OpenVPN: EC กับ ED — ทำไมชื่อเหล่านี้ไม่ใช่ขั้นบันไดของความแข็งแกร่ง

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

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

สองตัวอักษร สองคำถามที่ต่างกัน

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

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

การลงลายมือชื่อกับการแลกกุญแจเป็นงานคนละอย่าง

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

EdDSA กับ ECDSA ต่างก็ลงลายมือชื่อ แต่เป็นแผนที่ต่างกันและมีรูปแบบกุญแจต่างกัน ดังนั้น ใบรับรองที่ออกให้อันหนึ่งจึงใช้แทนอีกอันไม่ได้ EdDSA ถูกนิยามสำหรับชุดเส้นโค้งเล็ก ๆ และ P-256 ไม่ได้อยู่ในชุดนั้น นี่คือเหตุผลที่ใบรับรอง P-256 ตรวจสอบได้ด้วย ECDSA และไม่เคยตรวจสอบได้ด้วย Ed25519

คอลัมน์การแลกเปลี่ยนไม่มีสิ่งที่เทียบเท่าที่ชื่อ EdDH การตกลงชั่วคราวบนกุญแจ Curve25519 คือ X25519 และนั่นคือ ECDH ที่ใช้เส้นโค้งหนึ่งโดยเฉพาะ เช่นเดียวกับที่ใช้กับ P-256 Ed25519 หมายถึงแผนลงลายมือชื่ออย่างเคร่งครัด แม้ว่าชื่อนี้จะถูกใช้อย่างหลวม ๆ กับการแลกเปลี่ยนด้วย เพราะเส้นโค้งทั้งสองเกี่ยวข้องกัน รูปแบบ Edwards ที่ใช้ลงลายมือชื่อกับรูปแบบ Montgomery ที่ใช้กับ X25519 อธิบายกลุ่มพื้นฐานเดียวกัน

ทำไมโปรไฟล์ EC จึงไม่มีไฟล์ dh

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

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

TLS 1.3 ตัดการแลกเปลี่ยนกุญแจออกจากชื่อ

เทียบ TLS_AES_256_GCM_SHA384 กับ TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 แล้วชื่อที่สั้นกว่าดูเหมือนเป็นการลดระดับ มันคือการเปลี่ยนชื่อ และเหตุผลเป็นเชิงโครงสร้าง เพราะ TLS 1.3 ตัด RSA แบบคงที่และการแลกเปลี่ยนกุญแจ Diffie-Hellman แบบฟิลด์จำกัดออก การแลกเปลี่ยนแบบเส้นโค้งวงรีชั่วคราวจึงเหลือเป็นตัวเลือกเดียวที่ไม่ใช่ PSK การระบุชื่อนั้นในทุกชุดรหัสจะเป็นการพูดข้อเท็จจริงเดิมซ้ำหลายสิบครั้ง

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

มีข้อสรุปหนึ่งที่ควรพูดตรง ๆ ECDHE เป็นอัลกอริทึมแลกเปลี่ยนกุญแจและไม่เคยเป็นรหัสลับ ชุดรหัสที่ถูกอธิบายว่า “วงรี” บอกบางอย่างเกี่ยวกับวิธีที่สองฝ่ายไปถึงกุญแจร่วมกัน และไม่บอกอะไรเลยเกี่ยวกับสิ่งที่เข้ารหัสเพย์โหลดหลังจากนั้น

auth รับรองแพ็กเก็ต ไม่ใช่เพย์โหลด

คำสั่ง auth เลือกไดเจสต์ HMAC ที่ใช้รับรองแพ็กเก็ต และค่าเริ่มต้นตามประวัติคือ SHA1 เมื่อใช้รหัสลับข้อมูลที่ไม่ใช่ AEAD OpenVPN จะคำนวณไดเจสต์บนข้อความเข้ารหัสแล้วต่อท้าย ซึ่งเป็นการจัดเรียงแบบเข้ารหัสก่อนแล้วจึงทำ MAC และนั่นคือสิ่งที่ทำให้การจัดการแพดดิงทำได้ยากในทางปฏิบัติ

ความเชื่อผิดตรงนี้คือการเพิ่ม auth เป็น SHA512 จะทำให้อุโมงค์แข็งแกร่งขึ้น มันไม่ได้เพิ่มความแข็งแกร่งของการเข้ารหัส และถ้ารหัสลับข้อมูลที่ตกลงกันเป็นโหมด AEAD เช่น AES-256-GCM ไดเจสต์ก็ไม่ได้ถูกนำไปใช้กับแพ็กเก็ตข้อมูลเลย แท็ก GCM รับรองแพ็กเก็ตเหล่านั้นอยู่แล้ว และค่า auth ถูกเหลือไว้สำหรับ HMAC ของช่องควบคุมและสำหรับรหัสลับอื่นที่ไม่ใช่ AEAD ที่ยังใช้อยู่

ดังนั้นคำสั่งนี้สำคัญ แต่มันสำคัญในจุดที่แคบกว่าตำแหน่งของมันในไฟล์ การตรวจสอบว่าแท้จริงแล้วตกลงรหัสลับใดจะบอกคุณว่ามันมีผลหรือไม่

อ่านโปรไฟล์ตามคอลัมน์ ไม่ใช่ตามอันดับ

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

ไม่มีอะไรในป้าย EC หรือ ED ตัดสินข้อใดในสามข้อนั้น และชื่อชุดรหัสเพียงลำพังก็ไม่ได้ตัดสินข้อใดเลย ผลลัพธ์ที่ตกลงกันคือหลักฐานเดียว ดังนั้นจงอ่านสิ่งนั้นแทนการอนุมานความแข็งแกร่งจากถ้อยคำ

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

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