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

การบล็อกและการอ่านเป็นอำนาจที่ต่างกัน

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

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

สิ่งที่เปลือกให้มาฟรี

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

ชื่อโฮสต์ไม่อยู่ในนั้น เว็บไซต์รั่วผ่านประตูอื่น และที่กว้างที่สุดคือ DNS: ถ้าแล็ปท็อปยังถามรีโซลเวอร์ในเครื่อง ชื่อก็ปรากฏอย่างเปิดเผย

เวลาและปริมาณสมควรได้รับความเคารพโดยไม่กล่าวเกินจริง ไบต์ต่อนาที บอกได้ว่าการถ่ายโอนขนาดใหญ่เริ่มตอน 14:20 แต่บอกไม่ได้ว่าไฟล์ใดเคลื่อนที่ นั่นคือการเปิดเผยจริงเกี่ยวกับพฤติกรรม และเป็นประเภทที่ต่างจากการอ่านเนื้อหา

การดัก TLS ต้องมีรากที่คุณไว้ใจอยู่แล้ว

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

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

ทำไมช่อง VPN ไม่ใช่เซสชัน HTTPS

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

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

ตรวจสอบจากเครื่องของคุณเอง

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

openssl s_client -connect example.com:443 -servername example.com

จากนั้นแยกแฮนด์เชคที่ถูกปฏิเสธออกจากทราฟฟิกภายในที่ถูกกรองด้วยตัวนับ บันทึกพอร์ตขนส่งก่อนกฎทิ้งใด ๆ แล้วอ่านหลังการพยายาม:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

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

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

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