ca md too weak: ออกใบรับรองใหม่หรือลดระดับลง?

OpenVPN ไคลเอนต์ที่ทำงานได้เมื่อเดือนก่อนตอนนี้ล้มเหลวตอนเริ่มต้นด้วย ca md too weak, และโปรไฟล์บนดิสก์เหมือนกับตัวที่ทำงานได้ทุกไบต์ ข้อความเกี่ยวกับลายเซ็นบนใบรับรองของหน่วยออกใบรับรอง ไม่ใช่รหัสลับข้อมูล ไดเจสต์ auth หรือรหัสผ่านบัญชี เงื่อนไขสามข้อตัดสินว่าการแก้ไขคือข้อมูลระบุตัวตนใหม่ ห่วงโซ่ใหม่ หรือการเปลี่ยนนโยบายโดยเจตนา ทำตามลำดับ แล้วคุณจะหลีกเลี่ยงผลลัพธ์ปกติที่อุโมงค์กลับมาได้ด้วยการทำให้ทุกการเชื่อมต่อ TLS บนโฮสต์อ่อนแอลง

ข้อผิดพลาดระบุอะไรจริง ๆ

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

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

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

เงื่อนไขแรก: วัตถุที่ถูกปฏิเสธคือรากหรือไม่

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

ไฟล์ CA ที่รวมกันมักมีหลายบล็อก ดังนั้นจงระบุบล็อกที่โหลดจริงแทนที่จะถือว่าอันแรกเป็นผู้ผิด คำสั่ง openssl x509 -in ca.pem -noout -subject -issuer -text อธิบายใบรับรองทีละใบ ซึ่งหมายความว่าต้องแยกชุดก่อนหากมีมากกว่าหนึ่ง เปรียบเทียบอัลกอริทึมลายเซ็นที่พิมพ์กับไดเจสต์ที่คุณคาดหวังจากยุคที่รากถูกสร้าง

ใบปลายทางที่ลงลายเซ็นด้วย SHA-256 ใต้รากที่อ่อนแอยังคงล้มเหลว เพราะการตรวจห่วงโซ่ไล่ขึ้นไปจนสุด ลำดับนั้นคือสิ่งที่ทำให้เงื่อนไขถัดไปสำคัญ

เงื่อนไขที่สอง: คุณควบคุมผู้ออกหรือไม่

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

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

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

เงื่อนไขที่สาม: การลดระดับยอมรับอะไรอีก

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

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

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

การตัดสินใจ เขียนเป็นกฎ

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

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