หมายเหตุ: ฉันเขียนคำตอบดั้งเดิมของฉันอย่างเร่งรีบ แต่หลังจากนั้นคำถามนี้ได้กลายเป็นคำถาม / คำตอบที่ได้รับความนิยมเป็นอย่างมากฉันจึงขยายคำตอบออกเล็กน้อยและทำให้แม่นยำยิ่งขึ้น
ความสามารถ TLS
"SSL" เป็นชื่อที่ใช้บ่อยที่สุดในการอ้างถึงโปรโตคอลนี้ แต่ SSL นั้นหมายถึงโปรโตคอลที่เป็นกรรมสิทธิ์ซึ่งออกแบบโดย Netscape ในช่วงกลางยุค 90 "TLS" เป็นมาตรฐาน IETF ที่ยึดตาม SSL ดังนั้นฉันจะใช้ TLS ในคำตอบของฉัน วันนี้อัตราต่อรองคือการเชื่อมต่อที่ปลอดภัยเกือบทั้งหมดของคุณบนเว็บกำลังใช้ TLS ไม่ใช่ SSL
TLS มีความสามารถหลายอย่าง:
- เข้ารหัสข้อมูลเลเยอร์แอปพลิเคชันของคุณ (ในกรณีของคุณโพรโทคอลเลเยอร์คือ HTTP)
- ตรวจสอบเซิร์ฟเวอร์กับลูกค้า
- ตรวจสอบลูกค้าไปยังเซิร์ฟเวอร์
# 1 และ # 2 เป็นเรื่องธรรมดามาก # 3 เป็นเรื่องธรรมดาน้อยกว่า ดูเหมือนว่าคุณจะให้ความสำคัญกับ # 2 ดังนั้นฉันจะอธิบายส่วนนั้น
การรับรอง
เซิร์ฟเวอร์รับรองความถูกต้องของตัวเองให้กับลูกค้าโดยใช้ใบรับรอง ใบรับรองคือหยดข้อมูล [1] ที่มีข้อมูลเกี่ยวกับเว็บไซต์:
- ชื่อโดเมน
- กุญแจสาธารณะ
- บริษัท ที่เป็นเจ้าของมัน
- เมื่อมันออก
- เมื่อมันหมดอายุ
- ใครเป็นคนออก
- เป็นต้น
คุณสามารถบรรลุความลับได้ (# 1 ด้านบน) โดยใช้กุญแจสาธารณะที่รวมอยู่ในใบรับรองเพื่อเข้ารหัสข้อความที่สามารถถอดรหัสได้ด้วยรหัสส่วนตัวที่เกี่ยวข้องเท่านั้นซึ่งควรเก็บไว้อย่างปลอดภัยบนเซิร์ฟเวอร์นั้น [2] มาเรียกคู่คีย์นี้ว่า KP1 เพื่อเราจะได้ไม่สับสนในภายหลัง คุณสามารถยืนยันได้ว่าชื่อโดเมนในใบรับรองตรงกับเว็บไซต์ที่คุณเข้าชม (# 2 ด้านบน)
แต่จะเกิดอะไรขึ้นถ้าศัตรูสามารถแก้ไขแพ็กเก็ตที่ส่งไปยังและจากเซิร์ฟเวอร์และถ้าศัตรูนั้นแก้ไขใบรับรองที่คุณนำเสนอด้วยและใส่กุญแจสาธารณะของตนเองหรือเปลี่ยนรายละเอียดสำคัญอื่น ๆ หากเกิดขึ้นฝ่ายตรงข้ามสามารถดักจับและแก้ไขข้อความใด ๆ ที่คุณคิดว่าได้รับการเข้ารหัสอย่างปลอดภัย
เพื่อป้องกันการโจมตีนี้ใบรับรองจะถูกเซ็นชื่อด้วยรหัสลับของคนอื่นในลักษณะที่ลายเซ็นสามารถตรวจสอบได้โดยใครก็ตามที่มีรหัสสาธารณะที่เกี่ยวข้อง ลองเรียกคู่คีย์นี้ว่า KP2 เพื่อให้ชัดเจนว่านี่ไม่ใช่คีย์เดียวกับที่เซิร์ฟเวอร์ใช้
เจ้าหน้าที่ออกใบรับรอง
ใครเป็นผู้สร้าง KP2 ใครลงนามในใบรับรอง
การออกใบรับรองมากเกินไปสักหน่อยหน่วยงานออกใบรับรองจะสร้าง KP2 และพวกเขาขายบริการโดยใช้ไพรเวตคีย์เพื่อลงนามใบรับรองสำหรับองค์กรอื่น ๆ ตัวอย่างเช่นฉันสร้างใบรับรองและฉันจ่ายให้ บริษัท อย่าง Verisign เพื่อเซ็นชื่อด้วยรหัสส่วนตัวของพวกเขา [3] เนื่องจากไม่มีใครนอกจาก Verisign เข้าถึงรหัสส่วนตัวนี้เราจึงไม่มีใครสามารถปลอมลายเซ็นนี้ได้
และฉันจะรับกุญแจสาธารณะใน KP2 เป็นการส่วนตัวเพื่อยืนยันลายเซ็นนั้นได้อย่างไร
เราได้เห็นแล้วว่าใบรับรองสามารถถือกุญแจสาธารณะ - และนักวิทยาศาสตร์คอมพิวเตอร์รักการสอบถามซ้ำ - ทำไมไม่ลองใส่กุญแจสาธารณะ KP2 ลงในใบรับรองแล้วแจกมันด้วยวิธีนี้? ตอนแรกมันฟังดูเพี้ยนเล็กน้อย แต่ในความเป็นจริงแล้วมันทำงานอย่างไร ดำเนินการต่อด้วยตัวอย่าง Verisign Verisign สร้างใบรับรองที่มีข้อมูลเกี่ยวกับพวกเขาประเภทของสิ่งที่พวกเขาได้รับอนุญาตให้ลงชื่อ (ใบรับรองอื่น ๆ ) และกุญแจสาธารณะของพวกเขา
ตอนนี้ถ้าฉันมีสำเนาของใบรับรอง Verisign นั้นฉันสามารถใช้มันเพื่อตรวจสอบลายเซ็นบนใบรับรองเซิร์ฟเวอร์สำหรับเว็บไซต์ที่ฉันต้องการเยี่ยมชม ง่ายใช่มั้ย!
ไม่เร็วนัก ฉันได้รับใบรับรอง Verisign จากที่ไหนสักแห่ง จะเกิดอะไรขึ้นถ้ามีคนปลอมแปลงใบรับรอง Verisign และวางกุญแจสาธารณะของตนเองไว้ในนั้น จากนั้นพวกเขาสามารถปลอมลายเซ็นในใบรับรองของเซิร์ฟเวอร์และเรากลับมาที่จุดเริ่มต้นของเรา: การโจมตีคนในกลาง
โซ่ใบรับรอง
การคิดอย่างต่อเนื่องซ้ำ ๆ เราสามารถแนะนำใบรับรองที่สามและคู่คีย์ที่สาม (KP3) และใช้สิ่งนั้นเพื่อลงนามในหนังสือรับรอง Verisign เราเรียกสิ่งนี้ว่าห่วงโซ่ใบรับรอง: ใบรับรองแต่ละใบในกลุ่มนั้นจะใช้ในการตรวจสอบใบรับรองถัดไป หวังว่าคุณคงเห็นแล้วว่าแนวทางแบบวนซ้ำนี้เป็นเพียงแค่เต่า / ใบรับรองจนสุดทาง หยุดที่ไหน
เนื่องจากเราไม่สามารถสร้างจำนวนอนันต์ของใบรับรองห่วงโซ่ใบรับรองเห็นได้ชัดว่ามีการหยุดที่ใดที่หนึ่งและที่ทำโดยรวมทั้งใบรับรองในห่วงโซ่ที่มีลงนามด้วยตนเอง
ฉันจะหยุดสักครู่ขณะที่คุณหยิบชิ้นส่วนของสมองจากหัวของคุณระเบิด ลงนามด้วยตนเอง ?!
ใช่ในตอนท้ายของห่วงโซ่ใบรับรอง (หรือที่รู้จักในชื่อ "รูท") จะมีใบรับรองที่ใช้เป็นคู่คีย์ของตนเองในการเซ็นชื่อ สิ่งนี้จะช่วยลดปัญหาการเรียกซ้ำไม่สิ้นสุด แต่ก็ไม่ได้แก้ไขปัญหาการตรวจสอบสิทธิ์ ใคร ๆ ก็สามารถสร้างใบรับรองที่ลงนามเองได้ซึ่งบอกอะไรก็ได้เหมือนฉันสามารถสร้างประกาศนียบัตรปลอมของพรินซ์ตันที่บอกว่าฉันเรียนวิชาเอกการเมืองการเมืองฟิสิกส์เชิงทฤษฎีและสมัครเตะก้นแล้วเซ็นชื่อของฉันเองที่ด้านล่าง
วิธีแก้ปัญหา [ค่อนข้างไม่น่าตื่นเต้น] สำหรับปัญหานี้คือการเลือกชุดใบรับรองที่ลงนามด้วยตนเองบางชุดที่คุณเชื่อถืออย่างชัดแจ้ง ตัวอย่างเช่นฉันอาจพูดว่า "ฉันเชื่อถือใบรับรอง Verisign ที่ลงชื่อด้วยตนเอง"
ตอนนี้ฉันสามารถตรวจสอบความถูกต้องของห่วงโซ่ใบรับรองทั้งหมดได้ ไม่ว่าจะมีใบรับรองจำนวนเท่าใดในสายโซ่ฉันสามารถตรวจสอบลายเซ็นแต่ละใบได้จนถึงราก เมื่อฉันไปถึงรูทฉันสามารถตรวจสอบว่าใบรับรองรูทนั้นเป็นใบรับรองที่ฉันเชื่อถืออย่างชัดเจนหรือไม่ ถ้าเป็นเช่นนั้นฉันสามารถไว้วางใจห่วงโซ่ทั้งหมด
ความไว้วางใจที่ตกลงกัน
รับรองความถูกต้องใน TLS ใช้ระบบของความไว้วางใจพระราชทาน ถ้าฉันต้องการจ้างช่างซ่อมรถยนต์ฉันอาจไม่เชื่อถือช่างสุ่ม ๆ ที่ฉันพบ แต่บางทีเพื่อนของฉันอาจรับรองช่างบางคน เนื่องจากฉันเชื่อใจเพื่อนของฉันดังนั้นฉันจึงสามารถวางใจช่างได้
เมื่อคุณซื้อคอมพิวเตอร์หรือดาวน์โหลดเบราว์เซอร์มันมาพร้อมกับใบรับรองสองสามร้อยใบที่เชื่อถือได้อย่างชัดเจน [4] บริษัท ที่เป็นเจ้าของและดำเนินการใบรับรองเหล่านี้สามารถมอบความไว้วางใจให้กับองค์กรอื่น ๆ ได้โดยการลงนามใบรับรอง
สิ่งนี้อยู่ไกลจากระบบที่สมบูรณ์แบบ บางครั้ง CA อาจออกใบรับรองอย่างไม่ถูกต้อง ในกรณีเหล่านั้นอาจต้องเพิกถอนใบรับรอง การเพิกถอนเป็นเรื่องยากเนื่องจากใบรับรองที่ออกให้นั้นจะถูกต้องแบบเข้ารหัสเสมอ จำเป็นต้องใช้โปรโตคอลที่ไม่อยู่ในย่านความถี่เพื่อหาว่าใบรับรองใดที่ถูกต้องก่อนหน้านี้ถูกเพิกถอน ในทางปฏิบัติโพรโทคอลเหล่านี้บางส่วนไม่ปลอดภัยมากและเบราว์เซอร์จำนวนมากไม่ตรวจสอบเลย
บางครั้ง CA ทั้งหมดถูกบุกรุก ตัวอย่างเช่นหากคุณต้องการเจาะระบบ Verisign และขโมยรหัสการลงชื่อรูทของพวกเขาคุณสามารถปลอมแปลงใบรับรองใด ๆในโลก โปรดสังเกตว่าสิ่งนี้ไม่เพียงส่งผลกระทบต่อลูกค้า Verisign: แม้ว่าใบรับรองของฉันจะถูกลงชื่อโดย Thawte (คู่แข่งของ Verisign) แต่นั่นก็ไม่สำคัญ ใบรับรองของฉันยังสามารถปลอมแปลงได้โดยใช้คีย์การลงนามที่ถูกบุกรุกจาก Verisign
นี่ไม่ใช่แค่ทางทฤษฎี มันเกิดขึ้นในป่า DigiNotar ถูกแฮ็คที่มีชื่อเสียงและต่อมาก็ล้มละลาย โคโมโดก็ถูกแฮ็กด้วย แต่พวกเขายังคงทำธุรกิจอย่างลึกลับมาจนถึงทุกวันนี้
แม้ว่า CA จะไม่ถูกโจมตีโดยตรง แต่ก็มีภัยคุกคามอื่น ๆ ในระบบนี้ ตัวอย่างเช่นรัฐบาลใช้การบังคับตามกฎหมายเพื่อบังคับ CA เพื่อลงนามในใบรับรองปลอมแปลง นายจ้างของคุณอาจติดตั้งใบรับรอง CA ของตัวเองลงในคอมพิวเตอร์พนักงานของคุณ ในหลาย ๆ กรณีการรับส่งข้อมูลที่คุณคาดหวังว่า "ปลอดภัย" จะสามารถมองเห็นได้ / แก้ไขได้อย่างสมบูรณ์สำหรับองค์กรที่ควบคุมใบรับรองนั้น
เปลี่ยนบางคนได้รับการแนะนำรวมทั้งConvergence , TACKและDANE
เชิงอรรถ
[1] ข้อมูลใบรับรอง TLS มีรูปแบบที่เป็นไปตามมาตรฐาน X.509 X.509 ใช้ASN.1 ("Abstract Syntax Notation # 1") ซึ่งหมายความว่าไม่ใช่รูปแบบข้อมูลไบนารี ดังนั้น X.509 ต้องเข้ารหัสเป็นรูปแบบไบนารี DER และ PEMเป็นรหัสที่ใช้กันทั่วไปสองแบบที่ฉันรู้จัก
[2] ในทางปฏิบัติโปรโตคอลจริง ๆ แล้วเปลี่ยนไปใช้การเข้ารหัสแบบสมมาตร แต่นั่นเป็นรายละเอียดที่ไม่เกี่ยวข้องกับคำถามของคุณ
[3] สันนิษฐานว่าจริง ๆ แล้ว CA ตรวจสอบว่าคุณคือใครก่อนที่จะเซ็นใบรับรองของคุณ หากพวกเขาไม่ทำเช่นนั้นฉันก็สามารถสร้างใบรับรองสำหรับ google.com และขอให้ CA ลงนามได้ ด้วยการรับรองนั้นฉันสามารถเชื่อมต่อกับ "ปลอดภัย" กับคนที่อยู่ตรงกลางกับ google.com ดังนั้นขั้นตอนการตรวจสอบจึงเป็นปัจจัยที่สำคัญมากในการดำเนินงานของ CA น่าเสียดายที่มันยังไม่ชัดเจนว่ากระบวนการตรวจสอบนี้เข้มงวดมากเพียงใดที่ CA หลายร้อยแห่งทั่วโลก
[4] ดูของ Mozilla รายการ CAs
