OCSP กับ CRL: การตรวจสอบการเพิกถอนแต่ละแบบทำงานจริงอย่างไร

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

ขั้นที่ 1: การตรวจสอบแต่ละแบบคืนอะไรและใช้งานได้นานแค่ไหน

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

ดังนั้นแคชจึงเป็นสิ่งแรกที่ต้องกำหนดให้ชัด: องค์ประกอบใดถือสำเนาไว้ และสำเนานั้นอยู่ภายใต้เพดานใด บนเกตเวย์เพดานควรเป็น nextUpdate ลบด้วยส่วนเผื่อความปลอดภัย ไม่ใช่สิ่งที่ส่วนหัวแคช HTTP บังเอิญเสนอ openssl crl -in issuer.crl -noout -lastupdate -nextupdate พิมพ์วันที่ทั้งสอง และ รายการที่ nextUpdate ผ่านไปแล้วต้องถือว่าขาดหายไม่ใช่แค่เก่า

ขั้นที่ 2: ใบรับรองชี้ผู้ใช้งานไปที่ใด

ใบรับรองปลายทางมักมีเบาะแสสองอย่าง: ส่วนขยายจุดกระจาย CRL และรายการเข้าถึงข้อมูลอำนาจออกใบรับรองสำหรับ OCSP openssl x509 -in client.pem -noout -ext crlDistributionPoints พิมพ์อย่างแรก ส่วนอย่างที่สองอยู่ใต้ส่วน AIA ของ openssl x509 -in client.pem -noout -text ส่วนขยายใดก็ตามเป็นเพียงตัวชี้ ไม่ใช่ข้อผูกพัน ไคลเอนต์ที่ไม่เคยใช้การตรวจสอบการเพิกถอนเลยจะเชื่อมต่อกับใบรับรองที่ส่วนขยายระบุตัวผู้ตอบที่ตายไปแล้วปีหนึ่งได้อย่างราบรื่น

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

ขั้นที่ 3: เลือก fail-closed หรือ fail-open ก่อนเกิดเหตุขัดข้อง

ผู้ตอบที่เข้าถึงไม่ได้หรือรายการที่หมดอายุบังคับให้ต้องตัดสินใจ: ปฏิเสธการเชื่อมต่อ หรือยอมรับแล้วบันทึกช่องว่างไว้ คำสั่งย่อย verify ของ OpenSSL ทำให้การเลือกแบบเข้มงวดชัดเจน เพราะการเพิ่ม -crl_check เปลี่ยน CRL ที่ใช้ไม่ได้ให้กลายเป็น unable to get certificate CRL และการตรวจสอบที่ล้มเหลว การล้มเหลวแบบอ่อนในสแตกส่วนใหญ่ไม่ใช่แฟล็กเลย มันคือการไม่มีอยู่ของการตรวจสอบ และนั่นคือเหตุผลที่มันถูกส่งออกไปโดยบังเอิญ

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

ขั้นที่ 4: พิสูจน์ว่าการตรวจสอบทำงาน ณ จุดที่รับทราฟฟิก

หาโปรเซสที่สิ้นสุดหรืออนุญาตการเชื่อมต่อ แล้วถามถึงบรรทัดคอนฟิกูเรชันที่เปิดใช้การตรวจสอบการเพิกถอน เกตเวย์ที่ตรวจสอบห่วงโซ่แต่ไม่เคยถามเรื่องการเพิกถอน ย่อมบังคับใช้นโยบายที่ต่างจากที่อยู่ในเอกสารของคุณ และไม่มีภาพหน้าจอของห่วงโซ่ใบรับรองใดพิสูจน์ตรงกันข้าม OpenVPN เขียนออปชันนี้เป็น crl-verify ส่วน strongSwan เก็บการค้นหา CRL และ OCSP ไว้ใต้คอนฟิกูเรชันของ CA ซึ่งมีการตั้ง crl_uris หรือ ocsp_uris หากคุณชี้ไปที่อย่างใดอย่างหนึ่งไม่ได้ ให้ถือว่าการตรวจสอบนั้นไม่มีอยู่

การตอบกลับ OCSP จะใช้ได้ก็ต่อเมื่อ CA ผู้ออกลงนามไว้ หรือเมื่อผู้ตอบที่ถือการใช้คีย์แบบขยาย OCSPSigning ที่ CA นั้นมอบหมายลงนามไว้ คำตอบจากบริการที่ไม่เกี่ยวข้องจึงพิสูจน์อะไรไม่ได้เลย หากคุณดูแลผู้ตอบเอง ให้เฝ้าดูมันในฐานะการพึ่งพาที่สำคัญ เพราะบริการที่ตายเพียงหนึ่งเดียวจะกลายเป็นเหตุขัดข้องสำหรับไคลเอนต์ fail-closed ทุกตัวพร้อมกัน

ขั้นที่ 5: เพิกถอนใบรับรองหนึ่งใบโดยเจตนา

นำใบรับรองทดสอบมา เพิกถอนผ่านช่องทางเดียวกับที่การผลิตใช้ แล้วถามผู้ตอบโดยตรง openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ควร รายงาน Cert Status: revoked พร้อมเวลาที่เพิกถอน และคำตอบ good หมายความว่าการเพิกถอนของคุณไปไม่ถึงผู้ตอบที่ไคลเอนต์ของคุณถาม จากนั้นรัน openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem เพื่อดูการตัดสินใจเดียวกันผ่านเส้นทางรายการ อ่านสตริงเหตุผลแทนรหัสออก เพราะการปฏิเสธเนื่องจากการเพิกถอนและข้อผิดพลาดของห่วงโซ่ต่างก็จบลงด้วยความล้มเหลว

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