HTTPS

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

Hypertext Transfer Protocol Secure ( HTTP ) เป็นส่วนขยายของHypertext Transfer Protocol (HTTP) ใช้สำหรับการสื่อสารที่ปลอดภัยผ่านเครือข่ายคอมพิวเตอร์และใช้กันอย่างแพร่หลายบนอินเทอร์เน็ต [1] [2]ใน HTTPS โปรโตคอลการสื่อสารถูกเข้ารหัสโดยใช้Transport Layer Security (TLS) หรือก่อนหน้านี้คือ Secure Sockets Layer (SSL) โปรโตคอลนี้จึงถูกเรียกว่าHTTP over TLS , [3]หรือ HTTP over SSL

แรงจูงใจหลักสำหรับ HTTPS คือการตรวจสอบสิทธิ์ ของ เว็บไซต์ที่เข้าถึงและการปกป้องความเป็นส่วนตัวและความสมบูรณ์ของข้อมูลที่แลกเปลี่ยนระหว่างการส่งผ่าน มันป้องกันการโจมตีจากคนกลางและการเข้ารหัสการสื่อสารแบบสองทิศทางระหว่างไคลเอนต์และเซิร์ฟเวอร์ปกป้องการสื่อสารจากการดักฟังและการปลอมแปลง [4] [5]ด้านการรับรองความถูกต้องของ HTTPS กำหนดให้บุคคลที่สามที่เชื่อถือได้ลงนามในใบรับรองดิจิทัล ฝั่งเซิร์ฟเวอร์. ในอดีตเป็นการดำเนินการที่มีราคาแพง ซึ่งหมายความว่าการเชื่อมต่อ HTTPS ที่รับรองความถูกต้องโดยสมบูรณ์มักพบในบริการธุรกรรมการชำระเงินที่ปลอดภัยและระบบข้อมูลองค์กรที่ปลอดภัยอื่นๆ บนเวิลด์ไวด์เว็บเท่านั้น ในปี 2559 แคมเปญโดยมูลนิธิ Electronic Frontier Foundationซึ่งได้รับการสนับสนุนจาก นักพัฒนา เว็บเบราว์เซอร์ทำให้โปรโตคอลเป็นที่แพร่หลายมากขึ้น [6]ปัจจุบันผู้ใช้เว็บใช้ HTTPS บ่อยกว่า HTTP ดั้งเดิมที่ไม่ปลอดภัย โดยหลักแล้วเพื่อปกป้องความถูกต้องของหน้าบนเว็บไซต์ทุกประเภท บัญชีที่ปลอดภัย และเพื่อให้การสื่อสารของผู้ใช้ ข้อมูลประจำตัว และการท่องเว็บเป็นส่วนตัว

ภาพรวม

URLที่ขึ้นต้นด้วยรูปแบบ HTTPS และป้ายชื่อโดเมนWWW

รูปแบบ Uniform Resource Identifier (URI) HTTPSมีรูปแบบการใช้งานที่เหมือนกันกับรูปแบบ HTTP อย่างไรก็ตาม HTTPS จะส่งสัญญาณให้เบราว์เซอร์ใช้ชั้นการเข้ารหัสเพิ่มเติมของ SSL/TLS เพื่อป้องกันการรับส่งข้อมูล SSL/TLS เหมาะสมเป็นพิเศษสำหรับ HTTP เนื่องจากสามารถให้การป้องกันบางอย่างได้ แม้ว่าจะมีการตรวจสอบสิทธิ์ การสื่อสารเพียงด้าน เดียว กรณีนี้เป็นกรณีของธุรกรรม HTTP ทางอินเทอร์เน็ต ซึ่งโดยทั่วไปแล้ว มีเพียงเซิร์ฟเวอร์ เท่านั้นที่ ได้รับการตรวจสอบสิทธิ์ (โดยไคลเอ็นต์ตรวจสอบใบรับรอง ของเซิร์ฟเวอร์ )

HTTPS สร้างช่องทางที่ปลอดภัยบนเครือข่ายที่ไม่ปลอดภัย สิ่งนี้ทำให้มั่นใจได้ว่ามีการป้องกันที่เหมาะสมจากการดักฟังและการโจมตีโดยคนกลาง โดยมีเงื่อนไขว่ามีการใช้ ชุดการเข้ารหัสที่เพียงพอและใบรับรองเซิร์ฟเวอร์ได้รับการตรวจสอบและเชื่อถือได้

เนื่องจาก HTTPS piggybacks HTTP ทั้งหมดอยู่ด้านบนของ TLS จึงสามารถเข้ารหัสโปรโตคอล HTTP พื้นฐานทั้งหมดได้ ซึ่งรวมถึง URL คำขอ (ซึ่งมีการขอหน้าเว็บใดโดยเฉพาะ) พารามิเตอร์การค้นหา ส่วนหัว และคุกกี้ (ซึ่งมักมีข้อมูลระบุตัวตนเกี่ยวกับผู้ใช้) อย่างไรก็ตาม เนื่องจากที่อยู่เว็บไซต์และ หมายเลข พอร์ตจำเป็นต้องเป็นส่วนหนึ่งของTCP/IP . พื้นฐานโปรโตคอล HTTPS ไม่สามารถป้องกันการเปิดเผยได้ ในทางปฏิบัติ นี่หมายความว่าแม้ในเว็บเซิร์ฟเวอร์ที่กำหนดค่าอย่างถูกต้อง ผู้แอบฟังสามารถสรุปที่อยู่ IP และหมายเลขพอร์ตของเว็บเซิร์ฟเวอร์ และบางครั้งแม้แต่ชื่อโดเมน (เช่น www.example.org แต่ไม่ใช่ URL ที่เหลือ) ที่ ผู้ใช้กำลังสื่อสารด้วย พร้อมกับปริมาณข้อมูลที่ถ่ายโอนและระยะเวลาของการสื่อสาร แม้ว่าจะไม่ใช่เนื้อหาของการสื่อสารก็ตาม [4]

