HTTPS, DoH, ECH ו-VPN מסתירים דברים שונים
כל מנגנון מסיר מהנתיב צופה אחר, ואף אחד מהם אינו מסיר את כולם. השוו מה מוגן לפני שמוסיפים מנהרה נוספת.
הוספת VPN לדפדפן שכבר משתמש ב-HTTPS, ב-DoH וב-ECH אינה מערימה שלוש הגנות לאחת; היא משנה מי נמצא בעמדה לצפות במה. כל מנגנון מסיר צד אחר מהחלפה אחרת, וכל אחד משאיר משהו מאחור. השאלה המועילה אינה איזה מהם החזק ביותר, אלא איזה צופה אתם מנסים להסיר, מפני שהתשובה קובעת אם מנהרה עוזרת בכלל. השוואה של הצופים שנותרו מועילה יותר מרשימת תכונות.
ארבעה מנגנונים, ארבעה צופים
התחילו מארבעת היחסים ומהצד שכל אחד מהם נועד להשאיר בחוץ. הטבלה שלמטה היא זו שאני משתמש בה בסקירה, מפני שהיא כופה על השיחה לנקוב בשם של צופה במקום בטכנולוגיה.
| מנגנון | היחס שהוא מגן עליו | הצופה שהוא אינו מסיר |
|---|---|---|
| HTTPS | חיבור ה-TLS של היישום לנקודת הקצה הנקובה בשמה | רשת הגישה עדיין רואה את כתובת היעד |
| DoH | החלפת ה-DNS עם פותר ה-HTTPS הנבחר | הפותר הזה רואה כל שאילתה |
| ECH | שדות ClientHello הרגישים, היכן שנתמכים ומתקבלים | כתובות יעד, ו-DNS אם אינו מכוסה |
| VPN | חבילות מכוסות הנישאות לעמית ה-VPN | מפעיל ה-VPN רואה את היעדים |
ערכה של הטבלה הוא במה שהיא מסרבת לומר. היא אינה מדרגת את המנגנונים, ואינה טוענת ששימוש בכל הארבעה מסיר את כל ארבעת הצופים. יישום ווב בענן שכבר מסיים 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, שווה קריאה בגלל מה שהמנגנון מכסה ומה שאינו מכסה, והוא כן לגבי הערוצים שהוא מניח להם. השוו את המנגנונים לפי הצופה שכל אחד מסיר, כתבו את אותו צופה, ואז החליטו אם השכבה הנוספת מטפלת בו. אם התשובה היא שהצופה כבר היה מחוץ למודל האיומים שלכם, המנהרה היא עלות בלי תועלת.