Domain fronting ไม่ใช่ VPN: สองชื่อ หนึ่งคำขอ
สองชื่อในคำขอ HTTPS เดียวไม่ใช่ทันเนล fronting ขึ้นอยู่กับกฎการกำหนดเส้นทางของผู้ให้บริการ VPN เลือกว่าจะให้แพ็กเก็ตใดเดินทาง วาดแยกกัน
เทคนิคทั้งสองถูกจัดเก็บไว้ด้วยกันเพราะทั้งคู่มีคนกลางและทั้งคู่ฟังดูเหมือนการซ่อน แต่ทั้งสองทำงานกับวัตถุที่ต่างกัน domain fronting เกี่ยวกับว่าชื่อใดปรากฏในชั้นใดของคำขอ HTTPS หนึ่งคำขอ ส่วน VPN เกี่ยวกับว่าแพ็กเก็ตใดเดินทางตามเส้นทางหนึ่งไปยัง peer การเรียก fronting ว่าเป็น VPN ชนิดหนึ่งนำไปสู่การออกแบบที่ทำงานไม่ได้ และการทบทวนที่ถามคำถามผิด
สองชื่อ สองชั้น
การเชื่อมต่อ TLS สามารถพาชื่อเซิร์ฟเวอร์มาในแฮนด์เชกของตน เมื่อการเชื่อมต่อมีอยู่ คำขอ HTTP ระบุอำนาจที่ต้องการ โดยปกติในส่วนหัว Host สองสิ่งนี้คือฟิลด์สองฟิลด์ที่ถูกอ่านในสองช่วงเวลาต่างกันโดยซอฟต์แวร์สองส่วนที่ต่างกัน
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
domain fronting ใช้ประโยชน์จากความแตกต่างระหว่างสองชั้นแรก บริการ fronting จึงรับการเชื่อมต่อแล้วกำหนดเส้นทางคำขอไปที่อื่น มันทำงานเฉพาะที่บริการนั้นยินดีกำหนดเส้นทาง ซึ่งเป็นคำถามเรื่องนโยบายของผู้ให้บริการ ไม่ใช่กลอุบายของโปรโตคอล
fronting ขึ้นอยู่กับผู้ให้บริการ ไม่ใช่เทคนิค
เป็นตัวอย่างที่จำกัด, คำถามที่พบบ่อยเกี่ยวกับ Front Door เอกสารของ Azure บันทึกมาตรการป้องกัน domain fronting ไว้อธิบายความไม่ตรงกันที่อนุญาตสำหรับโดเมนภายในบอกรับเป็นสมาชิกเดียวกันและเส้นทางที่กำหนดค่าไว้ และการตอบกลับ 421 Misdirected Request เมื่อมาตรการป้องกันความไม่ตรงกันปิดกั้นคำขอ
นโยบายที่บันทึกไว้เพียงฉบับเดียวก็ล้มล้างคำขวัญทั้งสองในคราวเดียว ไม่ใช่ทุกคู่ของชื่อที่ต่างกันจะใช้ได้ และไม่ใช่ทุกความไม่ตรงกันจะถูกห้าม บริการอื่นมีตัวตรวจสอบของตน ข้อกำหนดในการติดตั้งใช้งานของตน และรหัสข้อผิดพลาดของตน
นี่ก็ไม่ใช่คำแนะนำในการหลีกเลี่ยงข้อจำกัดของเครือข่ายอื่น การอ่านกฎการกำหนดเส้นทางของผู้ให้บริการเพื่อเข้าใจว่าอะไรที่อนุญาตเป็นงานสถาปัตยกรรม การถือกฎเหล่านั้นเป็นสูตรหลีกเลี่ยงเป็นกิจกรรมอื่นที่มีผลลัพธ์อื่น แยกกิจกรรมทั้งสองนี้ออกจากกันในเอกสารที่คุณเขียน กิจกรรมที่สองคือสิ่งที่ทำให้การออกแบบถูกปฏิเสธในการทบทวน
VPN เลือกอะไรจริง ๆ
ใน VPN เครือข่าย การกำหนดเส้นทางและนโยบายแพลตฟอร์มเลือกทราฟฟิกภายในสำหรับทันเนลไปยัง peer ขึ้นอยู่กับการจัดวาง อาจครอบคลุมหลายแอปพลิเคชันหรือชุดย่อยที่กำหนดไว้ และอาจพาโปรโตคอลที่ไม่มีคำขอ HTTP เลย
fronting ไม่ทำสิ่งใดในนั้น การจัดคำขอ HTTPS หนึ่งคำขอผ่านบริการ fronting ไม่ได้ติดตั้งเส้นทางเครือข่ายส่วนตัว ไม่พาแอปพลิเคชัน UDP โดยพลการ และไม่ได้ทำให้ทุกโปรแกรมบนอุปกรณ์ใช้บริการ หากคุณต้องการความครอบคลุมนั้น คุณต้องมีพร็อกซีหรือทันเนล ไม่ใช่กลอุบายเรื่องชื่อ
นี่คือเหตุผลที่ทั้งสองสับสนในการทบทวน ทั้งคู่ถูกอธิบายว่าเป็นคนกลาง และทั้งคู่ปรากฏในเอกสารเกี่ยวกับการเข้าถึง อินเทอร์เฟซที่แต่ละอย่างเสนอแตกต่างกันโดยสิ้นเชิง และมีเพียงหนึ่งในนั้นที่เป็นเส้นทางเครือข่าย
การมองเห็นไม่ใช่สองค่า
การเปรียบเทียบก็ไม่ใช่แค่ซ่อนกับมองเห็น การสอบถาม DNS ที่อยู่ปลายทาง คุณลักษณะของแฮนด์เชก ขนาดแพ็กเก็ต และเวลา ยังคงสังเกตได้สำหรับผู้ที่อยู่ในตำแหน่งที่จะเห็นสิ่งเหล่านั้น และสิ่งที่ผู้สังเกตนั้นเรียนรู้ขึ้นอยู่กับว่าพวกเขาอยู่ที่ไหน
ข้อมูลแอปพลิเคชันก็มองเห็นได้ที่ปลายทางที่สิ้นสุดข้อมูลนั้น บริการ fronting ที่กำหนดเส้นทางคำขอของคุณเป็นหนึ่งในปลายทางเหล่านั้น และ peer ของ VPN เป็นอีกแห่ง ทั้งสองรูปแบบไม่ได้ทำให้เนื้อหาทึบสำหรับฝ่ายที่ต้องอ่านเพื่อให้บริการคุณ
วาดกล่องสามกล่อง
สำหรับการทบทวนสถาปัตยกรรม ให้วาดปลายทาง TLS บริการกำหนดเส้นทาง HTTP และแอปพลิเคชันสุดท้ายเป็นสามกล่องแยกกัน แล้ววาด peer ของ VPN ไว้ที่อื่นอีกครั้ง สถานที่ที่เลือกปลายทางเว็บและสถานที่ที่ขนส่งแพ็กเก็ตของเครือข่ายส่วนตัวไม่จำเป็นต้องเป็นระบบเดียวกัน และโดยปกติก็ไม่ใช่
เมื่อกล่องแยกจากกัน คำถามก็ตอบได้: ผู้ให้บริการนี้ยอมรับชื่อใด โปรโตคอลใดต้องการการขนส่ง และฝ่ายใดเห็นอะไรได้บ้าง แผนภาพที่หลอมรวมสิ่งเหล่านั้นเข้าด้วยกันก่อให้เกิดการออกแบบที่ไม่มีใครนำไปใช้ได้ และการทบทวนที่โต้เถียงเรื่องคำศัพท์