Domain fronting אינו VPN: שני שמות, בקשה אחת
שני שמות בבקשת HTTPS אחת אינם מנהרה. ה־fronting תלוי בכללי הניתוב של הספק; VPN בוחר אילו מנות עוברות. שרטטו אותם בנפרד.
שתי הטכניקות מתויקות יחד משום ששתיהן כוללות מתווך ושתיהן נשמעות כמו הסתרה. הן פועלות על אובייקטים שונים. Domain fronting עוסק בשאלה איזה שם מופיע באיזו שכבה של בקשת HTTPS אחת. VPN עוסק בשאלה אילו מנות עוברות במסלול מסוים אל עמית. לקרוא ל־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 FAQ של Azure מתעד הגנות מפני domain fronting. הוא מתאר אי־התאמה מותרת עבור דומיינים באותו מינוי ובמסלולים מוגדרים, ותגובת 421 Misdirected Request כאשר הגנת אי־ההתאמה חוסמת בקשה.
אותה מדיניות מתועדת אחת מבטלת את שני הסיסמאות בבת אחת. לא כל זוג שמות שונים עובד, וגם לא כל אי־התאמה אסורה. לשירותים אחרים יש בדיקות משלהם, דרישות פריסה משלהם וקודי שגיאה משלהם.
זה גם אינו הוראה לעקוף מגבלות של רשת אחרת. קריאת כללי הניתוב של ספק כדי להבין מה הוא מתיר היא עבודת ארכיטקטורה; התייחסות לכללים האלה כמתכון לעקיפה היא פעילות אחרת עם השלכות אחרות. החזיקו את שתי הפעילויות בנפרד במסמך שאתם כותבים. השנייה היא מה שגורם לתכנון להידחות בסקירה.
מה VPN באמת בוחר
ב־VPN רשת, הניתוב ומדיניות הפלטפורמה בוחרים תעבורה פנימית עבור מנהרה אל עמית. בהתאם לסידור זה יכול לכסות כמה יישומים או תת־קבוצה מוגדרת, והוא יכול לשאת פרוטוקולים שאין להם בקשת HTTP כלל.
ה־fronting לא עושה דבר מזה. סידור בקשת HTTPS אחת דרך שירות fronting אינו מתקין מסלול ברשת פרטית, אינו נושא יישומי UDP שרירותיים ואינו גורם לכל תוכנית במכשיר להשתמש בשירות. אם אתם צריכים את הכיסוי הזה, אתם צריכים פרוקסי או מנהרה, לא תחבולת שמות.
זו הסיבה שהשניים מתבלבלים בסקירה: שניהם מתוארים כמתווכים, ושניהם מופיעים במסמכים על גישה. הממשק שכל אחד מציע שונה לחלוטין, ורק אחד מהם הוא מסלול רשת.
נראות אינה בינארית
גם ההשוואה אינה רק נסתר מול גלוי. שאילתות DNS, כתובות יעד, מאפייני לחיצת יד, גדלי מנות ותזמון כולם נשארים ניתנים לצפייה למי שנמצא בעמדה לראותם, ומה שהמתבונן הזה לומד תלוי היכן הוא יושב.
גם נתוני היישום גלויים בנקודות הקצה שמסיימות אותם. שירות fronting שמנתב את הבקשה שלכם הוא אחת מנקודות הקצה האלה, ועמית VPN הוא אחר. אף אחד מהסידורים לא הופך את התוכן לאטום עבור הצד שצריך לקרוא אותו כדי לשרת אתכם.
שרטטו את שלוש הקופסאות
לסקירת ארכיטקטורה, שרטטו את נקודת הקצה של TLS, את שירות הניתוב של HTTP ואת היישום הסופי כשלוש קופסאות נפרדות, ואז שרטטו כל עמית VPN במקום אחר שוב. המקום שבוחר יעד אינטרנט והמקום שנושא מנות של רשת פרטית אינם חייבים להיות אותה מערכת, ובדרך כלל אינם.
לאחר שהקופסאות נפרדות, השאלות נעשות ברות מענה: אילו שמות הספק הזה מקבל, אילו פרוטוקולים זקוקים לנשיאה, ואיזה צד יכול לראות מה. תרשים שממזג אותם מייצר תכנון שאיש אינו יכול ליישם וסקירה שמתווכחת על אוצר מילים.