เว็บเบราว์เซอร์รู้วิธีเชื่อถือเว็บไซต์ HTTPS โดยอิงตามผู้ออกใบรับรองที่ติดตั้งมาล่วงหน้าในซอฟต์แวร์ของตน ผู้ออกใบรับรองได้รับความไว้วางใจจากผู้สร้างเว็บเบราว์เซอร์เพื่อให้ใบรับรองที่ถูกต้อง ดังนั้น ผู้ใช้ควรเชื่อถือการเชื่อมต่อ HTTPS กับเว็บไซต์ก็ต่อเมื่อสิ่งต่อไปนี้เป็นจริงเท่านั้น:

  • ผู้ใช้วางใจว่าอุปกรณ์ที่ใช้เปิดเบราว์เซอร์และวิธีการรับเบราว์เซอร์นั้นจะไม่เป็นอันตราย (เช่น การโจมตีของห่วงโซ่อุปทาน )
  • ผู้ใช้เชื่อว่าซอฟต์แวร์เบราว์เซอร์ใช้ HTTPS อย่างถูกต้องพร้อมผู้ออกใบรับรองที่ติดตั้งไว้ล่วงหน้าอย่างถูกต้อง
  • ผู้ใช้เชื่อถือผู้ออกใบรับรองเพื่อรับรองเฉพาะเว็บไซต์ที่ถูกต้องเท่านั้น (กล่าวคือ ผู้ออกใบรับรองไม่ถูกบุกรุกและไม่มีการออกใบรับรองอย่างไม่ถูกต้อง)
  • เว็บไซต์มีใบรับรองที่ถูกต้อง ซึ่งหมายความว่ามีการลงนามโดยผู้มีอำนาจที่เชื่อถือได้
  • ใบรับรองระบุเว็บไซต์ได้อย่างถูกต้อง (เช่น เมื่อเบราว์เซอร์เข้าชม " https://example.com " ใบรับรองที่ได้รับนั้นถูกต้องสำหรับ "example.com" และไม่ใช่หน่วยงานอื่น)
  • ผู้ใช้เชื่อมั่นว่าเลเยอร์การเข้ารหัสของโปรโตคอล (SSL/TLS) มีความปลอดภัยเพียงพอต่อการดักฟัง

HTTPS มีความสำคัญอย่างยิ่งต่อเครือข่ายและเครือข่ายที่ไม่ปลอดภัยซึ่งอาจมีการปลอมแปลง เครือข่ายที่ไม่ปลอดภัย เช่นจุดเชื่อมต่อ Wi-Fi สาธารณะ อนุญาตให้ทุกคนในเครือข่ายท้องถิ่นเดียวกันสามารถดักจับแพ็กเก็ตและค้นพบข้อมูลที่ละเอียดอ่อนซึ่งไม่ได้รับการปกป้องโดย HTTPS นอกจากนี้ เครือข่าย WLAN ที่เสียค่าใช้จ่ายและใช้งานฟรีบาง เครือข่ายได้รับการตรวจพบว่ามีการปลอมแปลงหน้าเว็บโดยมีส่วนร่วมในการแทรกแพ็กเก็ตเพื่อแสดงโฆษณาของตนเองบนเว็บไซต์อื่นๆ แนวทางปฏิบัตินี้สามารถนำไปใช้ในทางที่ผิดได้หลายวิธี เช่น โดยการฉีดมัลแวร์ลงบนเว็บเพจและการขโมยข้อมูลส่วนตัวของผู้ใช้ [7]

HTTPS ก็มีความสำคัญสำหรับการเชื่อมต่อผ่านเครือข่าย Torเนื่องจากโหนด Tor ที่เป็นอันตรายอาจสร้างความเสียหายหรือเปลี่ยนแปลงเนื้อหาที่ส่งผ่านในลักษณะที่ไม่ปลอดภัยและแทรกมัลแวร์เข้าสู่การเชื่อมต่อ นี่เป็นเหตุผลหนึ่งที่มูลนิธิ Electronic Frontier Foundationและโครงการ Torเริ่มพัฒนาHTTPS Everywhere [ 4]ซึ่งรวมอยู่ใน Tor Browser [8]

เนื่องจากมีการเปิดเผยข้อมูลเพิ่มเติมเกี่ยวกับการสอดส่องมวลชน ทั่วโลก และอาชญากรที่ขโมยข้อมูลส่วนบุคคล การใช้การรักษาความปลอดภัย HTTPS ในทุกเว็บไซต์จึงมีความสำคัญมากขึ้นเรื่อยๆ โดยไม่คำนึงถึงประเภทของการเชื่อมต่ออินเทอร์เน็ตที่ใช้ [9] [10]แม้ว่าข้อมูลเมตาเกี่ยวกับหน้าเว็บแต่ละหน้าที่ผู้ใช้เข้าชมอาจไม่ถือว่าละเอียดอ่อน แต่เมื่อรวมแล้วก็สามารถเปิดเผยข้อมูลจำนวนมากเกี่ยวกับผู้ใช้และทำให้ความเป็นส่วนตัวของผู้ใช้ลดลงได้ [11] [12] [13]

การปรับใช้ HTTPS ยังอนุญาตให้ใช้HTTP/2 (หรือโปรโตคอลรุ่นก่อนคือ SPDYที่เลิกใช้แล้วในขณะนี้) ซึ่งเป็น HTTP รุ่นใหม่ที่ออกแบบมาเพื่อลดเวลาการโหลดหน้าเว็บ ขนาด และเวลาแฝง

ขอแนะนำให้ใช้HTTP Strict Transport Security (HSTS) กับ HTTPS เพื่อปกป้องผู้ใช้จากการโจมตีแบบ man-in-the-middle โดยเฉพาะSSL stripping [13] [14]

ไม่ควรสับสน HTTPS กับSecure HTTP (S-HTTP) ที่ไม่ค่อยได้ใช้ซึ่งระบุไว้ใน RFC 2660

การใช้งานบนเว็บไซต์

ณ เดือนเมษายน 2018 33.2% ของเว็บไซต์ยอดนิยม 1,000,000 อันดับแรกของ Alexa ใช้ HTTPS เป็นค่าเริ่มต้น[15] 57.1% ของเว็บไซต์ยอดนิยม 137,971 แห่งบนอินเทอร์เน็ตมีการใช้งาน HTTPS อย่างปลอดภัย[16]และ 70% ของการโหลดหน้า (วัดโดย Firefox Telemetry ) ใช้ HTTPS [17]

การรวมเบราว์เซอร์

