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

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

ทำไมการตั้งค่าทั้งสองจึงดูเกี่ยวข้องกัน

การกำหนดค่า OpenVPN แบบเก่าต้องการไฟล์พารามิเตอร์ DH เพราะ Diffie-Hellman บนฟิลด์จำกัดต้องใช้พารามิเตอร์โดเมนที่ทั้งสองฝ่ายเห็นชอบ dh ชี้ไปที่ไฟล์นั้น เมื่อการติดตั้งย้ายไปใช้ ECDH พารามิเตอร์กลับมาจากเส้นโค้งที่มีชื่อแทน ไฟล์จึงไม่จำเป็นอีกต่อไป ซึ่งเป็นสิ่งที่ dh none แสดงออก

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

การตั้งชื่อทำให้การทับซ้อนแย่ลง เส้นโค้งวงรีปรากฏทั้งในชื่อชุด ECDHE และ ECDSA จึงง่ายที่จะสันนิษฐานว่าการเชื่อมต่อใดที่กล่าวถึงเส้นโค้งต้องมีใบรับรองเส้นโค้ง ไม่เป็นเช่นนั้น

วิธีอ่านชื่อชุด TLS 1.2 อย่างถูกต้อง

ลองดู ECDHE-RSA-AES256-GCM-SHA384 โทเคนแรกคือตระกูลแลกเปลี่ยนคีย์ ได้แก่ Diffie-Hellman ชั่วคราวบนเส้นโค้งวงรี ตัวที่สองคือตระกูลพิสูจน์ตัวตน ได้แก่ RSA ส่วนที่เหลืออธิบายการป้องกันบันทึกและแฮชที่ใช้ใน handshake

ชุด ECDHE-ECDSA ใช้ตระกูลแลกเปลี่ยนคีย์เดียวกันกับวิธีพิสูจน์ตัวตนที่ต่างออกไป จึงต้องใช้ใบรับรองเส้นโค้งวงรี ชุด DHE-RSA ใช้ Diffie-Hellman ชั่วคราวบนฟิลด์จำกัดพร้อมการพิสูจน์ตัวตน RSA และชุดนั้นต้องใช้พารามิเตอร์ DH จริง ๆ

อ่านชื่อชุดจากซ้ายไปขวาแล้วกำหนดแต่ละส่วนให้กับงานของมัน เมื่อแยกโทเคนออกแล้ว คำถามจะเปลี่ยนจาก «ใบรับรองของฉันตรงกับ dh none หรือไม่» เป็น «เซิร์ฟเวอร์ของฉันอนุญาตชุดที่การแลกเปลี่ยนคีย์ไม่ต้องใช้ไฟล์ DH หรือไม่»

dh none ปิดใช้งานอะไรจริง ๆ

dh none บอกเซิร์ฟเวอร์ว่าอย่าโหลดไฟล์พารามิเตอร์ DH บนฟิลด์จำกัด ไม่ได้ปิดการพิสูจน์ตัวตน การตรวจสอบใบรับรอง หรือ TLS เอง แต่กำหนดให้การแลกเปลี่ยนคีย์ที่เจรจาไว้ไม่ต้องใช้พารามิเตอร์เหล่านั้น ซึ่งในทางปฏิบัติหมายถึงชุด ECDHE หรือ handshake TLS 1.3

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

ในฝั่งเส้นโค้งวงรี เส้นโค้งถูกเลือกโดยการกำหนดค่า TLS ของเซิร์ฟเวอร์ และ OpenVPN มีตัวเลือกให้เลือกบนสาขาเก่า TLS 1.3 จัดการการเจรจากลุ่มภายในโปรโตคอลและไม่ดูไฟล์ DH เลย

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

ยืนยันการเจรจาก่อนแก้ไข

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

หากแสดง TLS 1.2 พร้อมชุด ECDHE-RSA และใบรับรอง RSA การรวมกันนั้นตรงกับที่ dh none คาดหวัง และไม่มีอะไรต้องซ่อม หากแสดงชุด DHE หรือความล้มเหลวของ handshake โดยไม่มีชุดรหัสร่วม วิธีแก้อยู่ที่นโยบายชุดรหัสหรือความสามารถของไคลเอนต์ ไม่ใช่ที่ใบรับรอง

ทดสอบไคลเอนต์ที่เก่าที่สุดที่คุณตั้งใจจะรองรับ เพราะไคลเอนต์ปัจจุบันอาจเจรจา TLS 1.3 ได้ ในขณะที่ไคลเอนต์เก่ากว่าจำกัดอยู่ที่ชุด TLS 1.2 หากไคลเอนต์ที่เก่าที่สุดไม่มีการทับซ้อน ให้ขยายชุดที่อนุญาตหรืออัปเกรดปลายทางนั้น

อย่าปิดการตรวจสอบใบรับรองเพื่อข้ามความล้มเหลวของ handshake ความล้มเหลวนั้นบอกคุณว่าฝ่ายต่าง ๆ ไม่สามารถตกลงการแลกเปลี่ยนคีย์ได้ และการปิดการตรวจสอบจะลบการรับประกันตัวตนโดยไม่แก้ไขข้อตกลง

รายการตรวจสอบ: ใบรับรองเป็น RSA หรือไม่ อนุญาตชุด ECDHE หรือไม่ บันทึกแสดงชุดนั้นหรือไม่ และไคลเอนต์ที่รองรับเก่าที่สุดก็เจรจาชุดนั้นด้วยหรือไม่ หากทั้งสี่ข้อใช่ dh none กำลังทำงานของมัน

บทความที่เกี่ยวข้อง