Kriptimi i tunelit WSS ndalon te terminatori TLS, jo te aplikacioni

Një tunel i transportuar brenda një WebSocket të sigurt ka saktësisht aq kriptim sa klienti ka vendosur në të, jo më shumë. Skema wss:// thotë se TLS mbron një lidhje në një hop. Nuk thotë asgjë për atë nëse bajtët brenda mesazheve WebSocket janë të mbrojtur veçmas, dhe pikërisht ky dallim vendos kush mund të lexojë trafikun tuaj kur diçka në mes përfundon TLS.

Dy shtresa që duken si një

Një WebSocket i sigurt është TLS me një shtrëngim duarsh WebSocket të kryer mbi të, siç përshkruan RFC 6455 në seksionet e lidhjes dhe të sigurisë. Shtresa TLS vërteton serverin dhe kripton rrjedhën, pastaj shtresa WebSocket kornizon atë që aplikacioni vendos të dërgojë.

Këto janë dy vendime të pavarura, dhe një diagram që vizaton një dry të vetëm mbi gjithë rrugën fsheh të dytin. Pyetni kush e përfundon lidhjen TLS. Pastaj pyetni çfarë vendos klienti brenda çdo mesazhi. Gjithçka tjetër për vendosjen rrjedh nga këto dy përgjigje.

Dizajni A: transporti është i vetmi kriptim

Në dizajnin më të thjeshtë, klienti merr paketa IP të papërpunuara dhe i mbështjell në mesazhe WebSocket. Asgjë brenda nuk është e kriptuar, kështu që komponenti që mban sesionin TLS lexon ngarkesa në tekst të thjeshtë. Kur ai komponent është serveri juaj i tunelit, ky është pika e fundit e synuar dhe dizajni është koherent, sepse serveri gjithsesi do ta shihte trafikun.

Bëhet një rregullim tjetër kur një proxy inspektimi qëndron në rrugë dhe e përfundon TLS me një certifikatë që klienti e beson. Ai proxy tani mban të njëjtin tekst të thjeshtë që do të kishte mbajtur serveri, dhe asnjë sasi kornizimi WebSocket nuk e ndryshon këtë. Depoja e besimit e klientit e vendosi këtë rezultat shumë përpara se tuneli të hapej, sepse zgjodhi ta pranojë atë certifikatë për atë emër. Proxy gjithashtu sheh hostin e kërkuar dhe madhësinë e çdo mesazhi, që mjafton për të marrë gjurmë gishtash të shumë aktiviteteve pa dekriptuar asgjë tjetër.

Dizajni B: ngarkesa mban çelësat e vet

Në dizajnin e dytë, klienti i kripton dhe vërteton paketat e tij me një protokoll VPN që ka identitetin dhe shkëmbimin e çelësave të vet, pastaj e transporton rezultatin brenda mesazheve WebSocket. Përfundimi i TLS të jashtëm këtu ekspozon tekst të kriptuar, jo trafik. Proxy mund të shohë madhësitë dhe kohën e mesazheve, dhe asgjë tjetër në ngarkesë. Ky është një ekspozim shumë më i vogël, dhe gjithsesi janë metadato që ia vlen të përmenden në një rishikim në vend që të hidhen poshtë.

Pikat fundore të protokollit të brendshëm ende shohin tekst të thjeshtë, që është qëllimi i rregullimit dhe njëkohësisht kufiri i tij. Nëse një komponent në pikën fundore është i autorizuar të lexojë të dhëna para kriptimit ose pas dekriptimit, shtresa shtesë nuk e kufizon. Çelësat, dhe softueri që i trajton, mbeten kufiri që ka rëndësi.

Një etiketë VPN, një ikonë e njohur klienti ose një faqe marketingu nuk janë provë se ky dizajn ekziston. Leximi i formatit të ngarkesës është provë.

Gjurmo ku shfaqet në të vërtetë teksti i thjeshtë

Skema e URL-së ju jep një fakt, ndaj merrni pjesën tjetër nga ndërfaqet. Kryeni kontrollet më poshtë me radhë, sepse secila e ngushton tjetrën:

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

Filloni me lidhjen e jashtme. Një sesion TCP jetëgjatë drejt portës TLS është pamja e një transportuesi WebSocket, dhe një sesion i dytë drejt një hosti të palidhur meriton shpjegim përpara se të shikoni më thellë. Pastaj gjeni ndërfaqen e tunelit në klient, sepse një pajisje tun ose tap ju tregon se klienti po trajton paketa IP në vend që të proxy-ojë një rrjedhë të vetme aplikacioni.

Kapja në ndërfaqen e tunelit zakonisht e zgjidh çështjen e ngarkesës. Titujt e lexueshëm atje nënkuptojnë se paketat e brendshme nuk u kriptuan kurrë veçmas, ndërsa ngarkesat me entropi të lartë nënkuptojnë se u kriptuan. Përsëritni kapjen në ndërfaqen e jashtme dhe krahasoni të dyja: nëse të dyja duken të rastësishme, shtresa e brendshme po bën punë që e jashtmja nuk mund ta zhbëjë.

Rishikoni besimin që keni dhënë në të vërtetë

Një certifikatë rrënjësore korporative e instaluar është fakt për depon e besimit të klientit, jo një deklaratë për atë që regjistron ose inspekton çdo proxy. Përcaktoni politikën e vendosur dhe rrugën reale të lidhjes në vend që të nxirrni sjellje nga prania e një CA.

Në pajisje të menaxhuara, pyetni administratorin se cili komponent e përfundon TLS, nëse klienti vërteton një certifikatë të fiksuar apo një publike, dhe cili është formati i ngarkesës. Ato tre përgjigje prodhojnë një gjetje që mund ta mbroni më vonë.

Shkruajeni rezultatin si kufi dhe jo si verdikt. "TLS përfundon te proxy i inspektimit, dhe ngarkesa e brendshme është e kriptuar veçmas me çelësa që i kanë vetëm pikat fundore" është një pohim i verifikueshëm që i mbijeton një ndryshimi furnizuesi. "WebSockets janë të sigurt" nuk i mbijeton.