ฝั่งใดของพร็อกซีตรวจสอบที่ปฏิเสธใบรับรอง?

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

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

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

อ่านข้อผิดพลาดของผู้ตรวจสอบ

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

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

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

อุโมงค์ CONNECT ธรรมดาแตกต่างออกไป

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

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