WSS-tunneli krüpteerimine lõpeb TLS-lõpetajas, mitte rakenduses

Turvalise WebSocketi sees transporditaval tunnelil on täpselt nii palju krüpteeringut, kui klient sinna pani, mitte rohkem. Skeem wss:// ütleb, et TLS kaitseb ühte ühendust ühel hüppel. See ei ütle midagi selle kohta, kas WebSocket-sõnumite sees olevad baidid on eraldi kaitstud, ja see erinevus otsustab, kes saab teie liiklust lugeda, kui miski keskel TLS-i lõpetab.

Kaks kihti, mis näivad ühena

Turvaline WebSocket on TLS, mille peal tehakse WebSocketi kätlus, nagu RFC 6455 kirjeldab oma ühenduse ja turvalisuse jaotistes. TLS-kiht autendib serveri ja krüpteerib voo, seejärel raamib WebSocketi kiht selle, mida rakendus otsustab saata.

Need on kaks sõltumatut otsust ja skeem, mis joonistab ühe luku kogu tee kohale, varjab teise. Küsige, kes lõpetab TLS-ühenduse. Seejärel küsige, mida klient iga sõnumi sisse paneb. Kõik muu juurutuse kohta tuleneb neist kahest vastusest.

Disain A: transport on ainus krüpteering

Lihtsamas disainis võtab klient toored IP-paketid ja mässib need WebSocket-sõnumitesse. Sees ei ole miski krüpteeritud, seega TLS-sessiooni hoidev komponent loeb lihtteksti koormusi. Kui see komponent on teie enda tunneliserver, on see kavandatud lõpp-punkt ja disain on sidus, sest server oleks liiklust nagunii näinud.

Sellest saab teistsugune korraldus, kui teele asub kontrollproksi ja lõpetab TLS-i sertifikaadiga, mida klient usaldab. See proksi hoiab nüüd sama lihtteksti, mida server oleks hoidnud, ja mingi kogus WebSocketi raamimist ei muuda seda. Kliendi usaldushoidla otsustas selle tulemuse ammu enne tunneli avamist, sest valis selle sertifikaadi selle nime jaoks vastu võtta. Proksi näeb ka taotletud hosti ja iga sõnumi suurust, millest piisab paljude tegevuste sõrmejälje võtmiseks ilma midagi rohkemat dekrüpteerimata.

Disain B: koormus kannab oma võtmeid

Teises disainis krüpteerib ja autendib klient oma paketid VPN-protokolliga, millel on oma partneri identiteet ja võtmevahetus, ning kannab seejärel tulemuse WebSocket-sõnumite sees. Välise TLS-i lõpetamine siin paljastab šifreeritud teksti, mitte liikluse. Proksi näeb sõnumite suurusi ja aega ning koormuses midagi muud. See on palju väiksem kokkupuude ja ometi metateave, mida tasub ülevaates nimetada, mitte kõrvale heita.

Sisemise protokolli enda lõpp-punktid näevad endiselt lihtteksti, mis on korralduse mõte ja ka selle piir. Kui lõpp-punkti komponent on volitatud andmeid lugema enne krüpteerimist või pärast dekrüpteerimist, siis lisakiht teda ei piira. Võtmed ja neid käsitlev tarkvara jäävad piiriks, millel on tähtsust.

VPN-i silt, tuttav kliendiikoon või turundusleht ei ole tõestus, et see disain olemas on. Koormuse vormingu lugemine on.

Jälgige, kus lihttekst tegelikult ilmub

URL-i skeem annab teile ühe fakti, ülejäänu hankige liidestest. Käivitage allolevad kontrollid järjekorras, sest igaüks kitsendab järgmist:

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

Alustage välisest ühendusest. Üks pikaajaline TCP-sessioon TLS-pordi vastu on see, kuidas WebSocketi kandja välja näeb, ja teine sessioon seotud mitteoleva hosti vastu väärib selgitust enne sügavamale vaatamist. Seejärel leidke kliendis tunneli liides, sest tun- või tap-seade ütleb, et klient käsitleb IP-pakette, mitte ei proksita ühte rakendusvoogu.

Tunneli liidesel tehtud püüdmine lahendab tavaliselt koormusküsimuse. Loejavad päised seal tähendavad, et sisemisi pakette ei krüpteeritud kunagi eraldi, samas kui suure entroopiaga koormused tähendavad, et krüpteeriti. Korrake püüdmist välisliidesel ja võrrelge mõlemat: kui mõlemad näivad juhuslikud, teeb sisemine kiht tööd, mida välimine ei saa tagasi pöörata.

Vaadake üle usaldus, mille tegelikult andsite

Paigaldatud ettevõtte juursertifikaat on fakt kliendi usaldushoidla kohta, mitte väide selle kohta, mida ükski proksi logib või kontrollib. Tehke kindlaks juurutatud poliitika ja tegelik ühendustee, selle asemel et tuletada käitumist CA olemasolust.

Hallatud seadmetel küsige administraatorilt, milline komponent TLS-i lõpetab, kas klient valideerib kinnitatud või avalikku sertifikaati, ja milline on koormuse vorming. Need kolm vastust annavad järelduse, mida saate hiljem kaitsta.

Kirjutage tulemus piirina, mitte otsusena. "TLS lõpeb kontrollproksil ja sisemine koormus on eraldi krüpteeritud võtmetega, mida hoiavad ainult lõpp-punktid" on kontrollitav väide, mis peab vastu tarnija vahetusele. "WebSockets on turvaline" ei ole.