เบราว์เซอร์ส่วนใหญ่แสดงคำเตือนหากได้รับใบรับรองที่ไม่ถูกต้อง เบราว์เซอร์รุ่นเก่า เมื่อเชื่อมต่อกับไซต์ที่มีใบรับรองที่ไม่ถูกต้อง จะแสดงกล่องโต้ตอบ ให้ผู้ใช้ ถามว่าต้องการดำเนินการต่อหรือไม่ เบราว์เซอร์ที่ใหม่กว่าจะแสดงคำเตือนทั่วทั้งหน้าต่าง เบราว์เซอร์ที่ใหม่กว่ายังแสดงข้อมูลความปลอดภัยของเว็บไซต์อย่างเด่นชัดในแถบที่อยู่ ใบรับรองการตรวจสอบเพิ่มเติมแสดงนิติบุคคลในข้อมูลใบรับรอง เบราว์เซอร์ส่วนใหญ่ยังแสดงคำเตือนแก่ผู้ใช้เมื่อเข้าชมไซต์ที่มีเนื้อหาที่เข้ารหัสและไม่ได้เข้ารหัสผสมกัน นอกจากนี้ตัวกรองเว็บ จำนวนมาก ยังแสดงคำเตือนด้านความปลอดภัยเมื่อเข้าชมเว็บไซต์ต้องห้าม

มูลนิธิElectronic Frontier Foundationให้ความเห็นว่า "ในโลกอุดมคติ ทุกคำขอของเว็บอาจถูกตั้งค่าเริ่มต้นเป็น HTTPS" ได้จัดเตรียมส่วนเสริมที่เรียกว่า HTTPS ทุกที่สำหรับMozilla Firefox , Google Chrome , ChromiumและAndroidที่เปิดใช้งาน HTTPS เป็นค่าเริ่มต้นสำหรับ เว็บไซต์ที่ใช้บ่อยหลายร้อยแห่ง [18] [19]

การบังคับให้เว็บเบราว์เซอร์โหลดเนื้อหา HTTPS เท่านั้นได้รับการสนับสนุนใน Firefox โดยเริ่มในเวอร์ชัน 83 [20]เริ่มในเวอร์ชัน 94 Google Chrome สามารถ "ใช้การเชื่อมต่อที่ปลอดภัยเสมอ" หากเปิดใช้งานในการตั้งค่าของเบราว์เซอร์ [21] [22]

ความปลอดภัย

ความปลอดภัยของ HTTPS เป็นความปลอดภัยของ TLS พื้นฐาน ซึ่งโดยทั่วไปแล้วจะใช้ คีย์ สาธารณะ และส่วนตัวระยะยาวเพื่อสร้าง คีย์เซสชันระยะสั้นซึ่งจะใช้ในการเข้ารหัสการไหลของข้อมูลระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ใบรับรอง X.509ใช้เพื่อรับรองความถูกต้องของเซิร์ฟเวอร์ (และบางครั้งก็เป็นไคลเอ็นต์ด้วย) ด้วยเหตุนี้ผู้ออกใบรับรองและใบรับรองคีย์สาธารณะจึงมีความจำเป็นในการตรวจสอบความสัมพันธ์ระหว่างใบรับรองกับเจ้าของ ตลอดจนเพื่อสร้าง ลงนาม และจัดการความถูกต้องของใบรับรอง แม้ว่าสิ่งนี้จะมีประโยชน์มากกว่าการตรวจสอบตัวตนผ่านเว็บที่เชื่อถือได้ แต่การเปิดเผยการสอดส่องดูแลมวลชนปี 2013ดึงความสนใจไปยังผู้ออกใบรับรองว่าเป็นจุดอ่อนที่อาจทำให้ การโจมตี แบบคนกลาง [23] [24]คุณสมบัติที่สำคัญในบริบทนี้คือความลับในการส่งต่อซึ่งทำให้มั่นใจได้ว่าการสื่อสารที่เข้ารหัสที่บันทึกไว้ในอดีตจะไม่สามารถเรียกคืนและถอดรหัสได้หากคีย์ลับหรือรหัสผ่านระยะยาวถูกบุกรุกในอนาคต ไม่ใช่ทุกเว็บเซิร์ฟเวอร์ที่มีความลับในการส่งต่อ [25] [ ต้องการการปรับปรุง ]

เพื่อให้ HTTPS มีประสิทธิภาพ เว็บไซต์ต้องโฮสต์ผ่าน HTTPS อย่างสมบูรณ์ หากเนื้อหาบางส่วนของเว็บไซต์โหลดผ่าน HTTP (เช่น สคริปต์หรือรูปภาพ) หรือหากมีการโหลดเฉพาะหน้าที่มีข้อมูลที่ละเอียดอ่อน เช่น หน้าเข้าสู่ระบบ โหลดผ่าน HTTPS ในขณะที่โหลดส่วนที่เหลือของเว็บไซต์ ผ่าน HTTP ธรรมดา ผู้ใช้จะเสี่ยงต่อการถูกโจมตีและการเฝ้าระวัง นอกจากนี้คุกกี้บนไซต์ที่ให้บริการผ่าน HTTPS จะต้องเปิดใช้งานแอตทริบิวต์ที่ปลอดภัย ในไซต์ที่มีข้อมูลที่ละเอียดอ่อน ผู้ใช้และเซสชันจะถูกเปิดเผยทุกครั้งที่เข้าถึงไซต์นั้นด้วย HTTP แทนที่จะเป็น HTTPS [13]

เทคนิค

ความแตกต่างจาก HTTP

HTTPS URLเริ่มต้นด้วย "https://" และใช้พอร์ต 443 โดยค่าเริ่มต้น ในขณะที่HTTP URL จะขึ้นต้นด้วย "http://" และใช้พอร์ต 80 โดยค่าเริ่มต้น

HTTP ไม่ได้รับการเข้ารหัส ดังนั้นจึงเสี่ยงต่อ การโจมตีโดย คนกลางและการดักฟังซึ่งทำให้ผู้โจมตีสามารถเข้าถึงบัญชีเว็บไซต์และข้อมูลที่มีความละเอียดอ่อน และแก้ไขหน้าเว็บเพื่อแทรกมัลแวร์หรือโฆษณา HTTPS ได้รับการออกแบบมาให้ทนต่อการโจมตีดังกล่าวและถือว่าปลอดภัยจากการโจมตีดังกล่าว (ยกเว้นการใช้งาน HTTPS ที่ใช้ SSL เวอร์ชันที่เลิกใช้แล้ว)

