Шифроването на WSS тунел спира при TLS терминатора, не в приложението

Тунел, пренасян вътре в защитен WebSocket, има точно толкова шифроване, колкото клиентът е вложил в него, и нито повече. Схемата wss:// казва, че TLS защитава една връзка на един хоп. Тя не казва нищо за това дали байтовете вътре в WebSocket съобщенията са защитени отделно и точно това разграничение решава кой може да чете трафика ви, когато нещо по средата прекрати TLS.

Два слоя, които изглеждат като един

Защитеният WebSocket е TLS, върху който се изпълнява WebSocket ръкостискане, както описва RFC 6455 в разделите си за връзка и сигурност. Слоят TLS удостоверява сървъра и шифрова потока, след което слоят WebSocket оформя в кадри каквото приложението реши да изпрати.

Това са две независими решения и диаграма, която рисува едно катинарче върху целия път, скрива второто. Питайте кой прекратява TLS връзката. После питайте какво клиентът поставя вътре във всяко съобщение. Всичко останало за внедряването следва от тези два отговора.

Дизайн A: транспортът е единственото шифроване

В по-простия дизайн клиентът взема сурови IP пакети и ги обвива в WebSocket съобщения. Вътре нищо не е шифровано, затова компонентът, който държи TLS сесията, чете открити полезни товари. Когато този компонент е вашият собствен тунелен сървър, това е предвидената крайна точка и дизайнът е последователен, защото сървърът така или иначе щеше да вижда трафика.

Това става друга подредба, когато на пътя застане прокси за инспекция и прекрати TLS със сертификат, на който клиентът се доверява. Това прокси сега държи същия открит текст, който сървърът би държал, и никакво количество WebSocket кадриране не го променя. Хранилището за доверие на клиента реши този изход много преди тунелът да се отвори, защото избра да приеме този сертификат за това име. Проксито също вижда заявения хост и размера на всяко съобщение, което е достатъчно да снеме отпечатък на много активност, без да дешифрира нищо повече.

Дизайн B: полезният товар носи собствени ключове

Във втория дизайн клиентът шифрова и удостоверява пакетите си с VPN протокол, който има собствена идентичност на партньора и обмен на ключове, и след това пренася резултата вътре в WebSocket съобщения. Прекратяването на външния TLS тук разкрива шифрован текст, а не трафик. Проксито може да види размерите на съобщенията и времето, и нищо друго в товара. Това е много по-малко излагане и все пак са метаданни, които заслужават да бъдат назовани в преглед, вместо да бъдат отмахнати.

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

Етикет VPN, позната икона на клиент или маркетингова страница не са доказателство, че този дизайн съществува. Четенето на формата на товара е.

Проследете къде всъщност се появява откритият текст

Схемата на URL ви дава един факт, затова вземете останалото от интерфейсите. Изпълнете проверките по-долу по ред, защото всяка стеснява следващата:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Започнете с външната връзка. Една дълготрайна TCP сесия към TLS порта е как изглежда WebSocket носител, а втора сесия към несвързан хост заслужава обяснение, преди да гледате по-дълбоко. След това намерете тунелния интерфейс на клиента, защото устройство tun или tap ви казва, че клиентът работи с IP пакети, а не проксира един поток на приложение.

Заснемането на тунелния интерфейс обикновено решава въпроса с товара. Четливите заглавки там означават, че вътрешните пакети никога не са били отделно шифровани, докато товари с висока ентропия означават, че са били. Повторете заснемането на външния интерфейс и сравнете двете: ако и двете изглеждат случайни, вътрешният слой върши работа, която външният не може да отмени.

Прегледайте доверието, което всъщност сте дали

Инсталиран корпоративен коренов сертификат е факт за хранилището за доверие на клиента, а не твърдение за това какво записва или инспектира някое прокси. Установете внедрената политика и реалния път на връзката, вместо да извеждате поведение от наличието на CA.

На управлявано оборудване попитайте администратора кой компонент прекратява TLS, дали клиентът проверява закрепен сертификат или публичен такъв и какъв е форматът на товара. Тези три отговора дават констатация, която можете да защитите по-късно.

Запишете резултата като граница, а не като присъда. "TLS се прекратява при проксито за инспекция, а вътрешният товар е отделно шифрован с ключове, които държат само крайните точки" е проверимо твърдение, което оцелява при смяна на доставчика. "WebSockets са сигурни" не е.