Шифрирањето на 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 се безбедни“ не.