ชั้นเครือข่าย

HTTP ทำงานที่เลเยอร์สูงสุดของโมเดล TCP/IPเลเยอร์แอปพลิเคชัน เช่นเดียวกับ โปรโตคอลความปลอดภัย TLS (ทำงานเป็นเลเยอร์ย่อยที่ต่ำกว่าของเลเยอร์เดียวกัน) ซึ่งเข้ารหัสข้อความ HTTP ก่อนส่งและถอดรหัสข้อความเมื่อมาถึง พูดอย่างเคร่งครัด HTTPS ไม่ใช่โปรโตคอลที่แยกจากกัน แต่หมายถึงการใช้HTTP ธรรมดา ผ่านการเชื่อมต่อ SSL/TLS ที่ เข้ารหัส

HTTPS เข้ารหัสเนื้อหาข้อความทั้งหมด รวมถึงส่วนหัว HTTP และข้อมูลคำขอ/ตอบกลับ ยกเว้นการโจมตีแบบเข้ารหัสลับCCA ที่เป็นไปได้ซึ่งอธิบายไว้ในส่วน ข้อจำกัดด้านล่าง อย่างมากที่สุดผู้โจมตีควรสามารถค้นพบว่ามีการเชื่อมต่อระหว่างสองฝ่าย พร้อมด้วยชื่อโดเมนและที่อยู่ IP ของพวกเขา

การตั้งค่าเซิร์ฟเวอร์

ในการเตรียมเว็บเซิร์ฟเวอร์ให้ยอมรับการเชื่อมต่อ HTTPS ผู้ดูแลระบบต้องสร้างใบรับรองคีย์สาธารณะสำหรับเว็บเซิร์ฟเวอร์ ใบรับรองนี้ต้องลงนามโดยผู้ออกใบรับรอง ที่เชื่อถือได้ เพื่อให้เว็บเบราว์เซอร์ยอมรับโดยไม่มีการเตือน หน่วยงานรับรองว่าผู้ถือใบรับรองเป็นผู้ดำเนินการเว็บเซิร์ฟเวอร์ที่นำเสนอ โดยทั่วไปแล้ว เว็บเบราว์เซอร์จะแจกจ่ายพร้อมกับรายการใบรับรองการลงนามของผู้ออกใบรับรองรายใหญ่เพื่อให้สามารถตรวจสอบใบรับรองที่ลงนามโดยหน่วยงานเหล่านั้นได้

การรับใบรับรอง

มีผู้ ออกใบรับรองเชิงพาณิชย์จำนวนหนึ่ง โดยเสนอใบรับรอง SSL/TLS แบบชำระเงิน หลาย ประเภท รวมถึงExtended Validation Certificate

Let's Encryptซึ่งเปิดตัวในเดือนเมษายน 2559 [26]ให้บริการอัตโนมัติและฟรีที่มอบใบรับรอง SSL/TLS พื้นฐานไปยังเว็บไซต์ [27]ตามที่มูลนิธิ Electronic Frontier Foundationระบุว่า Let's Encrypt จะทำให้การเปลี่ยนจาก HTTP เป็น HTTPS "ง่ายเหมือนการออกคำสั่งเดียวหรือคลิกปุ่มเดียว" [28]ผู้ให้บริการโฮสต์เว็บและคลาวด์ส่วนใหญ่ตอนนี้ใช้ประโยชน์จาก Let's Encrypt โดยให้ใบรับรองฟรีแก่ลูกค้าของตน

ใช้เป็นตัวควบคุมการเข้าถึง

ระบบยังสามารถใช้สำหรับการรับรองความถูกต้อง ของไคลเอ็นต์ เพื่อจำกัดการเข้าถึงเว็บเซิร์ฟเวอร์ให้กับผู้ใช้ที่ได้รับอนุญาต เมื่อต้องการทำเช่นนี้ ผู้ดูแลไซต์มักจะสร้างใบรับรองสำหรับผู้ใช้แต่ละราย ซึ่งผู้ใช้โหลดลงในเบราว์เซอร์ของตน โดยปกติ ใบรับรองจะประกอบด้วยชื่อและที่อยู่อีเมลของผู้ใช้ที่ได้รับอนุญาต และเซิร์ฟเวอร์จะตรวจสอบโดยอัตโนมัติในแต่ละการเชื่อมต่อเพื่อยืนยันตัวตนของผู้ใช้ โดยอาจไม่ต้องใช้รหัสผ่านด้วยซ้ำ

กรณีรหัสลับ (ส่วนตัว) ถูกบุกรุก

คุณสมบัติที่สำคัญในบริบทนี้คือPerfect Forward Secrecy (PFS) การมีคีย์ลับแบบอสมมาตรระยะยาวอันใดอันหนึ่งที่ใช้สร้างเซสชัน HTTPS ไม่ควรทำให้ได้รับคีย์เซสชันระยะสั้นเพื่อถอดรหัสการสนทนาได้ง่ายขึ้น แม้จะในภายหลังก็ตาม การแลกเปลี่ยนกุญแจ Diffie–Hellman (DHE) และการแลกเปลี่ยนกุญแจแบบโค้ง Elliptic Diffie–Hellman (ECDHE) เป็นเพียงแผนเดียวเท่านั้นที่ทราบว่ามีคุณสมบัติดังกล่าวในปี 2013 ในปี 2013 เซสชัน Firefox, Opera และ Chromium Browser เพียง 30% ใช้งาน และเกือบ 0% ของเซสชันSafari ของ Apple และMicrosoft Internet Explorer [25] TLS 1.3 ซึ่งเผยแพร่ในเดือนสิงหาคม 2018 ได้ยกเลิกการสนับสนุนการเข้ารหัสโดยไม่มีการส่งต่อความลับ ณ เดือนกุมภาพันธ์ 2563, 96.6% ของเว็บเซิร์ฟเวอร์ที่สำรวจสนับสนุนรูปแบบการส่งต่อความลับบางรูปแบบ และ 52.1% จะใช้การส่งต่อความลับกับเบราว์เซอร์ส่วนใหญ่ [29]

