Score:1

การใช้พารามิเตอร์ DH ที่กำหนดเองสำหรับการถอดรหัส TLS

ธง mc

มีหลายวิธีในการถอดรหัส TLS เช่น ในสภาพแวดล้อมขององค์กร ฉันไม่เห็นการใช้พารามิเตอร์ DH "ลับๆ" ที่กล่าวถึงที่ไหนสักแห่ง แต่ตามความเข้าใจของฉันมันควรจะใช้งานได้ตามหลักการ: โมดูลัสที่ไม่ใช่ไพรม์สำหรับ Diffie-Hellman ยอมให้มีแบ็คดอร์ได้อย่างไร

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

dave_thompson_085 avatar
cn flag
[ผู้วิจัย Logjam ในปี 2015](https://weakdh.org/) พบบางไซต์ใช้ DH แบบ 512 บิต (ซึ่งไซต์เหล่านี้เสียหาย) แม้ว่าจะไม่ตั้งใจดาวน์เกรดก็ตาม และอีกหลายแห่งใช้ 768 บิต (ซึ่งถือว่าแตกหักได้ในระดับปานกลาง ค่าใช้จ่าย). แน่นอนว่าสิ่งเหล่านี้ไม่ได้ถูกซ่อนไว้เหมือน 'ประตูหลัง' ตามปกติ แต่คนส่วนใหญ่ (และผู้ดูแลระบบ) ที่ไม่สนใจเรื่องความปลอดภัยจะไม่มีใครสังเกตเห็นจนกว่าจะถูกบุกรุก
Score:1
ธง my

เป็นไปได้ไหมที่ CPU เดสก์ท็อปล่าสุดจะถอดรหัสทราฟฟิกแบบเรียลไทม์ (เกือบ)

หากคุณถามเฉพาะเจาะจงเกี่ยวกับกลุ่ม DH แบ็คดอร์ ถ้าคุณใช้ TLS เวอร์ชันที่อนุญาตให้เซิร์ฟเวอร์ [1] เสนอกลุ่ม DH ที่ไม่เป็นมาตรฐาน (และไคลเอ็นต์จะยอมรับกลุ่มนั้น คนปกติจะไม่ยอมรับ) ใช่แล้ว มันสามารถเสนอกลุ่มที่อ่อนแอมาก (เช่นกลุ่มที่ $p-1$ ไม่มีปัจจัยขนาดใหญ่) และสิ่งนี้จะทำให้การกู้คืนความลับที่ใช้ร่วมกัน (และด้วยเหตุนี้คีย์การรับส่งข้อมูล) จึงเป็นเรื่องง่าย

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

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

[1]: ฉัน คิด เป็นเซิร์ฟเวอร์ที่เสนอกลุ่ม DH ใน TLS 1.2; ถ้าไม่เพียงแค่สลับไคลเอนต์และเซิร์ฟเวอร์ในอาร์กิวเมนต์ด้านบน

dave_thompson_085 avatar
cn flag
สำหรับ TLS1.0-1.2 _without_ RFC7919, _if_ ไคลเอนต์เสนอและเซิร์ฟเวอร์ยอมรับชุดการเข้ารหัสโดยใช้ (FF)DHE เซิร์ฟเวอร์เลือกกลุ่มและไคลเอ็นต์ต้องปฏิบัติตามหรือยกเลิกการจับมือ ด้วย 7919 ไคลเอนต์สามารถร้องขอกลุ่มมาตรฐาน (สไตล์ Oakley) ได้ แต่เซิร์ฟเวอร์ยังสามารถเลือกอย่างอื่นได้ ซึ่งในกรณีนี้ไคลเอนต์อาจยกเลิก ฉันไม่รู้อะไรที่ใช้ 7919 โดยไม่ได้ใช้งาน TLS1.3 ซึ่งไม่เพียง แต่ XXDHE 'ส่งต่อ' (ไคลเอนต์เสนอคีย์แชร์ไปยังเซิร์ฟเวอร์) แต่ยังดีกว่าด้วยเหตุผลอื่น
Score:0

ในโปรโตคอล TLS เซิร์ฟเวอร์จะตัดสินใจเลือกกลุ่มสำหรับการแลกเปลี่ยนคีย์: กลุ่ม Diffie-Hellman ที่มีขอบเขตจำกัดหรือเส้นโค้งวงรี เซิร์ฟเวอร์ต้องเลือกภายในข้อจำกัดที่กำหนดโดยไคลเอนต์ ใน TLS 1.3 มีการระบุกลุ่มจากรายการกลุ่มมาตรฐานเล็กๆ โปรโตคอลเวอร์ชันก่อนหน้าอนุญาตให้เซิร์ฟเวอร์อธิบายกลุ่มที่กำหนดเองได้ สำหรับเส้นโค้งวงรี จะไม่ค่อยรองรับ: ซอฟต์แวร์ส่วนใหญ่รองรับเฉพาะเส้นโค้งที่มีชื่อ แต่สำหรับ Diffie-Hellman ที่มีเขตข้อมูลจำกัด ไคลเอนต์แบบคลาสสิกจะจำกัดขนาดของกลุ่มเท่านั้น และเซิร์ฟเวอร์จะส่งค่าตัวเลขของพารามิเตอร์ แม้ว่าซอฟต์แวร์ส่วนใหญ่ในปัจจุบันจะสนับสนุนส่วนขยาย NamedGroup แต่ไคลเอ็นต์ส่วนใหญ่จะยอมรับค่าตัวเลขสำหรับความเข้ากันได้แบบย้อนกลับ ดังนั้น ลูกค้าอาจถูกหลอกให้ยอมรับพารามิเตอร์ FFDH ที่เป็นแบ็คดอร์

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

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

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

poncho avatar
my flag
อันที่จริง มีรูปแบบภัยคุกคามที่สาม: ใครก็ตามที่ทำเซิร์ฟเวอร์ไม่รู้จักการเข้ารหัสและเลือกพารามิเตอร์ DH ที่อ่อนแอโดยไม่ตั้งใจ

โพสต์คำตอบ

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