SSL และความเข้าใจผิดแบบคนตรงกลาง

ฉันได้อ่านเอกสารที่เกี่ยวข้องกับปัญหานี้มากมาย แต่ฉันยังไม่สามารถรวบรวมทุกส่วนเข้าด้วยกันได้ดังนั้นฉันจึงอยากถามคำถามสองสามข้อ

1. ก่อนอื่นฉันจะอธิบายสั้น ๆ เกี่ยวกับขั้นตอนการรับรองความถูกต้องตามที่ฉันเข้าใจเนื่องจากฉันอาจเข้าใจผิดในเรื่องนั้น: ไคลเอนต์เริ่มการเชื่อมต่อซึ่งเซิร์ฟเวอร์ตอบสนองด้วยการรวมกันของคีย์สาธารณะข้อมูลเมตาและลายเซ็นดิจิทัลของ ผู้มีอำนาจที่เชื่อถือได้ จากนั้นไคลเอ็นต์จะตัดสินใจว่าเธอเชื่อถือเซิร์ฟเวอร์หรือไม่เข้ารหัสคีย์เซสชันแบบสุ่มด้วยคีย์สาธารณะและส่งกลับ รหัสเซสชันนี้สามารถถอดรหัสได้ด้วยคีย์ส่วนตัวที่เก็บไว้บนเซิร์ฟเวอร์เท่านั้น เซิร์ฟเวอร์ทำสิ่งนี้แล้วเซสชัน HTTPS จะเริ่มขึ้น

2. ดังนั้นถ้าฉันพูดถูกต้องข้างต้นคำถามคือการโจมตีแบบคนตรงกลางสามารถเกิดขึ้นได้อย่างไรในสถานการณ์เช่นนี้? ฉันหมายถึงแม้ว่าจะมีคนขัดขวางการตอบสนองของเซิร์ฟเวอร์ (เช่น www.server.com) ด้วยคีย์สาธารณะและมีวิธีการบางอย่างที่ทำให้ฉันคิดว่าเขาเป็น www.server.com เขาก็ยังไม่สามารถถอดรหัสคีย์เซสชันของฉันได้ ไม่มีคีย์ส่วนตัว

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

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

การโจมตีแบบคนตรงกลางบน SSL จะเกิดขึ้นได้ก็ต่อเมื่อเงื่อนไขเบื้องต้นข้อใดข้อหนึ่งของ SSL ขัดข้องนี่คือตัวอย่างบางส่วน

• คีย์เซิร์ฟเวอร์ถูกขโมย - หมายความว่าผู้โจมตีอาจดูเหมือนเป็นเซิร์ฟเวอร์และไม่มีทางที่ไคลเอ็นต์จะรู้ได้

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

• ลูกค้าไม่ต้องกังวลในการตรวจสอบใบรับรองอย่างถูกต้องกับรายการ CA ที่เชื่อถือได้ - ทุกคนสามารถสร้าง CA ได้ หากไม่มีการตรวจสอบความถูกต้อง "รถยนต์และใบรับรองของเบ็น" จะถูกต้องเช่นเดียวกับ Verisign

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

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

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

เซิร์ฟเวอร์ตอบสนองด้วยห่วงโซ่ใบรับรอง X.509 และลายเซ็นดิจิทัลที่เซ็นชื่อด้วยคีย์ส่วนตัวของตัวเอง

จากนั้นลูกค้าจะตัดสินใจว่าเธอไว้วางใจเซิร์ฟเวอร์หรือไม่

แก้ไข.

เข้ารหัสคีย์เซสชันแบบสุ่มด้วยคีย์สาธารณะและส่งกลับ

ไม่ไคลเอ็นต์และเซิร์ฟเวอร์มีส่วนร่วมในกระบวนการสร้างคีย์เซสชันร่วมกันโดยที่คีย์เซสชันจะไม่ถูกส่งเลย

รหัสเซสชันนี้สามารถถอดรหัสได้ด้วยคีย์ส่วนตัวที่เก็บไว้บนเซิร์ฟเวอร์เท่านั้น

ไม่

เซิร์ฟเวอร์ทำสิ่งนี้

ไม่

จากนั้นเซสชัน HTTPS จะเริ่มขึ้น

TLS / SSLเซสชั่นเริ่มต้น แต่มีขั้นตอนมากขึ้นเป็นครั้งแรก

ดังนั้นถ้าฉันพูดถูกต้องข้างต้นคำถามคือการโจมตีแบบคนกลางเกิดขึ้นได้อย่างไรในสถานการณ์เช่นนี้?

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

ฉันหมายความว่าแม้ว่าจะมีคนขัดขวางการตอบสนองของเซิร์ฟเวอร์ (เช่น www.server.com) ด้วยคีย์สาธารณะและด้วยวิธีการบางอย่างให้ฉันคิดว่าเขาเป็น www.server.com เขาก็ยังไม่สามารถถอดรหัสคีย์เซสชันของฉันได้ ไม่มีคีย์ส่วนตัว

