OpenVPN tls-ciphersuites กับ tls-version-min: แต่ละอย่างบังคับอะไร

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

ตรวจสอบบิลด์ก่อนอ่านรายการใด ๆ

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

openvpn --version

บิลด์ 2.6 ที่ลิงก์กับ OpenSSL ยอมรับทั้ง tls-cipher และ tls-ciphersuites บิลด์กับ mbed TLS ไม่มีการเลือกชุด TLS 1.3 เลย และคู่มือ 2.6 ทำเครื่องหมาย tls-ciphersuites เป็นตัวเลือกของ OpenSSL หากเซิร์ฟเวอร์ถูกสร้างใหม่ด้วยแบ็กเอนด์อื่น โปรไฟล์เดิมอาจเปลี่ยนพฤติกรรมโดยไม่ต้องแก้ไขบรรทัดการกำหนดค่าแม้แต่บรรทัดเดียว

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

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

แยกขอบเขตเวอร์ชันออกจากรายการรหัส

ในคู่มือ 2.6 สิ่งเหล่านี้คือการควบคุมสามอย่าง ไม่ใช่หนึ่ง:

• tls-cipher กำหนดนโยบายรหัสสำหรับ TLS 1.2 และเก่ากว่า และส่งต่อไปยังรายการรหัสของ OpenSSL
• tls-ciphersuites เลือกชุด TLS 1.3
• tls-version-min และ tls-version-max จำกัดเวอร์ชันโปรโตคอลที่การเชื่อมต่อใช้ได้

ดังนั้นรายการชุด TLS 1.3 ที่ตัดแต่งอย่างรอบคอบไม่ได้พิสูจน์อะไรเกี่ยวกับเวอร์ชันเก่าที่ยังได้รับอนุญาต หากข้อกำหนดคือ «TLS 1.3 เท่านั้น» ขอบล่างของเวอร์ชันคือสิ่งที่รับผิดชอบ และรายการชุดเพียงจำกัดตัวเลือกภายในขอบนั้น:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

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

ช่องทางข้อมูลคือการควบคุมที่สี่ data-ciphers เจรจารหัสสมมาตรภายในอุโมงค์ และผลลัพธ์ไม่ได้บอกอะไรเกี่ยวกับเวอร์ชัน TLS ของช่องทางควบคุม การเห็น AES-256-GCM ในสรุปเซสชันไม่ใช่หลักฐานเกี่ยวกับ TLS 1.3 ในทิศทางใด

อ่าน show-tls เป็นรายการท้องถิ่น

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

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

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

ถามเกตเวย์ในสิ่งที่มันตอบได้

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

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

การชี้ openssl s_client ไปที่พอร์ต VPN ก็ไม่ได้จำลองคำถามเช่นกัน ช่องทางควบคุมทำงานภายในกรอบของ OpenVPN เอง ดังนั้นการตรวจสอบ TLS แบบดิบจึงทดสอบโปรโตคอลอื่นบนพอร์ตที่คาดหวังอย่างอื่น ข้อสรุปใด ๆ จากสิ่งนั้นจึงเป็นเรื่องของการตรวจสอบ ไม่ใช่ของอุโมงค์

บันทึกผลลัพธ์สองอย่างและแยกออกจากกัน

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

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

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

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