ข้อผิดพลาดรหัสลับ TLS ของ OpenVPN: เทียบทั้งสองฝั่งก่อน

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

ถ้าจัดลำดับผิด อาจเสียเวลาหนึ่งชั่วโมงเพิ่มชื่อ AES ลงในรายการที่ไม่เคยถูกเปิดดูเลย

รายการรหัสลับสองรายการ และมีเพียงรายการเดียวที่ทำให้แฮนด์เชกล้มเหลว

ช่องควบคุมเจรจาเซสชัน TLS และนโยบายของช่องนี้เขียนด้วย tls-cipher สำหรับ TLS 1.2 และ tls-ciphersuites สำหรับ TLS 1.3 ช่องข้อมูลถูกกำหนดค่าแยกด้วย data-ciphers ซึ่งความไม่ตรงกันทำให้เกิดการเชื่อมต่อที่สร้างสำเร็จแล้วแต่อุโมงค์ส่งข้อมูลผ่านไม่ได้ ทั้งสองฝั่งสร้างข้อผิดพลาดที่กล่าวถึงรหัสลับ จึงมักถูกสับสน แฮนด์เชกที่ไม่เคยเสร็จสิ้นชี้ไปที่ช่องควบคุม ขณะที่อุโมงค์ที่สร้างแล้วแต่ทิ้งแพ็กเก็ตชี้ไปที่ช่องข้อมูล

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

เทียบเวอร์ชันก่อนเทียบชุดรหัส

ฝั่งที่จำกัดไว้ที่ TLS 1.2 กับฝั่งที่ต้องการ 1.3 ไม่มีเวอร์ชันร่วมกัน และไม่มีสตริงรหัสลับใดเชื่อมช่องว่างนี้ได้ บันทึก tls-version-min และ tls-version-max ทั้งสองฝั่ง หรือค่าเริ่มต้นของบิลด์ที่ใช้งานอยู่ เพราะนโยบาย OpenSSL ของดิสทริบิวชันอาจยกพื้นขั้นต่ำขึ้นโดยไม่มีตัวเลือกใดของ OpenVPN บอกไว้ ถ้าฝั่งหนึ่งเป็นอุปกรณ์หรือไคลเอนต์ของบุคคลที่สาม หน้าต่างของมันคือสิ่งที่เฟิร์มแวร์อนุญาต การเทียบชุดรหัสจึงมีความหมายก็ต่อเมื่อหน้าต่างทั้งสองทับซ้อนกัน

บันทึกเหล่านั้นควรระบุไบนารีจริงด้วย openvpn บนคอมพิวเตอร์พกพาของคุณไม่จำเป็นต้องเป็นไคลเอนต์ที่จัดการโปรไฟล์ที่นำเข้า

รายการ TLS 1.2 และ TLS 1.3 ใช้ปนกันไม่ได้

ชื่อชุดรหัส TLS 1.2 มีลักษณะเช่น ECDHE-RSA-AES256-GCM-SHA384 และอยู่ใน tls-cipher ซึ่งรับสตริงรหัสลับของ OpenSSL ชุดรหัส TLS 1.3 มีชื่อเช่น TLS_AES_256_GCM_SHA384 และอยู่ใน tls-ciphersuites การเพิ่มชุดหนึ่งลงในสตริง 1.2 ไม่ได้กำหนดค่ารายการ 1.3 และตัวแยกวิเคราะห์อาจยอมรับข้อความโดยไม่เคยจับคู่เลย ตัวกรองที่ถูกต้องสำหรับเวอร์ชันหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกเวอร์ชัน จดไว้ว่ารายการใดมีไว้สำหรับเวอร์ชันใด

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

พิสูจน์การเจรจาบนการเชื่อมต่อใหม่

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

ถ้าไม่มีการกำหนดค่าร่วมที่ได้รับอนุมัติ คำตอบคือการอัปเกรดหรือแผนย้ายระบบ ไม่ใช่นโยบายที่อ่อนแอลง tls-version-min การลดค่า การปิดการยืนยัน หรือการเปิดชุดรหัสเก่าทั้งหมด ลบการปฏิเสธออกโดยไม่ตอบสนองข้อกำหนดด้านความปลอดภัยที่สร้างมันขึ้นมา.

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