การเพิกถอนใบรับรอง

ใบรับรองอาจถูกเพิกถอนก่อนหมดอายุ ตัวอย่างเช่น เนื่องจากความลับของคีย์ส่วนตัวถูกบุกรุก เบราว์เซอร์ยอดนิยมเวอร์ชันใหม่กว่า เช่นFirefox , [30] Opera , [31]และInternet ExplorerบนWindows Vista [32]ใช้Online Certificate Status Protocol (OCSP) เพื่อตรวจสอบว่าไม่ใช่กรณีนี้ เบราว์เซอร์จะส่งหมายเลขซีเรียลของใบรับรองไปยังผู้ออกใบรับรองหรือผู้รับมอบสิทธิ์ผ่าน OCSP (โปรโตคอลสถานะใบรับรองออนไลน์) และหน่วยงานตอบกลับโดยบอกเบราว์เซอร์ว่าใบรับรองยังใช้ได้อยู่หรือไม่ [33] CA อาจออกCRLเพื่อบอกผู้คนว่าใบรับรองเหล่านี้ถูกเพิกถอน CRL ไม่จำเป็นอีกต่อไปในฟอรัม CA/เบราว์เซอร์[34]อย่างไรก็ตาม CA ยังคงใช้กันอย่างแพร่หลาย สถานะการเพิกถอนส่วนใหญ่บนอินเทอร์เน็ตจะหายไปในไม่ช้าหลังจากใบรับรองหมดอายุ [35]

ข้อจำกัด

การเข้ารหัส SSL (Secure Sockets Layer) และ TLS (Transport Layer Security) สามารถกำหนดค่าได้ในสองโหมด: แบบธรรมดาและ แบบ ร่วมกัน ในโหมดธรรมดา การรับรองความถูกต้องจะดำเนินการโดยเซิร์ฟเวอร์เท่านั้น รุ่นร่วมกันกำหนดให้ผู้ใช้ติดตั้งใบรับรองไคลเอ็นต์ ส่วนบุคคล ในเว็บเบราว์เซอร์เพื่อตรวจสอบสิทธิ์ผู้ใช้ [36]ไม่ว่าในกรณีใด ระดับการป้องกันจะขึ้นอยู่กับความถูกต้องของการใช้งานซอฟต์แวร์และอัลกอริธึมการเข้ารหัส ที่ ใช้งาน

SSL/TLS ไม่ได้ป้องกันการสร้างดัชนีของไซต์โดยโปรแกรมรวบรวมข้อมูลเว็บและในบางกรณีURIของทรัพยากรที่เข้ารหัสสามารถอนุมานได้ด้วยการรู้เฉพาะขนาดคำขอ/การตอบกลับที่ถูกดักจับ [37]สิ่งนี้ทำให้ผู้โจมตีสามารถเข้าถึงข้อความธรรมดา (เนื้อหาสแตติกที่เปิดเผยต่อสาธารณะ) และข้อความที่เข้ารหัส (เวอร์ชันที่เข้ารหัสของเนื้อหาสแตติก) ซึ่งอนุญาตให้มีการโจมตีด้วยการเข้ารหัส

เนื่องจากTLSทำงานที่ระดับโปรโตคอลที่ต่ำกว่า HTTP และไม่มีความรู้เกี่ยวกับโปรโตคอลระดับสูง เซิร์ฟเวอร์ TLS สามารถแสดงใบรับรองได้เพียงรายการเดียวเท่านั้นสำหรับที่อยู่และพอร์ตเฉพาะ [38]ในอดีต หมายความว่าเป็นไปไม่ได้ที่จะใช้โฮสติ้งเสมือนตามชื่อกับ HTTPS มีโซลูชันที่เรียกว่าServer Name Indication (SNI) ซึ่งส่งชื่อโฮสต์ไปยังเซิร์ฟเวอร์ก่อนที่จะเข้ารหัสการเชื่อมต่อ แม้ว่าเบราว์เซอร์รุ่นเก่าจำนวนมากจะไม่สนับสนุนส่วนขยายนี้ รองรับ SNI ตั้งแต่Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 และInternet Explorer 7บนWindows Vista . [39] [40] [41]

จากมุมมองทางสถาปัตยกรรม:

  • การเชื่อมต่อ SSL/TLS ได้รับการจัดการโดยเครื่องด้านหน้าเครื่องแรกที่เริ่มต้นการเชื่อมต่อ TLS หากด้วยเหตุผลใดก็ตาม (การกำหนดเส้นทาง การเพิ่มประสิทธิภาพการรับส่งข้อมูล ฯลฯ) เครื่องด้านหน้านี้ไม่ใช่เซิร์ฟเวอร์แอปพลิเคชันและต้องถอดรหัสข้อมูล จะต้องพบโซลูชันเพื่อเผยแพร่ข้อมูลการตรวจสอบสิทธิ์ผู้ใช้หรือใบรับรองไปยังเซิร์ฟเวอร์แอปพลิเคชัน ซึ่งจำเป็นต้อง รู้ว่าใครจะเชื่อมต่อ
  • สำหรับ SSL/TLS ที่มีการพิสูจน์ตัวตนร่วมกัน เซสชัน SSL/TLS จะได้รับการจัดการโดยเซิร์ฟเวอร์แรกที่เริ่มต้นการเชื่อมต่อ ในสถานการณ์ที่การเข้ารหัสต้องแพร่กระจายไปตามเซิร์ฟเวอร์ที่ถูกล่ามโซ่ การจัดการ session timeOut จะกลายเป็นเรื่องยุ่งยากอย่างมากในการนำไปใช้
  • ความปลอดภัยสูงสุดเมื่อใช้ SSL/TLS ร่วมกัน แต่ในฝั่งไคลเอ็นต์ไม่มีทางที่จะยุติการเชื่อมต่อ SSL/TLS ได้อย่างถูกต้องและยกเลิกการเชื่อมต่อผู้ใช้ ยกเว้นโดยการรอให้เซสชันของเซิร์ฟเวอร์หมดอายุหรือโดยการปิดแอปพลิเคชันไคลเอ็นต์ที่เกี่ยวข้องทั้งหมด

