Що тунель шифрує і що залишає читабельним

Ваш тунель піднято, на одній вкладці зелений замок, а звичайна HTTP-сторінка на іншій вкладці досі попереджає, що з'єднання не захищене. Це поєднання бентежить людей, бо два захисти покривають різні відстані. VPN захищає трафік між власними кінцевими точками, а за виходом трафік знову стає звичайним. HTTPS захищає одне з'єднання аж до сайту. Якщо поставити ці два факти поряд, це пояснює більшість питань про те, що VPN насправді приховує.

Що тунель насправді покриває

Між клієнтом і партнером VPN спостерігач бачить зашифровані байти, а не читабельний запит. Це охоплює ділянку, яку проходить тунель, і зазвичай це та частина, яку ви не контролюєте. Це не сягає ланки між виходом VPN і сайтом, бо тунель закінчився на виході. Байти знову стають читабельними з моменту, коли тунель закінчується. Ніщо в цьому не є помилковим налаштуванням.

Вихід — це машина, яка розшифровує й пересилає, і саме для цього потрібен VPN. Усе, що вона пересилає, видно їй у тому вигляді, у якому було отримано, тому звичайний HTTP-запит залишається відкритим текстом від виходу й далі.

Читайте це як властивість, а не як ваду. Шифрування обмежене шляхом, а шлях закінчується там, де починається служба.

Ключі, nonce і цілісність простими словами

Поточний трафік захищений симетричною криптографією, і обидві сторони виводять або отримують ключовий матеріал під час рукостискання. Автентифіковане шифрування, описане загалом у RFC 5116, дає конфіденційність і цілісність в одній конструкції. Отримувач відкидає змінені байти, а не просто не може їх прочитати, і саме це люди забувають, коли думають, що шифрування означає перемішування.

Ключі беруться з цього обміну, а не з пароля, введеного під час входу. Пароль засвідчує особу, а потім протокол встановлює матеріал сеансу. Ефемерний обмін ключами дає пряму секретність, тому записаний сеанс залишається нечитабельним, навіть якщо довгостроковий ключ згодом витече.

Велике число в специфікації не відповідає на жодне з цих питань, а порівняння чисел між непов'язаними алгоритмами не є рейтингом. Запитайте натомість, що дає обмін ключами.

Де закінчується тунель

Кінцева точка, яка завершує тунель, може читати те, що пересилає. Це однаково стосується корпоративного шлюзу, комерційного провайдера й власного сервера. Це дизайн, а не його вада. Сильна криптографія не може завадити скомпрометованій кінцевій точці читати відкритий текст, який до неї надходить, бо захист спиняється саме на кінцевій точці.

HTTPS продовжується за цією точкою, тому сайт може бути безпечним у ворожій мережі навіть без VPN. Два захисти перекриваються на першій ділянці, і лише один із них продовжується після виходу.

Саме тому ослаблення перевірки сертифіката, щоб з'єднання запрацювало, не є перевіркою тунелю. Воно вимикає інший захист і залишає вас із меншим, ніж було на початку.

Чому анонімність — це інший продукт

Адреси, час і обсяг залишаються спостережуваними поза тунелем. Спостерігач може бачити, що трафік тече до кінцевої точки VPN, приблизно скільки і коли. Вміст може бути нечитабельним, поки шаблон ще інформативний.

Провайдер також розташований не там, де ваша мережа, і це зміна спостерігача, а не усунення спостереження. Файли cookie, входи й ідентифікатори облікових записів працюють точно як раніше, бо тунель ніколи не обіцяв їх змінювати.

Обирайте провайдера за його політикою журналювання та юрисдикцією, якщо це вимога, а потім прочитайте саму політику. Маркетингові сторінки рідко відповідають на це питання так, щоб хтось міг перевірити.

Перевіряйте тунель і сайт окремо

Спочатку перевірте тунель, щоб знати, який захист ви тестуєте. Потім перевірте власний транспорт сайту й порівняйте два результати, а не припускайте, що одне означає інше. Тунель, що несе звичайний HTTP, і сайт, що віддає HTTPS, обидва роблять саме те, для чого налаштовані.

Виконуйте перевірки на хості, який вам дозволено тестувати, і читайте вивід, а не підсумок.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Коли тунель піднято, а сайт працює через HTTPS, у вас два захисти на першій ділянці й один на другій. Коли сайт працює через звичайний HTTP, друга ділянка читабельна для всіх, хто в ній, включно з виходом, що переслав запит. Знання того, якого з двох бракує, це весь діагноз, і для цього потрібні дві команди, а не новий клієнт.