WSS-tunnelin salaus päättyy TLS-päättäjään, ei sovellukseen

Suojatun WebSocketin sisällä kuljetettavassa tunnelissa on täsmälleen niin paljon salausta kuin asiakas siihen laittoi, ei enempää. wss://-skeema kertoo, että TLS suojaa yhtä yhteyttä yhdellä hypyllä. Se ei kerro mitään siitä, suojataanko WebSocket-viestien sisällä olevat tavut erikseen, ja juuri tämä ero ratkaisee, kuka voi lukea liikennettäsi, kun jokin välissä päättää TLS:n.

Kaksi kerrosta, jotka näyttävät yhdeltä

Suojattu WebSocket on TLS, jonka yli suoritetaan WebSocket-kättely, kuten RFC 6455 kuvaa yhteys- ja turvallisuusosissaan. TLS-kerros todentaa palvelimen ja salaa virran, sitten WebSocket-kerros kehystää sen, mitä sovellus päättää lähettää.

Ne ovat kaksi riippumatonta päätöstä, ja kaavio, joka piirtää yhden lukon koko polun yli, kätkee toisen. Kysy, kuka päättää TLS-yhteyden. Kysy sitten, mitä asiakas laittaa kunkin viestin sisään. Kaikki muu käyttöönotosta seuraa näistä kahdesta vastauksesta.

Malli A: siirto on ainoa salaus

Yksinkertaisemmassa mallissa asiakas ottaa raa'at IP-paketit ja käärii ne WebSocket-viesteihin. Sisällä ei ole mitään salattua, joten TLS-istuntoa pitävä komponentti lukee selkokielisiä hyötykuormia. Kun tuo komponentti on oma tunnelipalvelimesi, tämä on tarkoitettu päätepiste ja malli on johdonmukainen, koska palvelin olisi joka tapauksessa nähnyt liikenteen.

Siitä tulee toisenlainen järjestely, kun tarkastusvälityspalvelin istuu polulla ja päättää TLS:n varmenteella, johon asiakas luottaa. Tuolla välityspalvelimella on nyt sama selkokielinen teksti, joka palvelimella olisi ollut, eikä mikään määrä WebSocket-kehystystä muuta sitä. Asiakkaan luottamusvarasto päätti tämän tuloksen kauan ennen kuin tunneli avautui, koska se valitsi hyväksyä tuon varmenteen tuolle nimelle. Välityspalvelin näkee myös pyydetyn isännän ja kunkin viestin koon, mikä riittää monen toiminnan sormenjälkeen ilman, että mitään enää puretaan.

Malli B: hyötykuorma kantaa omat avaimensa

Toisessa mallissa asiakas salaa ja todentaa pakettinsa VPN-protokollalla, jolla on oma vertaisidentiteettinsä ja avaintenvaihtonsa, ja kuljettaa sitten tuloksen WebSocket-viestien sisällä. Ulomman TLS:n päättäminen tässä paljastaa salatekstiä, ei liikennettä. Välityspalvelin näkee viestien koot ja ajoituksen, eikä mitään muuta hyötykuormasta. Se on paljon pienempi altistus, ja silti se on metatietoa, joka kannattaa nimetä katselmoinnissa sen sijaan, että se sivuutettaisiin.

Sisemmän protokollan omat päätepisteet näkevät yhä selkokielistä tekstiä, mikä on järjestelyn tarkoitus ja myös sen raja. Jos päätepisteen komponentti on valtuutettu lukemaan tietoja ennen salausta tai salauksen purkamisen jälkeen, lisäkerros ei rajoita sitä. Avaimet ja niitä käsittelevä ohjelmisto pysyvät rajana, jolla on merkitystä.

VPN-tarra, tuttu asiakaskuvake tai markkinointisivu eivät ole todiste tämän mallin olemassaolosta. Hyötykuorman muodon lukeminen on.

Jäljitä, mihin selkokielinen teksti todella ilmestyy

URL-skeema antaa yhden tosiasian, joten hae loput rajapinnoista. Suorita alla olevat tarkistukset järjestyksessä, koska jokainen kaventaa seuraavaa:

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

Aloita ulommasta yhteydestä. Yksi pitkäikäinen TCP-istunto TLS-porttiin on se, miltä WebSocket-kantaja näyttää, ja toinen istunto asiaankuulumattomaan isäntään ansaitsee selityksen ennen kuin katsot syvemmälle. Etsi sitten tunneliliittymä asiakkaalta, koska tun- tai tap-laite kertoo asiakkaan käsittelevän IP-paketteja sen sijaan, että se välittäisi yhtä sovellusvirtaa.

Tunneliliittymän kaappaus ratkaisee yleensä hyötykuormakysymyksen. Luettavat otsikot siellä tarkoittavat, ettei sisempiä paketteja koskaan salattu erikseen, kun taas korkean entropian hyötykuormat tarkoittavat, että ne salattiin. Toista kaappaus ulommalla liittymällä ja vertaa kahta: jos molemmat näyttävät satunnaisilta, sisempi kerros tekee työtä, jota ulompi ei voi peruuttaa.

Tarkastele luottamusta, jonka todella annoit

Asennettu yrityksen juurivarmenne on tosiasia asiakkaan luottamusvarastosta, ei väite siitä, mitä mikä tahansa välityspalvelin lokittaa tai tarkastaa. Selvitä käyttöön otettu käytäntö ja todellinen yhteyspolku sen sijaan, että päättelet käyttäytymisen CA:n olemassaolosta.

Hallinnoiduilla laitteilla kysy järjestelmänvalvojalta, mikä komponentti päättää TLS:n, validoiko asiakas kiinnitetyn varmenteen vai julkisen, ja mikä hyötykuorman muoto on. Nuo kolme vastausta tuottavat havainnon, jota voit puolustaa myöhemmin.

Kirjoita tulos rajana, ei tuomiona. "TLS päättyy tarkastusvälityspalvelimella, ja sisempi hyötykuorma on salattu erikseen avaimilla, joita vain päätepisteet pitävät" on tarkistettava väite, joka kestää toimittajan vaihtumisen. "WebSockets on turvallinen" ei kestä.