อุโมงค์ที่บรรทุกอยู่ใน WebSocket ที่ปลอดภัยมีการเข้ารหัสเท่ากับที่ลูกค้าใส่เข้าไปเท่านั้น ไม่มากกว่านั้น สคีมา wss:// บอกว่า TLS ปกป้องการเชื่อมต่อหนึ่งรายการในหนึ่งฮอป มันไม่บอกอะไรเลยว่าไบต์ภายในข้อความ WebSocket ถูกป้องกันแยกหรือไม่ และความแตกต่างนั้นเองเป็นตัวกำหนดว่าใครอ่านทราฟฟิกของคุณได้เมื่อมีบางสิ่งตรงกลางสิ้นสุด TLS

สองชั้นที่ดูเหมือนชั้นเดียว

WebSocket ที่ปลอดภัยคือ TLS ที่มีการจับมือ WebSocket ทำอยู่บนนั้น ตามที่ RFC 6455 อธิบายไว้ในส่วนการเชื่อมต่อและความปลอดภัย ชั้น TLS ตรวจสอบเซิร์ฟเวอร์และเข้ารหัสสตรีม จากนั้นชั้น WebSocket จึงใส่เฟรมให้สิ่งที่แอปพลิเคชันตัดสินใจส่ง

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

ดีไซน์ A: การขนส่งคือการเข้ารหัสเดียว

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

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

ดีไซน์ B: เพย์โหลดบรรทุกกุญแจของตัวเอง

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

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

ป้าย VPN ไอคอนลูกค้าที่คุ้นเคย หรือหน้าสื่อสารการตลาดไม่ใช่หลักฐานว่าดีไซน์นี้มีอยู่จริง การอ่านรูปแบบเพย์โหลดต่างหากคือหลักฐาน

ตามรอยว่าข้อความธรรมดาปรากฏที่ใดจริง

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

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

เริ่มจากการเชื่อมต่อชั้นนอก เซสชัน TCP อายุยาวหนึ่งเซสชันไปยังพอร์ต TLS คือหน้าตาของตัวบรรทุก WebSocket และเซสชันที่สองไปยังโฮสต์ที่ไม่เกี่ยวข้องก็สมควรได้รับการอธิบายก่อนจะดูลึกลงไป จากนั้นหาอินเทอร์เฟซอุโมงค์บนลูกค้า เพราะอุปกรณ์ tun หรือ tap บอกคุณว่าลูกค้ากำลังจัดการแพ็กเก็ต IP ไม่ใช่พร็อกซีสตรีมแอปพลิเคชันเดียว

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

ทบทวนความเชื่อถือที่คุณให้ไปจริง

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

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

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

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