ECH แทนที่ VPN หรือไม่? แต่ละอย่างซ่อนอะไรจริง ๆ
ECH เข้ารหัสส่วนต่าง ๆ ของ TLS handshake ที่อาจเปิดเผยชื่อเซิร์ฟเวอร์ที่ต้องการ VPN พาข้อมูลไปยังปลายทาง ไม่มีสิ่งใดทำหน้าที่ของอีกสิ่งหนึ่ง
คุณเปิดใช้ Encrypted Client Hello เปิดเว็บไซต์ และการเชื่อมต่อก็ทำงาน มีคนถามว่า VPN ยังจำเป็นอยู่ไหม และคำตอบที่ซื่อตรงคือสองฟีเจอร์นี้ซ่อนสิ่งต่าง ๆ จากฝ่ายที่ต่างกัน ECH ปกป้องบางส่วนของ TLS handshake ที่อาจเปิดเผยชื่อเซิร์ฟเวอร์ที่คุณร้องขอ VPN นำข้อมูลของคุณเข้าไปในอุโมงค์ที่สิ้นสุดที่ปลายทางของผู้ให้บริการ การสับสนระหว่างสองสิ่งนี้ทำให้คุณจ่ายเกินสำหรับการป้องกันที่มีอยู่แล้ว หรือเชื่อว่าคุณมีการป้องกันที่คุณไม่เคยมี
handshake เปิดเผยอะไรเมื่อไม่มี ECH
การเชื่อมต่อ TLS เริ่มต้นด้วย ClientHello และในรูปแบบเก่าชื่อเซิร์ฟเวอร์ที่ต้องการเดินทางแบบเปิดเผยอยู่ภายใน ใครก็ตามที่อยู่ในตำแหน่งที่สังเกต handshake ได้ ตั้งแต่ผู้ให้บริการเครือข่ายไปจนถึงเซ็นเซอร์แบบพาสซีฟบนเส้นทาง สามารถอ่านชื่อนั้นได้ แม้ว่าข้อมูลแอปพลิเคชันหลังจากนั้นจะถูกเข้ารหัสก็ตาม ที่อยู่ปลายทางก็มองเห็นได้เช่นกัน ชื่อจึงมักเป็นข้อมูลยืนยันมากกว่าจะเป็นสัญญาณเดียว
นั่นคือการรั่วไหลเฉพาะที่ ECH มุ่งเป้า มันเป็นการรั่วไหลที่แคบ และการทำให้แคบลงก็คุ้มค่า แต่มันไม่เหมือนกับการซ่อนว่าข้อมูลของคุณไปที่ไหน
ECH เปลี่ยนอะไรจริง ๆ
ด้วยการสนับสนุนไคลเอนต์และเซิร์ฟเวอร์ที่เข้ากันได้และการกำหนดค่าที่จำเป็น ECH เข้ารหัส ClientHello ภายในด้วยคีย์ที่เซิร์ฟเวอร์เผยแพร่ ผู้สังเกตจึงเห็น handshake ภายนอกที่ไม่พาชื่อเซิร์ฟเวอร์จริง ข้อมูลยังคงไปยังที่อยู่เดิม ในเวลาเดิม ในปริมาณใกล้เคียงเดิม เวลาและขนาดยังคงสังเกตได้ และ IP ปลายทางไม่เคยเป็นส่วนหนึ่งของสิ่งที่ ECH เข้ารหัส
การสนับสนุนก็ไม่เป็นสากลเช่นกัน ไม่ใช่ทุกไคลเอนต์ บริการ หรือการเชื่อมต่อแต่ละรายที่ใช้ ECH และคุณไม่สามารถอนุมานการมีอยู่ได้จากไอคอนกุญแจหรือจากการเปลี่ยนประเทศของ VPN การวินิจฉัยต้องดูที่ handshake ไม่ใช่ที่การตกแต่งของเบราว์เซอร์
VPN เปลี่ยนอะไรแทน
VPN นำข้อมูลที่ถูกปกปิดภายในอุโมงค์ไปยังปลายทาง ผู้สังเกตที่ใกล้คุณที่สุดจึงเห็นการเชื่อมต่อกับ VPN ไม่ใช่กับปลายทาง สิ่งนี้เปลี่ยนว่าใครสังเกตอะไรได้ และเปลี่ยนที่อยู่ที่ปลายทางมองเห็น มันไม่ได้เข้ารหัสสิ่งใดที่แอปพลิเคชันยังไม่ได้เข้ารหัส และไม่ได้ซ่อนการเชื่อมต่อจากผู้ให้บริการ VPN ซึ่งตามโครงสร้างแล้วอยู่ในเส้นทาง
ทั้งสองทำงานร่วมกันตามธรรมชาติ แอปพลิเคชันสามารถใช้ TLS และ ECH ขณะที่อุโมงค์ปกป้องส่วนของเครือข่ายรอบ ๆ ไม่มีสิ่งใดกำหนดว่าฝ่ายแต่ละฝ่ายมองเห็นหรือเก็บรักษาอะไรได้ เพราะฝ่ายต่าง ๆ อยู่ในตำแหน่งที่ต่างกันบนเส้นทาง
DNS อยู่ตรงไหน
การสอบถาม DNS ที่ไม่ได้รับการปกป้องเปิดเผยชื่อให้กับตัวแก้ไข DNS และใครก็ตามที่สังเกตเส้นทางนั้น ซึ่งเป็นการเปิดเผยแยกจาก handshake ของ TLS ECH ไม่ได้เข้ารหัส DNS และ VPN เปลี่ยนตัวตนของตัวแก้ไข DNS ก็ต่อเมื่อคุณส่งคำถามผ่านอุโมงค์ด้วยหรือใช้ตัวแก้ไขที่เข้ารหัส ผู้คนเปิดหนึ่งในสามอย่างแล้วคิดว่าอีกสองอย่างตามมา
ตรวจสอบเส้นทางของตัวแก้ไข DNS แยกจากเส้นทางของ handshake ส่วนมันล้มเหลวอย่างเป็นอิสระต่อกัน และถูกกำหนดค่าในที่ต่างกัน
จะรู้ได้อย่างไรว่าคุณกำลังดูชั้นไหน
ถามว่าการสังเกตนั้นจะเปิดเผยอะไร หากคำถามคือชื่อเซิร์ฟเวอร์ใดถูกร้องขอ handshake และตัวแก้ไข DNS คือชั้นที่เกี่ยวข้อง หากคำถามคือข้อมูลไปยังเครือข่ายใดและใครเห็นได้ระหว่างทาง นั่นคืออุโมงค์ หากคำถามคือบัญชีใดทำอะไรบนเว็บไซต์ ทั้งสองอย่างไม่ช่วย เพราะเว็บไซต์ยังคงได้รับคำขอและตัวตนใด ๆ ที่คุณให้ไป
รักษาการตรวจสอบใบรับรองและนโยบาย DNS ให้คงอยู่ขณะที่คุณตรวจสอบความเข้ากันได้ การปิดการตรวจสอบเพื่อให้การทดสอบผ่านจะเปลี่ยนความหมายของผลลัพธ์ แทนที่จะแสดงว่า ECH ปกป้องอะไร
จดบันทึกว่าคุณเปิดชั้นใดจริง ๆ ก่อนที่จะเพิ่มอีกชั้น ความสับสนส่วนใหญ่ที่นี่มาจากการสมมติว่าการควบคุมเดียวครอบคลุมคำขอ ชื่อ ปลายทาง และตัวตนของคำขอในคราวเดียว