ข้อผิดพลาด TLS เฉพาะบน VPN ขององค์กร: แก้ไขที่เก็บความเชื่อถือที่ถูกต้อง

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

สามข้อความ สามกลไก

ข้อผิดพลาด x509 certificate signed by unknown authority หมายความว่ามีการสร้างห่วงโซ่ขึ้นและรูทของมันหายไปจาก ที่เก็บความเชื่อถือที่โปรเซสนั้นใช้ ข้อผิดพลาด self-signed certificate in certificate chain โดยปกติหมายความว่าพร็อกซีตรวจสอบตอบกลับด้วยใบรับรองของตัวเอง ซึ่งเป็นห่วงโซ่ที่รันไทม์ของคุณไม่รู้จัก SSL EOF ระหว่างแฮนด์เชกหมายความว่าการเชื่อมต่อถูกปิดก่อนที่จะส่งใบรับรองที่ใช้งานได้ และนั่นคือ อุปกรณ์กลางที่ปฏิเสธ ClientHello ไม่ใช่ปัญหาเรื่องความเชื่อถือเลย

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

หา bundle ที่โปรเซสอ่านจริง ๆ

รูทขององค์กรที่ติดตั้งในที่เก็บของ Windows แก้ไขเบราว์เซอร์และแอปพลิเคชัน .NET ที่ปรึกษาที่เก็บของระบบ มันไม่ได้ทำอะไรให้บิลด์ที่ทำงานในคอนเทนเนอร์ซึ่งนำ CA bundle ของตัวเองมา และไม่ได้ทำอะไรให้โปรเซส Python ที่ใช้ certifi หรือโปรเซส Node ที่ใช้รายการที่มาพร้อมกัน Go อ่านพูลของระบบในสภาพแวดล้อมที่ไบนารีทำงาน นั่นคือคอนเทนเนอร์ ไม่ใช่โน้ตบุ๊ก เครื่องเดียวจึงให้ทั้งเบราว์เซอร์ที่ทำงานและเครื่องมือบิลด์ที่ล้มเหลวในเวลาเดียวกัน

ถามเครื่องมือแทนการสันนิษฐาน python3 -c "import ssl; print(ssl.get_default_verify_paths())" พิมพ์ไฟล์ที่ Python จะปรึกษา และ node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" แสดงว่ามีการแทนที่ถูกตั้งไว้แล้วหรือไม่ สำหรับคอนเทนเนอร์ ให้รันการตรวจสอบเดียวกันภายในอิมเมจ เพราะนั่นคือสภาพแวดล้อมที่บิลด์ใช้จริง

ติดตั้งรูทหนึ่งรายการในที่ที่บิลด์ทำงาน

ขอรูทสำหรับตรวจสอบจากฝ่ายไอทีเป็นไฟล์ PEM และตรวจสอบลายนิ้วมือผ่านช่องทางแยกก่อนที่จะเชื่อถือ บนอิมเมจที่ใช้ Debian ให้คัดลอกไปยัง /usr/local/share/ca-certificates/ และรัน update-ca-certificates อิมเมจตระกูล RHEL ใช้ update-ca-trust หลังจากวางไฟล์ใน /etc/pki/ca-trust/source/anchors/ ในการบิลด์คอนเทนเนอร์ ให้เพิ่มขั้นตอนเหล่านั้นก่อนคำสั่งที่ล้มเหลว เพื่อให้เลเยอร์ถูกแคชเหนือการติดตั้ง dependencies

สำหรับ devcontainer ในเครื่อง ให้เมานต์ PEM และรันคำสั่งอัปเดตเดียวกันตอนเริ่ม แทนการอบมันลงในอิมเมจส่วนตัวที่คนอื่นไม่สามารถทำซ้ำได้ เครื่องมือที่นำ bundle ของตัวเองมาด้วยต้องมีการแทนที่ที่มีเอกสารกำกับของตัวเอง pip มีการตั้งค่าใบรับรอง npm มีการตั้งค่า cafile และส่วนใหญ่ยอมรับตัวแปรสภาพแวดล้อมมาตรฐาน

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

เมื่อแฮนด์เชกตายก่อนใบรับรอง

หากไม่มีอะไรถูกนำเสนอ การเปลี่ยนที่เก็บความเชื่อถือก็ไม่ช่วย เปรียบเทียบคำขอเดียวกันกับอุโมงค์ที่เปิดและปิด แล้วตรวจสอบห่วงโซ่โดยตรงด้วย openssl s_client -connect host:443 -servername host -showcerts การเชื่อมต่อที่สำเร็จภายนอก VPN และถูกรีเซ็ตภายในคือการตัดสินใจเชิงนโยบายของอุปกรณ์กลาง และวิธีแก้คือข้อยกเว้นสำหรับโฮสต์นั้น ไม่ใช่ใบรับรองอีกใบ ขอให้ registry ของแพ็กเกจหรือปลายทาง API ผ่านได้โดยไม่ถูกแก้ไข

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

บันทึกผลลัพธ์แยกตามเครื่องมือ

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

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