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, варто прочитати заради того, що механізм покриває і чого не покриває, і вона чесна щодо каналів, які не чіпає. Порівнюйте механізми за спостерігачем, якого кожен прибирає, запишіть цього спостерігача і вирішіть, чи звертається до нього додатковий рівень. Якщо відповідь така, що спостерігач і так був поза вашою моделлю загроз, тунель — це витрати без користі.