ผู้ให้บริการ VPN มองเห็นเว็บไซต์ที่คุณเข้าชมได้หรือไม่
เซิร์ฟเวอร์ OpenVPN ค่าเริ่มต้นบันทึกเซสชัน ไม่ใช่ URL เปรียบเทียบบันทึกการเชื่อมต่อ การดักจับทันเนล และการทดสอบ DNS รั่วไหล ก่อนจะอ้างว่าผู้ให้บริการเห็นอะไร
ถามว่า VPN มองเห็นอะไรได้บ้าง คำตอบขึ้นอยู่กับ ว่าคุณยืนอยู่ตรงไหนของเส้นทาง. ในชั้นเซสชัน ผู้ให้บริการมีเหตุการณ์ยืนยันตัวตนและจำนวนไบต์ ในชั้นแพ็กเก็ตมีที่อยู่ปลายทางและเวลา ในชั้น DNS อาจมีชื่อเหล่านั้นเอง แต่ละชั้นตอบคำถามคนละข้อ และไม่มีสวิตช์ใดย้ายคุณระหว่างชั้นเหล่านี้
กำหนดชั้นก่อนจะกล่าวอ้าง
การเชื่อมต่อเดียวกันสร้างบันทึกต่างกันในแต่ละจุด และข้อความเกี่ยวกับความเป็นส่วนตัวจะมีความหมายก็ต่อเมื่อระบุจุดนั้น อ่านตารางทีละคอลัมน์: อะไรมีอยู่ในชั้นนั้น ผู้ให้บริการเห็นอะไรได้ที่นั่น และบันทึกเดียวกันนั้นยังบอกอะไรไม่ได้
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
การอ่านชั้นเดียวเป็นภาพรวมทั้งหมดคือจุดเริ่มต้นของทั้งการกล่าวอ้างเกินจริงและความมั่นใจลวง การบอกว่าไม่บันทึกการท่องเว็บอาจถูกต้องเรื่องการบันทึก URL แต่ยังเก็บบันทึกเซสชันไว้ และการดักจับแพ็กเก็ตที่แสดงเพียงที่อยู่ไม่กลายเป็นประวัติการท่องเว็บได้หากไม่มีการค้นย้อนกลับและการคาดเดา
เมื่อประเมินนโยบาย ให้หาประโยคที่อธิบายแต่ละชั้น หากนโยบายไม่แยกชั้นเหล่านี้ ให้ถามว่ามีบันทึกใดอยู่ แทนที่จะยอมรับข้อความทั่วไปเกี่ยวกับการเข้ารหัส
บัญชีเซสชัน: สิ่งที่เซิร์ฟเวอร์ OpenVPN มาตรฐานเก็บไว้
โดยค่าเริ่มต้น OpenVPN เซิร์ฟเวอร์ไม่ได้ดักจับทราฟฟิก ผลลัพธ์ปกติคือบัญชีเซสชัน: บัญชีที่ยืนยันตัวตนแล้ว ที่อยู่ต้นทางที่มาจาก เวลาประทับเริ่มต้นและสิ้นสุด ที่อยู่ทันเนลที่แจกให้ และยอดไบต์รวมทั้งสองทิศทาง นั่นคือบัญชีของเซสชัน ไม่ใช่รายการปลายทาง
ตัวเลือกการบันทึกสามารถเพิ่มรายละเอียดได้ ระดับความละเอียดที่สูงขึ้นจะเขียนเกี่ยวกับการจับมือมากกว่า และไฟล์สถานะอาจแสดงรายชื่อไคลเอนต์ที่เชื่อมต่อ แต่ทั้งสองไม่ได้เปลี่ยนเซิร์ฟเวอร์เป็นพร็อกซีโปร่งใส การสร้าง URL ต้องยุติ TLS หรือรันพร็อกซีแบบชัดเจน และทั้งสองเปลี่ยนโครงสร้างความไว้วางใจแทนที่จะเปิดคุณสมบัติที่ซ่อนอยู่
นี่คือเหตุผลที่ข้ออ้างว่าไม่มีบันทึกการท่องเว็บฉบับเที่ยงตรงนั้นแคบกว่าที่ฟังดู เซิร์ฟเวอร์ไม่รู้หน้าเว็บ แต่รู้ว่ามีเซสชันอยู่และข้อมูลราวเท่าไรผ่านไป การเก็บบันทึกเซสชันนั้นหรือไม่และนานเท่าใดเป็นคำถามนโยบายแยกต่างหาก
แพ็กเก็ตชั้นในและชั้นนอกเป็นหลักฐานคนละแบบ
การดักจับแพ็กเก็ตคือวิธีดูว่าอะไรผ่านทันเนลจริง ๆ บนเซิร์ฟเวอร์ ระบุอินเทอร์เฟซของทันเนลและเขียนลงไฟล์ที่วิเคราะห์แบบออฟไลน์ได้:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headไฟล์นั้นมีทราฟฟิกชั้นในที่ถอดรหัสแล้ว: ที่อยู่ทันเนลของไคลเอนต์เป็นต้นทาง ที่อยู่ปลายทางและพอร์ต ขนาดแพ็กเก็ตและเวลา ไม่มีเส้นทาง HTTP หรือเนื้อหาการตอบกลับ เว้นแต่จะยุติ TLS ที่ใดที่หนึ่ง และเป็นข้อมูลอ่อนไหวที่การเก็บรักษาเป็นการตัดสินใจเชิงนโยบาย ไม่ใช่ความสะดวกในการดีบัก
การดักจับบนอินเทอร์เฟซกายภาพแสดงอีกอย่างหนึ่ง ที่นั่นคุณเห็นแพ็กเก็ตชั้นนอกที่ส่งไปยังปลายทาง VPN โดยมีเพย์โหลดที่เข้ารหัสอยู่ข้างใน ที่อยู่ที่ไม่เกี่ยวข้องซึ่งปรากฏในไฟล์นั้นเป็นเรื่องปกติเมื่อมีอะแดปเตอร์เสมือน เพราะอุปกรณ์ทันเนลพาการไหลชั้นใน ขณะที่การขนส่งที่เข้ารหัสพาการไหลชั้นนอก
ถามว่าการดักจับนั้นมีไว้ตอบคำถามอะไร การใช้ทันเนลของแอปพลิเคชันเห็นได้บนอะแดปเตอร์เสมือน การเข้าถึงทันเนลถึงปลายทางเห็นได้บนอะแดปเตอร์กายภาพ การใช้ไฟล์ใดไฟล์หนึ่งเป็นภาพรวมทั้งหมดให้ข้อสรุปที่ข้อมูลรองรับไม่ได้
DNS คือจุดที่ชื่อกลายเป็นสิ่งที่มองเห็นได้
DNS ยังคงเป็นข้อยกเว้นในทางปฏิบัติ ตัวแก้ชื่อเห็นชื่อที่ถูกขอให้แปลง ดังนั้นผู้ที่ดำเนินการจึงรู้ว่าไคลเอนต์ค้นหาเว็บไซต์ใด แม้การเชื่อมต่อภายหลังจะถูกเข้ารหัส การดักจับทันเนลแสดงที่อยู่ ตัวแก้ชื่อแสดงชื่อ
ตรวจสอบว่าตัวแก้ชื่อใช้ที่อยู่ใดเพื่อเข้าถึงบริการภายนอก คำตอบคือที่อยู่ขาออกของตัวแก้ชื่อ และการเปรียบเทียบกับทางออกของ VPN บอกว่าคำถามนั้นผ่านทันเนลหรือไม่:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53หากที่อยู่ตรงกับการเชื่อมต่อภายในแทนที่จะเป็นทางออกของทันเนล การค้นหาข้าม VPN ไปและชื่อนั้นมองเห็นได้บนเส้นทางภายใน ทำการตรวจซ้ำหลังอัปเดตไคลเอนต์ เพราะเวอร์ชันใหม่อาจเปลี่ยนว่าโปรไฟล์ติดตั้งตัวแก้ชื่อใด
DNS ที่เข้ารหัสย้ายการมองเห็นแทนที่จะลบมัน เครือข่ายไม่เห็นคำถามอีกต่อไป แต่ตัวแก้ชื่อยังเห็น และคำถามเรื่องความไว้วางใจเพียงเปลี่ยนมือ ชื่อเซิร์ฟเวอร์ TLS ในการจับมือของการเชื่อมต่อเป็นสัญญาณบางส่วนอีกอย่างหนึ่ง มักอยู่รอดแม้เพย์โหลดจะทึบ ดังนั้นที่อยู่ปลายทางจึงไม่ใช่เมทาดาทาเดียวที่เซิร์ฟเวอร์ส่งต่อสามารถสังเกตได้
บันทึกสามประเภทและใครอ่านได้บ้าง
การบัญชีเซสชัน บันทึกตามชื่อ และหลักฐานการรั่วไหลเป็นผลิตภัณฑ์สามอย่างที่ต่างกันพร้อมภาระหน้าที่ต่างกัน บันทึกเซสชันมีต้นทุนต่ำและละเอียดอ่อนน้อย และตอบว่าใครเชื่อมต่อเมื่อใด บันทึกตามชื่อต้องมีตัวแก้ชื่อที่บันทึกหรือพร็อกซีแบบชัดเจน และสร้างหน้าที่ในการเปิดเผยต่อผู้ที่ได้รับผลกระทบ หลักฐานการรั่วไหลคือการทดสอบฝั่งไคลเอนต์ที่เปรียบเทียบสิ่งที่ตัวแก้ชื่อเปิดเผยกับทางออกของทันเนล
บันทึกว่าคุณดำเนินการอย่างใดในสามอย่างนี้ ใครอ่านได้ และเก็บไว้นานเท่าใด ข้อความที่ว่าบริการไม่เก็บบันทึกอธิบายเพียงชั้นเดียว และเป็นจริงเพียงในขอบเขตนั้น ผู้ให้บริการรายเดียวกันอาจถูกต้องเรื่องเซสชันแต่ผิดเรื่อง DNS
ทำให้การทดสอบทำซ้ำได้: คำถามเดียวกันถึงตัวแก้ชื่อ อินเทอร์เฟซดักจับเดียวกัน และการเปรียบเทียบเดียวกัน ข้ออ้างเรื่องความเป็นส่วนตัวที่ทดสอบไม่ได้ในชั้นที่ระบุชื่อนั้นเป็นคำขวัญ ไม่ใช่ข้อเท็จจริงเชิงปฏิบัติการ