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

แยกความล้มเหลวออกเป็นสองส่วนก่อนแก้ไดเรกทีฟ

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

ตัวรับฟังตัวที่สองคือที่ที่ซื่อตรงสำหรับขีดจำกัดล่างที่อ่อนแอกว่า

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

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

ใบรับรองผู้ให้บริการเก่าทำลายอะไรจริงๆ

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

อ่านค่าที่เจรจากัน ไม่ใช่แบนเนอร์

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

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

ทุกข้อยกเว้นต้องมีเจ้าของและวันที่

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

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

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