Criptarea tunelului WSS se oprește la terminatorul TLS, nu în aplicație

Un tunel transportat într-un WebSocket securizat are exact atâta criptare cât a pus clientul în el, nu mai mult. Schema wss:// spune că TLS protejează o singură conexiune pe un salt. Nu spune nimic despre dacă octeții din interiorul mesajelor WebSocket sunt protejați separat, iar această distincție decide cine poate citi traficul tău când ceva din mijloc termină TLS.

Două straturi care par unul singur

Un WebSocket securizat este TLS cu o strângere de mână WebSocket executată deasupra, așa cum descrie RFC 6455 în secțiunile despre conexiune și securitate. Stratul TLS autentifică serverul și criptează fluxul, apoi stratul WebSocket încadrează ce decide aplicația să trimită.

Sunt două decizii independente, iar o diagramă care desenează un singur lacăt pe toată calea o ascunde pe a doua. Întrebați cine termină conexiunea TLS. Apoi întrebați ce pune clientul în fiecare mesaj. Tot restul despre implementare decurge din aceste două răspunsuri.

Design A: transportul este singura criptare

În designul mai simplu, clientul ia pachete IP brute și le înfășoară în mesaje WebSocket. Nimic din interior nu este criptat, așa că componenta care ține sesiunea TLS citește încărcături în text clar. Când acea componentă este propriul server de tunel, acesta este punctul final prevăzut, iar designul este coerent, pentru că serverul oricum ar fi văzut traficul.

Devine o altă aranjare când un proxy de inspecție stă pe cale și termină TLS cu un certificat în care clientul are încredere. Acel proxy are acum același text clar pe care l-ar fi avut serverul, iar nicio cantitate de încadrare WebSocket nu schimbă asta. Magazinul de încredere al clientului a decis acest rezultat cu mult înainte de deschiderea tunelului, pentru că a ales să accepte acel certificat pentru acel nume. Proxyul vede și gazda solicitată și dimensiunea fiecărui mesaj, ceea ce este suficient pentru a lua amprenta multor activități fără a mai decripta nimic.

Design B: încărcătura își poartă propriile chei

În al doilea design, clientul criptează și autentifică pachetele cu un protocol VPN care are propria identitate de partener și propriul schimb de chei, apoi transportă rezultatul în mesaje WebSocket. Terminarea TLS-ului exterior aici expune text cifrat, nu trafic. Proxyul poate vedea dimensiunile și momentul mesajelor, și nimic altceva din încărcătură. Este o expunere mult mai mică, și totuși sunt metadate care merită numite într-o revizuire în loc să fie înlăturate.

Punctele finale proprii ale protocolului interior văd în continuare text clar, ceea ce este sensul aranjării și totodată limita ei. Dacă o componentă de la punctul final este autorizată să citească date înainte de criptare sau după decriptare, stratul suplimentar nu o restricționează. Cheile, și software-ul care le gestionează, rămân granița care contează.

O etichetă VPN, o pictogramă de client cunoscută sau o pagină de marketing nu sunt dovada că acest design există. Citirea formatului încărcăturii este.

Urmăriți unde apare de fapt textul clar

Schema URL vă dă un singur fapt, așa că luați restul din interfețe. Rulați verificările de mai jos în ordine, pentru că fiecare o îngustează pe următoarea:

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

Începeți cu conexiunea exterioară. O sesiune TCP de lungă durată către portul TLS este aspectul unui purtător WebSocket, iar o a doua sesiune către o gazdă fără legătură merită o explicație înainte de a privi mai adânc. Apoi găsiți interfața de tunel pe client, pentru că un dispozitiv tun sau tap vă spune că clientul tratează pachete IP în loc să facă proxy pentru un singur flux de aplicație.

Captura pe interfața de tunel rezolvă de obicei întrebarea încărcăturii. Antetele lizibile de acolo înseamnă că pachetele interioare nu au fost niciodată criptate separat, în timp ce încărcăturile cu entropie mare înseamnă că au fost. Repetați captura pe interfața exterioară și comparați-le pe cele două: dacă ambele par aleatorii, stratul interior face o muncă pe care cel exterior nu o poate anula.

Revizuiți încrederea pe care ați acordat-o de fapt

Un certificat rădăcină corporativ instalat este un fapt despre magazinul de încredere al clientului, nu o afirmație despre ce înregistrează sau inspectează vreun proxy. Stabiliți politica implementată și calea reală de conexiune în loc să deduceți comportamentul din prezența unei CA.

Pe echipamente administrate, întrebați administratorul ce componentă termină TLS, dacă clientul validează un certificat fixat sau unul public, și care este formatul încărcăturii. Acele trei răspunsuri produc o constatare pe care o puteți apăra mai târziu.

Scrieți rezultatul ca o graniță, nu ca un verdict. "TLS se termină la proxyul de inspecție, iar încărcătura interioară este criptată separat cu chei pe care le au doar punctele finale" este o afirmație verificabilă care supraviețuiește unei schimbări de furnizor. "WebSockets sunt sigure" nu.