HTTPS, DoH, ECH และ VPN ซ่อนสิ่งที่แตกต่างกัน
แต่ละกลไกนำผู้สังเกตที่ต่างกันออกจากเส้นทาง และไม่มีกลไกใดนำออกได้ทั้งหมด เปรียบเทียบสิ่งที่ได้รับการปกป้องก่อนจะเพิ่มอุโมงค์อีกชั้น
การเพิ่ม VPN ให้เบราว์เซอร์ที่ใช้ HTTPS, DoH และ ECH อยู่แล้วไม่ได้ซ้อนการป้องกันสามอย่างเป็นหนึ่งเดียว แต่เปลี่ยนว่าใครอยู่ในตำแหน่งที่จะสังเกตอะไร แต่ละกลไกนำฝ่ายที่ต่างกันออกจากการแลกเปลี่ยนที่ต่างกัน และแต่ละอย่างก็ทิ้งอะไรไว้ คำถามที่มีประโยชน์ไม่ใช่ว่ากลไกใดแข็งแกร่งที่สุด แต่คือคุณกำลังพยายามนำผู้สังเกตคนใดออก เพราะคำตอบตัดสินว่าอุโมงค์ช่วยได้เลยหรือไม่ การเปรียบเทียบผู้สังเกตที่เหลืออยู่มีประโยชน์กว่ารายการคุณสมบัติ
สี่กลไก สี่ผู้สังเกต
เริ่มจากความสัมพันธ์ทั้งสี่และฝ่ายที่แต่ละกลไกออกแบบมาเพื่อกันออก ตารางด้านล่างคือตารางที่ผมใช้ในการทบทวน เพราะมันบังคับให้บทสนทนาระบุชื่อผู้สังเกตแทนที่จะระบุเทคโนโลยี
| Mechanism | Relationship it protects | Observer it does not remove |
|---|---|---|
| HTTPS | The application's TLS connection to its named endpoint | The access network still sees the destination address |
| DoH | The DNS exchange to the selected HTTPS resolver | That resolver sees every query |
| ECH | The sensitive ClientHello fields, where supported and accepted | Destination addresses, and DNS if it is not covered |
| VPN | Covered packets carried to the VPN peer | The VPN operator sees the destinations |
คุณค่าของตารางอยู่ที่สิ่งที่มันปฏิเสธที่จะพูด มันไม่ได้จัดอันดับกลไก และไม่ได้อ้างว่าการใช้ทั้งสี่จะนำผู้สังเกตทั้งสี่ออก แอปพลิเคชันเว็บบนคลาวด์ที่ยุติ TLS ที่ขอบของตัวเองอยู่แล้วได้รับการปกป้องจากเครือข่ายเข้าถึงสำหรับการแลกเปลี่ยนนั้น และไม่มีอุโมงค์ใดปรับปรุงคุณสมบัตินั้นได้ สิ่งที่อุโมงค์เปลี่ยนได้คือเครือข่ายใดเห็นแพ็กเก็ตชั้นนอก และผู้ให้บริการรายใดอยู่ในเส้นทางตอนนี้
HTTPS ซ่อนอะไรจริง ๆ
HTTPS ปกป้องการแลกเปลี่ยนของแอปพลิเคชันระหว่างไคลเอนต์กับปลายทางที่ใบรับรองระบุชื่อ มันไม่ได้ซ่อนที่อยู่ปลายทาง ไม่ได้ซ่อนว่ามีการเชื่อมต่อเกิดขึ้น และไม่ได้ซ่อนชื่อ เว้นแต่ ECH จะทำงานอยู่ การตรวจสอบใบรับรองเป็นส่วนหนึ่งของการป้องกัน ไม่ใช่พิธีการรอบ ๆ
VPN ไม่จำเป็นต้องยุติ TLS นั้น และไม่ควรถือว่าทางออกที่ส่งต่อเป็นปลายทางที่ผ่านการพิสูจน์ตัวตนของแอปพลิเคชัน หากการออกแบบให้ทางออกถอดรหัส นั่นคือสถาปัตยกรรมอื่นที่มีถ้อยแถลงความไว้วางใจอื่น
DoH และ ECH ย้ายอะไร และเหลืออะไรไว้
DoH ย้ายการแลกเปลี่ยน DNS ไปยังตัวแก้ไข HTTPS ซึ่งหมายความว่าตัวแก้ไขนั้นเห็นคำถามของคุณแทนตัวแก้ไขของเครือข่ายท้องถิ่น นั่นคือการเปลี่ยนแปลงจริงและมีขอบเขต: ตัวแก้ไขที่เลือกกลายเป็นฝ่ายที่สามารถเชื่อมโยงคำถามกับที่อยู่ที่คุณเชื่อมต่อในภายหลัง ซึ่งเป็นความเชื่อมโยงที่เอกสาร RFC 8484 กล่าวถึงพอดี การขนส่งที่เข้ารหัสไม่ได้ทำให้ผู้รับไม่รู้ถึงคำถามที่มันตอบ
ECH ปกป้องส่วนที่ละเอียดอ่อนของ ClientHello เพื่อให้ผู้สังเกตแบบพาสซีฟบนเส้นทางอ่านชื่อเซิร์ฟเวอร์ที่ตั้งใจไม่ได้ มันขึ้นอยู่กับการติดตั้งที่รองรับและการยอมรับจากเซิร์ฟเวอร์และเครือข่าย และปล่อยช่องทางอื่นไว้ตามเดิม ที่อยู่ปลายทางยังมองเห็นได้ และ DNS อาจยังเปิดเผยชื่อได้
อีกสิ่งหนึ่งที่ ECH ไม่ทำคือการพิสูจน์ตัวเอง การเชื่อมต่อที่ใช้ TLS 1.3 ไม่ใช่หลักฐานว่า ECH ถูกยอมรับ และเบราว์เซอร์ที่เสนอ ECH ให้เซิร์ฟเวอร์ที่ไม่รองรับจะถอยกลับอย่างเงียบ ๆ ตรวจสอบสถานะจริงของการเชื่อมต่อแทนการอนุมานจากเวอร์ชันโปรโตคอล
นั่นคือรูปร่างทั่วไปของการเปรียบเทียบทั้งหมดนี้ แต่ละกลไกได้รับการตรวจสอบในชั้นของตัวเอง และ ไม่มีกลไกใดได้รับการยืนยันจากความสำเร็จของอีกกลไกหนึ่ง
VPN ย้ายอะไร และเพิ่มอะไร
เมื่อทราฟฟิกเว็บเข้าสู่อุโมงค์ VPN เครือข่ายเข้าถึงจะเห็นการแลกเปลี่ยนชั้นนอกกับเพียร์ VPN แทนการเชื่อมต่อของแอปพลิเคชันแต่ละรายการ และผู้ให้บริการ VPN เข้ามาอยู่ในตำแหน่งบนเส้นทางต่อไป นั่นคือการย้ายขอบเขตความไว้วางใจ ไม่ใช่การนำออก ผู้ให้บริการเห็นแล้วว่าคุณไปถึงปลายทางใด แม้เนื้อหาจะยังเข้ารหัสตั้งแต่ต้นจนจบ การที่สิ่งนี้เป็นการปรับปรุงหรือไม่ขึ้นอยู่กับว่าคุณไว้วางใจฝ่ายใดในสองฝ่ายนี้น้อยกว่า
รักษา HTTPS ของแอปพลิเคชันและการป้องกันตัวแก้ไขตามที่ตั้งใจไว้ขณะทำสิ่งนี้ อุโมงค์ไม่ใช่สิ่งทดแทนการตรวจสอบใบรับรอง และการปิดการป้องกันของตัวแก้ไขเพราะทราฟฟิกผ่านอุโมงค์คือการนำการควบคุมออกโดยไม่ใส่สิ่งทดแทน
การเลือกจากความต้องการ
ระบุความต้องการจริง เพราะมันเป็นตัวกำหนดการออกแบบ การอนุญาตเข้าถึงทรัพยากรส่วนตัว จุดออกที่บริหารจัดการ ภัยคุกคามเฉพาะของเครือข่ายเข้าถึง และการอนุญาตอุปกรณ์ เป็นความต้องการที่ต่างกันสี่อย่างพร้อมคำตอบที่ต่างกันสี่แบบ และบริษัทที่ใช้เฉพาะแอปพลิเคชันคลาวด์สาธารณะก็ยังต้องตัดสินใจเรื่องการอนุญาตและการจัดการข้อมูล ชั้นเพิ่มเติมอาจเหมาะสมโดยไม่ใช่สิ่งที่ใช้แทนกันได้ การเชื่อมต่อที่ซับซ้อนกว่าไม่ใช่การวัดความเป็นนิรนาม และไม่ใช่ข้อโต้แย้งด้านความปลอดภัยด้วยตัวเอง
ข้อกำหนด ECH คือ RFC 9849 น่าอ่านเพื่อดูว่ากลไกครอบคลุมอะไรและไม่ครอบคลุมอะไร และมันซื่อสัตย์เกี่ยวกับช่องทางที่ปล่อยไว้ตามลำพัง เปรียบเทียบกลไกตามผู้สังเกตที่แต่ละอย่างนำออก เขียนผู้สังเกตนั้นลงไป แล้วตัดสินว่าชั้นเพิ่มเติมกำลังจัดการกับผู้นั้นหรือไม่ หากคำตอบคือผู้สังเกตอยู่ภายนอกแบบจำลองภัยคุกคามของคุณอยู่แล้ว อุโมงค์ก็เป็นต้นทุนโดยไม่มีประโยชน์