ดูด้านบน. ไม่มีคีย์เซสชันในการถอดรหัส การเชื่อมต่อ SSL นั้นมีความปลอดภัยผู้ที่คุณกำลังคุยด้วยอาจไม่ปลอดภัย

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

แก้ไข.

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

ไม่

อะไรคือข้อเสียของวิธีการดังกล่าวเมื่อเปรียบเทียบกับการพิสูจน์ตัวตนร่วมกัน (เฉพาะปัญหาด้านความปลอดภัยเท่านั้นที่สำคัญไม่ใช่ความซับซ้อนของการนำไปใช้งาน)

มีความปลอดภัยพอ ๆ กับชื่อผู้ใช้ / รหัสผ่านเท่านั้นซึ่งจะรั่วไหลได้ง่ายกว่าคีย์ส่วนตัวมาก

ใครก็ตามที่อยู่บนท้องถนนระหว่างไคลเอนต์และเซิร์ฟเวอร์สามารถทำให้ชายคนหนึ่งโจมตีกลาง https ได้ หากคุณคิดว่าสิ่งนี้ไม่น่าเกิดขึ้นหรือหายากให้พิจารณาว่ามีผลิตภัณฑ์เชิงพาณิชย์ที่ถอดรหัสสแกนและเข้ารหัสทราฟฟิก ssl ทั้งหมดผ่านเกตเวย์อินเทอร์เน็ตอย่างเป็นระบบ. พวกเขาทำงานโดยการส่งใบรับรอง ssl ให้กับลูกค้าที่สร้างขึ้นทันทีพร้อมกับรายละเอียดที่คัดลอกมาจากใบรับรอง ssl "จริง" แต่ลงนามด้วยสายการรับรองอื่น หากเครือข่ายนี้สิ้นสุดลงพร้อมกับ CA ที่เชื่อถือได้ของเบราว์เซอร์ผู้ใช้ MITM นี้จะมองไม่เห็น ผลิตภัณฑ์เหล่านี้ส่วนใหญ่ขายให้กับ บริษัท ต่างๆเพื่อ "รักษาความปลอดภัย" (ตำรวจ) เครือข่ายองค์กรและควรใช้ด้วยความรู้และความยินยอมของผู้ใช้ ในทางเทคนิคแล้วไม่มีอะไรหยุดการใช้งานโดย ISP หรือผู้ให้บริการเครือข่ายอื่น ๆ (คงจะปลอดภัยถ้าสมมติว่า NSA มีคีย์การลงนาม CA root ที่เชื่อถือได้อย่างน้อยหนึ่งคีย์ )

หากคุณกำลังให้บริการเพจคุณสามารถใส่ส่วนหัว HTTP เพื่อระบุว่าเพจควรเซ็นชื่อด้วยคีย์สาธารณะใด ซึ่งอาจช่วยแจ้งเตือนผู้ใช้ให้ทราบถึง MITM ของการเชื่อมต่อที่ "ปลอดภัย" แต่เป็นเทคนิคที่เชื่อถือได้เมื่อใช้งานครั้งแรก ถ้า Bob ยังไม่มีบันทึกพินคีย์สาธารณะ "จริง" Mallory จะเขียนส่วนหัว pkp ในเอกสารใหม่ รายชื่อเว็บไซต์ที่ใช้เทคโนโลยีนี้ (HPKP) สั้นมาก ซึ่งรวมถึง Google และ Dropbox ไว้ในเครดิต โดยปกติเกตเวย์ดักฟัง https จะส่งผ่านหน้าเว็บจากไซต์ที่เชื่อถือได้ขนาดใหญ่เพียงไม่กี่แห่งที่ใช้ HPKP หากคุณพบข้อผิดพลาด HPKP โดยที่คุณไม่คาดคิดโปรดระวัง

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

1. แก้ไข
2. ไม่ถูกต้อง ในการโจมตีแบบนั้นเซิร์ฟเวอร์ itermediate ได้รับคำขอของคุณและส่งไปยังปลายทางในนามของคุณ จากนั้นตอบกลับคุณพร้อมผลลัพธ์ จริงๆแล้วมันเป็นเซิร์ฟเวอร์แบบ man-in-the-middle ซึ่งทำให้การเชื่อมต่อที่ปลอดภัยกับคุณไม่ใช่เซิร์ฟเวอร์จริงที่คุณตั้งใจจะสื่อสาร นั่นคือเหตุผลที่คุณต้องตรวจสอบใบรับรองว่าถูกต้องและเชื่อถือได้เสมอ
3. อาจจะถูกต้อง
4. หากคุณแน่ใจว่าการเชื่อมต่อที่ปลอดภัยเชื่อถือได้ b จะปลอดภัยที่จะส่งชื่อผู้ใช้ / รหัสผ่าน

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