ข้อมูลเกี่ยวกับใหม่ (CVE-2020-1968) ในโปรโตคอล TLS ชื่อรหัส
และอนุญาตให้กำหนดคีย์หลักเบื้องต้น (พรีมาสเตอร์) ในบางกรณี ซึ่งสามารถใช้เพื่อถอดรหัสการเชื่อมต่อ TLS รวมถึง HTTPS เมื่อสกัดกั้นการรับส่งข้อมูล (MITM) มีข้อสังเกตว่าการโจมตีนั้นยากมากสำหรับการปฏิบัติจริงและมีลักษณะทางทฤษฎีมากกว่า ในการโจมตี จำเป็นต้องมีการกำหนดค่าเฉพาะของเซิร์ฟเวอร์ TLS และความสามารถในการวัดเวลาประมวลผลของเซิร์ฟเวอร์ได้อย่างแม่นยำมาก
ปัญหาปรากฏโดยตรงในข้อกำหนด TLS และมีผลเฉพาะกับการเชื่อมต่อที่ใช้การเข้ารหัสตามโปรโตคอลการแลกเปลี่ยนคีย์ DH (Diffie-Hellman, TLS_DH_*") เมื่อใช้การเข้ารหัส ECDH ปัญหาจะไม่เกิดขึ้นและยังคงปลอดภัย เฉพาะโปรโตคอล TLS สูงสุดเวอร์ชัน 1.2 เท่านั้นที่มีช่องโหว่ TLS 1.3 ไม่ได้รับผลกระทบจากปัญหา ช่องโหว่นี้เกิดขึ้นในการใช้งาน TLS ที่ใช้คีย์ลับ DH ซ้ำในการเชื่อมต่อ TLS ต่างๆ (ลักษณะการทำงานนี้เกิดขึ้นบนประมาณ 4.4% ของเซิร์ฟเวอร์ Alexa Top 1M)
ใน OpenSSL 1.0.2e และรุ่นก่อนหน้า คีย์หลัก DH จะถูกนำมาใช้ซ้ำในการเชื่อมต่อเซิร์ฟเวอร์ทั้งหมด เว้นแต่ว่าตัวเลือก SSL_OP_SINGLE_DH_USE จะถูกตั้งค่าไว้อย่างชัดเจน ตั้งแต่ OpenSSL 1.0.2f คีย์หลัก DH จะถูกนำมาใช้ซ้ำเมื่อใช้การเข้ารหัส DH แบบคงที่เท่านั้น ("DH-*" เช่น "DH-RSA-AES256-SHA") ช่องโหว่นี้ไม่ปรากฏใน OpenSSL 1.1.1 เนื่องจากสาขานี้ไม่ได้ใช้คีย์หลัก DH และไม่ได้ใช้การเข้ารหัส DH แบบคงที่
เมื่อใช้วิธีการแลกเปลี่ยนคีย์ DH การเชื่อมต่อทั้งสองด้านจะสร้างคีย์ส่วนตัวแบบสุ่ม (ต่อไปนี้จะเรียกว่าคีย์ “a” และคีย์ “b”) โดยขึ้นอยู่กับการคำนวณและส่งคีย์สาธารณะ (ga mod p และ gb mod p) หลังจากที่แต่ละฝ่ายได้รับคีย์สาธารณะ จะมีการคำนวณคีย์หลักทั่วไป (gab mod p) ซึ่งใช้ในการสร้างคีย์เซสชัน การโจมตี Raccoon ช่วยให้คุณสามารถระบุคีย์หลักผ่านการวิเคราะห์ช่องทางด้านข้าง โดยอิงตามข้อเท็จจริงที่ว่าข้อกำหนด TLS จนถึงเวอร์ชัน 1.2 กำหนดให้ไบต์ว่างนำหน้าทั้งหมดของคีย์หลักถูกละทิ้งก่อนที่จะทำการคำนวณที่เกี่ยวข้อง
การรวมคีย์หลักที่ถูกตัดทอนจะถูกส่งไปยังฟังก์ชันการสร้างคีย์เซสชัน ซึ่งขึ้นอยู่กับฟังก์ชันแฮชที่มีความล่าช้าต่างกันเมื่อประมวลผลข้อมูลที่ต่างกัน การวัดระยะเวลาของการดำเนินการหลักอย่างแม่นยำที่ดำเนินการโดยเซิร์ฟเวอร์ช่วยให้ผู้โจมตีสามารถระบุเบาะแส (oracle) ที่ทำให้สามารถตัดสินได้ว่าคีย์หลักเริ่มต้นจากศูนย์หรือไม่ ตัวอย่างเช่น ผู้โจมตีสามารถสกัดกั้นกุญแจสาธารณะ (ga) ที่ส่งโดยไคลเอนต์ ส่งอีกครั้งไปยังเซิร์ฟเวอร์ และพิจารณา
ไม่ว่าคีย์หลักที่เป็นผลลัพธ์จะเริ่มต้นจากศูนย์หรือไม่
โดยตัวมันเอง การกำหนดคีย์หนึ่งไบต์ไม่ได้ให้อะไรเลย แต่โดยการสกัดกั้นค่า "ga" ที่ส่งโดยไคลเอนต์ในระหว่างการเจรจาการเชื่อมต่อ ผู้โจมตีสามารถสร้างชุดของค่าอื่น ๆ ที่เกี่ยวข้องกับ "ga" และส่งไปที่ เซิร์ฟเวอร์ในเซสชันการเจรจาการเชื่อมต่อที่แยกจากกัน ด้วยการสร้างและส่งค่า “gri*ga” ผู้โจมตีสามารถกำหนดค่าที่นำไปสู่การรับคีย์หลักโดยเริ่มจากศูนย์ผ่านการวิเคราะห์การเปลี่ยนแปลงความล่าช้าในการตอบสนองของเซิร์ฟเวอร์ เมื่อกำหนดค่าดังกล่าวแล้ว ผู้โจมตีสามารถสร้างชุดสมการได้ และคำนวณคีย์หลักดั้งเดิม
ช่องโหว่ OpenSSL ระดับอันตรายต่ำ และการแก้ไขลดลงเป็นการย้ายรหัสที่มีปัญหา “TLS_DH_*” ในรุ่น 1.0.2w ไปยังหมวดหมู่รหัสที่มีระดับการป้องกันไม่เพียงพอ (“รหัสอ่อนแอ SSL”) ซึ่งถูกปิดใช้งานตามค่าเริ่มต้น . นักพัฒนา Mozilla ก็ทำแบบเดียวกัน ในไลบรารี NSS ที่ใช้ใน Firefox, ชุดการเข้ารหัส DH และ DHE ตั้งแต่ Firefox 78 รหัสที่มีปัญหาจะถูกปิดใช้งาน การสนับสนุน Chrome สำหรับ DH ถูกยกเลิกในปี 2016 ไลบรารี BearSSL, BoringSSL, Botan, Mbed TLS และ s2n ไม่ได้รับผลกระทบจากปัญหานี้ เนื่องจากไม่รองรับการเข้ารหัส DH หรือรูปแบบคงที่ของการเข้ารหัส DH
ปัญหาเพิ่มเติมจะถูกบันทึกไว้แยกกัน () ในสแต็ก TLS ของอุปกรณ์ F5 BIG-IP ทำให้การโจมตีสมจริงยิ่งขึ้น โดยเฉพาะอย่างยิ่ง มีการระบุความเบี่ยงเบนในลักษณะการทำงานของอุปกรณ์เมื่อมีไบต์เป็นศูนย์ที่จุดเริ่มต้นของคีย์หลัก ซึ่งสามารถนำมาใช้แทนการวัดเวลาแฝงที่แน่นอนของการคำนวณ
ที่มา: opennet.ru