ประเภทที่ซับซ้อนของการโจมตีแบบ man-in-the-middle ที่เรียกว่า SSL stripping ถูกนำเสนอในการประชุม Blackhat ใน ปี 2009 การโจมตีประเภทนี้เอาชนะการรักษาความปลอดภัยที่มีให้โดย HTTPS โดยการเปลี่ยนhttps:ลิงก์เป็นhttp:ลิงก์ โดยใช้ประโยชน์จากข้อเท็จจริงที่ว่าผู้ใช้อินเทอร์เน็ตเพียงไม่กี่รายพิมพ์ "https" ลงในอินเทอร์เฟซของเบราว์เซอร์ พวกเขาไปที่ไซต์ที่ปลอดภัยโดยคลิกที่ลิงก์ และ ดังนั้นจึงถูกหลอกให้คิดว่าพวกเขากำลังใช้ HTTPS ทั้งที่จริง ๆ แล้วพวกเขากำลังใช้ HTTP ผู้โจมตีจะสื่อสารกับลูกค้าอย่างชัดเจน [42]สิ่งนี้ทำให้เกิดการพัฒนามาตรการตอบโต้ใน HTTP ที่เรียกว่าHTTP Strict Transport Security

พบว่า HTTPS มีความเสี่ยงต่อ การ โจมตีการวิเคราะห์ปริมาณการ ใช้งาน การโจมตีการวิเคราะห์ปริมาณการใช้ข้อมูลเป็นประเภทของการโจมตีช่องทางด้านข้างที่อาศัยการเปลี่ยนแปลงของเวลาและขนาดของการรับส่งข้อมูลเพื่อสรุปคุณสมบัติเกี่ยวกับการรับส่งข้อมูลที่เข้ารหัสเอง การวิเคราะห์การรับส่งข้อมูลเป็นไปได้เนื่องจากการเข้ารหัส SSL/TLS เปลี่ยนแปลงเนื้อหาของการรับส่งข้อมูล แต่มีผลกระทบน้อยที่สุดต่อขนาดและระยะเวลาของการรับส่งข้อมูล ในเดือนพฤษภาคม 2553 บทความวิจัยโดยนักวิจัยจากMicrosoft ResearchและIndiana Universityพบว่าข้อมูลผู้ใช้ที่ละเอียดอ่อนโดยละเอียดสามารถอนุมานได้จากช่องทางด้านข้าง เช่น ขนาดแพ็คเก็ต นักวิจัยพบว่า แม้จะมีการป้องกัน HTTPS ในเว็บแอปพลิเคชันระดับสูงที่มีชื่อเสียงในด้านการดูแลสุขภาพ ภาษี การลงทุน และการค้นหาเว็บ ผู้ดักฟังสามารถสรุปความเจ็บป่วย/ยา/การผ่าตัดของผู้ใช้ได้ รายได้ของครอบครัวและความลับในการลงทุนของเธอ [43]แม้ว่างานนี้แสดงให้เห็นถึงช่องโหว่ของ HTTPS ต่อการวิเคราะห์ปริมาณการใช้ข้อมูล แต่แนวทางที่นำเสนอโดยผู้เขียนจำเป็นต้องมีการวิเคราะห์ด้วยตนเองและเน้นเฉพาะบนเว็บแอปพลิเคชันที่ได้รับการป้องกันโดย HTTPS

ข้อเท็จจริงที่ว่าเว็บไซต์ที่ทันสมัยส่วนใหญ่ รวมทั้ง Google, Yahoo! และ Amazon ใช้ HTTPS ทำให้เกิดปัญหากับผู้ใช้จำนวนมากที่พยายามเข้าถึงฮอตสปอต Wi-Fi สาธารณะ เนื่องจากหน้าเข้าสู่ระบบฮอตสปอต Wi-Fi ไม่สามารถโหลดได้หากผู้ใช้พยายาม เปิดทรัพยากร HTTPS [44]เว็บไซต์หลายแห่ง เช่นneverssl.comและnonhttps.comรับประกันว่า HTTP จะยังคงเข้าถึงได้เสมอ [45] [46]

ประวัติ

Netscape Communicationsสร้าง HTTPS ในปี 1994 สำหรับเว็บเบราว์เซอร์Netscape Navigator [47]เดิมที ใช้ HTTPS กับโปรโตคอลSSL เมื่อ SSL พัฒนาเป็นTransport Layer Security (TLS) HTTPS ได้รับการระบุอย่างเป็นทางการโดย RFC 2818 ในเดือนพฤษภาคม 2000 Google ประกาศในเดือนกุมภาพันธ์ 2018 ว่าเบราว์เซอร์ Chrome จะทำเครื่องหมายไซต์ HTTP ว่า "ไม่ปลอดภัย" หลังจากเดือนกรกฎาคม 2018 [48]การย้ายครั้งนี้คือ เพื่อสนับสนุนให้เจ้าของเว็บไซต์ใช้ HTTPS เพื่อทำให้เวิลด์ไวด์เว็บมีความปลอดภัยมากขึ้น

ดูเพิ่มเติม

