WebRTC รั่ว: ทำไมที่อยู่จริงของคุณยังโผล่ได้แม้อยู่หลังพร็อกซี
WebRTC มีไว้เพื่อให้เบราว์เซอร์คุยกันโดยตรงสำหรับการโทรและการแชร์หน้าจอ เพื่อทำเช่นนั้น เบราว์เซอร์ต้องค้นหาที่อยู่ที่ติดต่อถึงตัวมันได้ และกระบวนการค้นหานั้นคือสิ่งที่ “WebRTC รั่ว” หมายถึง
ICE candidate ในหนึ่งย่อหน้า
เมื่อหน้าเว็บสร้าง RTCPeerConnection และเริ่ม offer เบราว์เซอร์จะรวบรวม candidate: วิธีที่เพียร์อื่นจะติดต่อมันได้ candidate แบบ host คือที่อยู่ของอินเทอร์เฟซภายในเครื่อง candidate แบบ server-reflexive (srflx) คือที่อยู่สาธารณะที่เซิร์ฟเวอร์ STUN เห็นว่าคำขอมาจาก candidate แบบ relay คือที่อยู่ของเซิร์ฟเวอร์ TURN แต่ละ candidate ถูกส่งให้หน้าเว็บเป็นบรรทัดข้อความที่มีที่อยู่อยู่ในนั้น ซึ่งเป็นวิธีที่สคริปต์อ่านมันได้ โดยไม่ต้องมีการโทรเกิดขึ้นเลย
จุดที่รั่ว
candidate แบบ srflx คือตัวที่สำคัญ เพื่อให้ได้มัน เบราว์เซอร์ส่งแพ็กเก็ต UDP ขนาดเล็กไปยังเซิร์ฟเวอร์ STUN ซึ่งตอบกลับด้วยที่อยู่ที่มันเห็น หากทราฟฟิก HTTP ของคุณผ่านพร็อกซีแต่ทราฟฟิก UDP ไม่ผ่าน เซิร์ฟเวอร์ STUN จะเห็นการเชื่อมต่อจริงของคุณ และตอนนี้หน้าเว็บมีที่อยู่ที่ไม่ตรงกับที่เว็บเซิร์ฟเวอร์เห็น ความไม่ตรงกันนั้นคือการรั่วแบบคลาสสิก หน้าวินิจฉัยแสดงมันได้ด้วยการเปรียบเทียบทั้งสอง
สังเกตว่าอะไรเกิดขึ้นและไม่เกิดขึ้น ไม่มีการบันทึกสื่อ ไม่เกี่ยวข้องกับสิทธิ์ไมโครโฟนหรือกล้อง แพ็กเก็ตไปยังเซิร์ฟเวอร์ STUN ตัวใดก็ตามที่หน้าเว็บระบุ เซิร์ฟเวอร์นั้นจึงเห็นที่อยู่ของคุณ เหมือนเซิร์ฟเวอร์ใด ๆ ที่คุณติดต่อ
สิ่งที่เบราว์เซอร์เปลี่ยน
candidate แบบ host เคยเปิดเผยที่อยู่ LAN ส่วนตัวเช่น 192.168.1.23 ซึ่งมีประโยชน์ในการสร้างลายนิ้วมือของเครือข่ายบ้าน เบราว์เซอร์สมัยใหม่แทนที่ด้วยชื่อ mDNS ที่สุ่มสร้างซึ่งลงท้ายด้วย .local หน้าเว็บจึงเห็นชื่อที่ทึบแสงแทนที่อยู่ การวินิจฉัยที่รายงานว่า “ถูกเบราว์เซอร์ปิดบัง” กำลังอธิบายสิ่งเหล่านี้ Firefox และ Brave ยังมีการตั้งค่าที่หยุดการรวบรวม candidate นอกพร็อกซี และส่วนขยายบางตัวบล็อก WebRTC ทั้งหมด
การตั้งค่าที่ปลอดภัยกับพร็อกซี
สามแนวทางใช้ได้ผล โดยมีต้นทุนต่างกัน การปิด WebRTC ป้องกันการรั่วและทำให้ทุกเว็บไซต์ที่ต้องใช้มันพัง การบังคับให้ WebRTC ใช้เฉพาะเส้นทางของพร็อกซี (โหมด “ปลอดภัยกับพร็อกซี” ในบางเบราว์เซอร์) ทำให้การโทรทำงานต่อได้เมื่อพร็อกซีรองรับ UDP หรือ TURN และถ้าไม่รองรับก็จะไม่ได้ candidate สาธารณะเลย การให้ WebRTC ทำงานตามปกติถูกต้องเฉพาะเมื่อพร็อกซีนำทราฟฟิกทั้งหมด อย่างที่ VPN ระดับระบบมักทำ
แบบไหนถูกต้องขึ้นกับงาน สำหรับโปรไฟล์เบราว์เซอร์ที่แยกขาดซึ่งต้องดูเหมือนอยู่ที่เดียว กฎนั้นง่าย: ที่อยู่ที่ WebRTC เปิดเผยต้องเป็นที่อยู่เดียวกับที่เว็บเซิร์ฟเวอร์เห็น หรือไม่มีเลย อย่างอื่นคือความขัดแย้งที่เว็บไซต์สังเกตได้โดยไม่ต้องใช้เครื่องมือพิเศษ
การอ่านผลลัพธ์
การวินิจฉัยแสดง candidate ที่สังเกตเห็นภายในไม่กี่วินาที และเปรียบเทียบตัวที่เป็นสาธารณะกับที่อยู่ที่ใช้เข้าหน้าเว็บ “ไม่มีการเปิดเผย” พร้อม candidate ที่ถูกปิดบังบางตัวเป็นผลลัพธ์ปกติและดีสำหรับเบราว์เซอร์ที่เก็บ WebRTC ไว้ในพร็อกซี ที่อยู่สาธารณะที่ต่างจากที่อยู่ของหน้าคือสิ่งที่ต้องแก้