อ้างอิง

  1. ^ "ปกป้องเว็บไซต์ของคุณ ด้วยHTTPS" ฝ่ายสนับสนุน ของGoogle Google Inc. เก็บถาวรจากต้นฉบับเมื่อวันที่ 1 มีนาคม2558 สืบค้นเมื่อ20 ตุลาคม 2018 .
  2. ^ "HTTPS คืออะไร" . โคโมโด ซี เอจำกัด เก็บจากต้นฉบับเมื่อ 12 กุมภาพันธ์ 2558 . สืบค้นเมื่อ20 ตุลาคม 2018 . Hyper Text Transfer Protocol Secure (HTTPS) เป็นเวอร์ชันที่ปลอดภัยของ HTTP [...]
  3. ^ คณะทำงานเครือข่าย (พฤษภาคม 2543) "HTTP บนTLS" คณะทำงานด้านวิศวกรรมอินเทอร์เน็ต เก็บถาวรจากต้นฉบับเมื่อ 31 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  4. ^ a b c "คำถามที่พบบ่อย HTTPS ทุกที่ " 8 พฤศจิกายน 2559 เก็บถาวรจากต้นฉบับเมื่อ 14 พฤศจิกายน 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  5. ^ "สถิติการใช้งานของโปรโตคอลเริ่มต้น https สำหรับเว็บไซต์ กรกฎาคม 2019 " w3techs.com . เก็บถาวรจากต้นฉบับเมื่อ 1 สิงหาคม 2019 . สืบค้นเมื่อ20 กรกฎาคม 2019 .
  6. ^ "การเข้ารหัสเว็บ" . มูลนิธิพรมแดนอิเล็กทรอนิกส์ . เก็บจากต้นฉบับเมื่อ 18 พฤศจิกายน 2019 . สืบค้นเมื่อ19 พฤศจิกายน 2019 .
  7. ^ "การฉีด JavaScript ของโรงแรม Wifi" แค่นอน ไม่หลับ 3 เมษายน 2555. เก็บถาวรจากต้นฉบับเมื่อ 18 พฤศจิกายน 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  8. ^ The Tor Project, Inc. "เบราว์เซอร์ของ Tor คืออะไร" . TorProject.org . เก็บถาวรจากต้นฉบับเมื่อ 17 กรกฎาคม 2556 . สืบค้นเมื่อ30 พฤษภาคม 2555 .
  9. โคนิกส์บวร์ก, เอตัน; แพนท์, ราจีฟ; Kvochko, Elena (13 พฤศจิกายน 2014). "โอบรับ HTTPS " เดอะนิวยอร์กไทม์ส . เก็บถาวรจากต้นฉบับเมื่อ 8 มกราคม 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  10. กัลลาเกอร์, เควิน (12 กันยายน 2014). "สิบห้าเดือนหลังจากการเปิดเผยของ NSA เหตุใดองค์กรข่าวจึงไม่ใช้ HTTPS อีก" . มูลนิธิเสรีภาพสื่อมวลชน. เก็บถาวรจากต้นฉบับเมื่อ 10 สิงหาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  11. ^ "HTTPS เป็นสัญญาณอันดับ" . บล็อกGoogle Webmaster Central Google Inc. 6 สิงหาคม 2014. เก็บถาวรจากต้นฉบับเมื่อ 17 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 . คุณสามารถทำให้เว็บไซต์ของคุณปลอดภัยด้วย HTTPS (Hypertext Transfer Protocol Secure) [...]
  12. ^ Grigorik, อิลยา; Far, Pierre (26 มิถุนายน 2014). "Google I/O 2014 - HTTPS ทุกที่ " นักพัฒนา Google เก็บถาวรจากต้นฉบับเมื่อ 20 พฤศจิกายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  13. ^ a b c "วิธีการปรับใช้ HTTPS อย่างถูกต้อง " 15 พฤศจิกายน 2553 เก็บถาวรจากต้นฉบับเมื่อ 10 ตุลาคม 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  14. ^ "การรักษาความปลอดภัยการขนส่งอย่างเข้มงวด HTTP" . เครือข่าย นักพัฒนา Mozilla เก็บถาวรจากต้นฉบับเมื่อ 19 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  15. ^ "สถิติการใช้งาน HTTPS บนเว็บไซต์ 1 ล้านอันดับแรก " StatOperator.com _ เก็บถาวรจากต้นฉบับเมื่อ 9 กุมภาพันธ์ 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  16. ^ "Qualys SSL Labs - SSL พัลส์ " www.ssllabs.com . 3 เมษายน 2561 เก็บถาวรจากต้นฉบับเมื่อ 2 ธันวาคม 2560 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  17. ^ "มาเข้ารหัสสถิติกันเถอะ" . LetsEncrypt.org _ เก็บถาวรจากต้นฉบับเมื่อ 19 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  18. เอเคอร์สลีย์, ปีเตอร์ (17 มิถุนายน 2010). "เข้ารหัสเว็บด้วยส่วนขยาย HTTPS ทุกที่ของ Firefox " บล็อกเอฟเอเก็บถาวรจากต้นฉบับเมื่อ 25 พฤศจิกายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  19. ^ "HTTPS ทุกที่" . โครงการเอฟเอ7 ตุลาคม 2554. เก็บถาวรจากต้นฉบับเมื่อ 5 มิถุนายน 2554 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  20. ^ "โหมด HTTPS เท่านั้นใน Firefox " สืบค้นเมื่อ12 พฤศจิกายนพ.ศ. 2564 .{{cite web}}: CS1 maint: url-status (link)
  21. ^ "จัดการความปลอดภัยและความปลอดภัยของ Chrome - Android - ความช่วยเหลือของ Google Chrome " support.google.com _ สืบค้นเมื่อ7 มีนาคม 2565 .
  22. ^ "ลงมือทำโหมด HTTPS-First ของ Chrome " เทคโด วส์ . 19 กรกฎาคม 2564 . สืบค้นเมื่อ7 มีนาคม 2565 .
  23. ซิงเกล, ไรอัน (24 มีนาคม 2010). "อุปกรณ์บังคับใช้กฎหมายล้มล้าง SSL " แบบ มีสาย เก็บถาวรจากต้นฉบับเมื่อ 17 มกราคม 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  24. ^ Schoen, Seth (24 มีนาคม 2010). งานวิจัย ใหม่ชี้รัฐบาลอาจปลอมใบรับรอง SSL เอฟเอฟ . เก็บถาวรจากต้นฉบับเมื่อ 4 มกราคม 2016 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  25. a b Duncan, Robert (25 มิถุนายน 2013). "SSL: สกัดกั้นวันนี้ ถอดรหัสในวันพรุ่งนี้ " เน็ตคราฟ. เก็บถาวรจากต้นฉบับเมื่อ 6 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  26. ^ Cimpanu, Catalin (12 เมษายน 2559). "มาเข้ารหัสกันเถอะ เปิดตัววันนี้ ปกป้อง 3.8 ล้านโดเมน " ข่าวซอฟท์พีเดีย. เก็บถาวรจากต้นฉบับเมื่อ 9 กุมภาพันธ์ 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  27. เคอร์เนอร์, ฌอน ไมเคิล (18 พฤศจิกายน 2014). "มาเข้ารหัสความพยายามที่จะปรับปรุงความปลอดภัยอินเทอร์เน็ตกัน เถอะ" eWeek.com . ควินสตรี ตเอ็นเตอร์ไพรส์ สืบค้นเมื่อ20 ตุลาคม 2018 .
  28. เอเคอร์สลีย์, ปีเตอร์ (18 พฤศจิกายน 2014). "เปิดตัวในปี 2015: ผู้ออกใบรับรองเพื่อเข้ารหัสทั้งเว็บ " มูลนิธิพรมแดนอิเล็กทรอนิกส์ . เก็บถาวรจากต้นฉบับเมื่อ 18 พฤศจิกายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  29. ^ Qualys SSL Labs "SSL พัลส์ " เก็บถาวรจากต้นฉบับ(3 กุมภาพันธ์ 2019)เมื่อ 15 กุมภาพันธ์ 2019 . สืบค้นเมื่อ25 กุมภาพันธ์ 2019 .
  30. ^ "นโยบายความเป็นส่วนตัวของ Mozilla Firefox " มูลนิธิมอซิลลา 27 เมษายน 2552 เก็บถาวรจากต้นฉบับเมื่อ 18 ตุลาคม 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  31. ^ "Opera 8 เปิดตัวบน FTP" . ซอฟ ต์พีเดีย 19 เมษายน 2548 เก็บถาวรจากต้นฉบับเมื่อ 9 กุมภาพันธ์ 2562 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  32. ^ Lawrence, Eric (31 มกราคม 2549). "การปรับปรุงความปลอดภัย HTTPS ใน Internet Explorer 7 " ไมโครซอฟต์ดอคส์ . สืบค้นเมื่อ24 ตุลาคม 2021 .
  33. ^ ไมเยอร์ส ไมเคิล; แองนีย์, ริช; มัลปานี, อัมบาริช; กัลเปริน, สลาวา; อดัมส์ คาร์ไลล์ (20 มิถุนายน 2542) "โปรโตคอลสถานะใบรับรองออนไลน์ – OCSP " คณะทำงาน ด้านวิศวกรรมอินเทอร์เน็ต เก็บถาวรจากต้นฉบับเมื่อ 25 สิงหาคม 2011 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  34. ^ "ข้อกำหนดพื้นฐาน" . ฟอรั่ ม CAB สืบค้นเมื่อ1 พฤศจิกายนพ.ศ. 2564{{cite web}}: CS1 maint: url-status (link)
  35. คอร์ซิตสกี้, นิกิตา; คาร์ลสัน, นิคลาส (2021). สถานะการเพิกถอนบนอินเทอร์เน็ต ในการดำเนินการของการประชุมการวัดผลแบบพาสซีฟและแอ็คทีฟปี 2564 (PAM 2021 ) arXiv : 2102.04288 .{{cite book}}: CS1 maint: url-status (link)
  36. ^ "จัดการใบรับรองไคลเอ็นต์บนอุปกรณ์ Chrome – ความช่วยเหลือสำหรับธุรกิจและการศึกษาของ Chrome " support.google.com _ เก็บถาวรจากต้นฉบับเมื่อ 9 กุมภาพันธ์ 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  37. ปูเซป, สตานิสลอว์ (31 กรกฎาคม 2551). "อ่าวโจรสลัด un-SSL" (PDF ) เก็บถาวร(PDF)จากต้นฉบับเมื่อ 20 มิถุนายน 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  38. ^ "การเข้ารหัสที่แข็งแกร่ง SSL/TLS: คำถามที่พบบ่อย " apache.org _ เก็บถาวรจากต้นฉบับเมื่อ 19 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  39. ^ Lawrence, Eric (22 ตุลาคม 2548) "การปรับปรุง HTTPS ที่กำลังจะมีขึ้นใน Internet Explorer 7 Beta 2 " ไมโครซอฟต์ . เก็บถาวรจากต้นฉบับเมื่อ 20 กันยายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  40. ^ "การระบุชื่อเซิร์ฟเวอร์ (SNI)" . ในหัวของอับราฮิ21 กุมภาพันธ์ 2549 เก็บถาวรจากต้นฉบับเมื่อ 10 สิงหาคม 2561 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  41. ปิแอร์, จูเลียน (19 ธันวาคม พ.ศ. 2544) "รองรับเบราว์เซอร์สำหรับการระบุชื่อเซิร์ฟเวอร์ TLS " บัก ซิลล่า . มูลนิธิมอซิลลา เก็บถาวรจากต้นฉบับเมื่อ 8 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  42. ^ "sslสตริป 0.9" . เก็บถาวรจากต้นฉบับเมื่อ 20 มิถุนายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  43. ^ โชวเฉิน; รุยวัง; เสี่ยวเฟิงหวาง; Kehuan Zhang (20 พฤษภาคม 2010). "ช่องด้านข้างรั่วในแอปพลิเคชันเว็บ: ความเป็นจริงในวันนี้ อนาคตที่ท้าทาย " ไมโครซอฟ รีเสิร์ช . IEEE Symposium on Security & Privacy 2010 เก็บถาวรจากต้นฉบับเมื่อ 22 กรกฎาคม2018 สืบค้นเมื่อ20 ตุลาคม 2018 .
  44. ^ Guaay, Matthew (21 กันยายน 2017). "วิธีบังคับให้เปิดหน้าเข้าสู่ระบบเครือข่าย Wi-Fi สาธารณะ " เก็บถาวรจากต้นฉบับเมื่อ 10 สิงหาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  45. ^ " ไม่เคย SSL" เก็บถาวรจากต้นฉบับเมื่อ 1 กันยายน 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  46. ^ "เว็บไซต์ที่ไม่ใช่ https" . เก็บถาวรจากต้นฉบับเมื่อ 17 ตุลาคม 2018 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  47. ^ วอลส์, โคลิน (2005). ซอฟต์แวร์ฝังตัว: The Works . นิวเนส. หน้า 344. ISBN 0-7506-7954-9. เก็บถาวรจากต้นฉบับเมื่อ 9 กุมภาพันธ์ 2019 . สืบค้นเมื่อ20 ตุลาคม 2018 .
  48. ^ "เว็บที่ปลอดภัยอยู่ที่นี่แล้ว" . บล็อกโครเมียม เก็บถาวรจากต้นฉบับเมื่อ 24 เมษายน 2019 . สืบค้นเมื่อ22 เมษายน 2019 .

ลิงค์ภายนอก