WSS tuneļa šifrēšana beidzas pie TLS terminētāja, nevis lietotnē

Tunelim, kas tiek pārvadāts drošā WebSocket iekšpusē, ir tieši tik daudz šifrēšanas, cik klients tajā ielicis, ne vairāk. Shēma wss:// saka, ka TLS aizsargā vienu savienojumu vienā lēcienā. Tā neko nepasaka par to, vai baiti WebSocket ziņojumu iekšpusē ir aizsargāti atsevišķi, un tieši šī atšķirība izšķir, kas var lasīt jūsu datplūsmu, kad kaut kas pa vidu pabeidz TLS.

Divi slāņi, kas izskatās kā viens

Drošs WebSocket ir TLS, uz kura tiek veikta WebSocket rokasspiediena procedūra, kā RFC 6455 apraksta sadaļās par savienojumu un drošību. TLS slānis autentificē serveri un šifrē plūsmu, pēc tam WebSocket slānis ierāmē to, ko lietotne nolemj nosūtīt.

Tie ir divi neatkarīgi lēmumi, un diagramma, kas visā ceļā uzzīmē vienu slēdzeni, paslēpj otru. Pajautājiet, kas pabeidz TLS savienojumu. Pēc tam pajautājiet, ko klients ievieto katrā ziņojumā. Viss pārējais par izvietošanu izriet no šīm divām atbildēm.

Dizains A: transports ir vienīgā šifrēšana

Vienkāršākajā dizainā klients ņem neapstrādātus IP paketes un ietin tās WebSocket ziņojumos. Iekšpusē nekas nav šifrēts, tāpēc komponents, kas tur TLS sesiju, lasa atklāta teksta slodzes. Ja šis komponents ir jūsu pašu tuneļa serveris, tas ir paredzētais galapunkts un dizains ir saskaņots, jo serveris datplūsmu tik un tā redzētu.

Tas kļūst par citu izkārtojumu, kad ceļā atrodas pārbaudes starpniekservers un pabeidz TLS ar sertifikātu, kuram klients uzticas. Šim starpniekserverim tagad ir tas pats atklātais teksts, kas būtu serverim, un neviens WebSocket ierāmēšanas daudzums to nemaina. Klienta uzticības krātuve šo iznākumu izlēma daudz pirms tuneļa atvēršanas, jo tā izvēlējās pieņemt šo sertifikātu šim vārdam. Starpniekservers arī redz pieprasīto resursdatoru un katra ziņojuma lielumu, ar ko pietiek, lai nospiestu pirkstu nospiedumu daudzām aktivitātēm, neko vairāk neatšifrējot.

Dizains B: slodze nes savas atslēgas

Otrajā dizainā klients šifrē un autentificē savas paketes ar VPN protokolu, kam ir sava partnera identitāte un atslēgu apmaiņa, pēc tam pārvadā rezultātu WebSocket ziņojumos. Ārējā TLS pabeigšana šeit atklāj šifrētu tekstu, nevis datplūsmu. Starpniekservers redz ziņojumu lielumus un laiku, un neko citu slodzē. Tā ir daudz mazāka pakļautība, un tomēr tie ir metadati, ko ir vērts nosaukt pārskatā, nevis noslaucīt nost.

Iekšējā protokola paša galapunkti joprojām redz atklātu tekstu, un tā ir šī izkārtojuma būtība un arī tā robeža. Ja komponents galapunktā ir pilnvarots lasīt datus pirms šifrēšanas vai pēc atšifrēšanas, papildu slānis to neierobežo. Atslēgas un tās apstrādājošā programmatūra paliek robeža, kurai ir nozīme.

VPN etiķete, pazīstama klienta ikona vai mārketinga lapa nav pierādījums, ka šis dizains pastāv. Slodzes formāta lasīšana ir.

Izsekojiet, kur atklātais teksts patiešām parādās

URL shēma dod vienu faktu, tāpēc pārējo iegūstiet no saskarnēm. Izpildiet tālāk minētās pārbaudes pēc kārtas, jo katra sašaurina nākamo:

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

Sāciet ar ārējo savienojumu. Viena ilgmūžīga TCP sesija uz TLS portu ir tas, kā izskatās WebSocket pārvadātājs, un otra sesija uz nesaistītu resursdatoru ir pelnījusi skaidrojumu pirms lūkošanās dziļāk. Pēc tam atrodiet tuneļa saskarni klientā, jo tun vai tap ierīce pasaka, ka klients apstrādā IP paketes, nevis starpnieko vienu lietotnes plūsmu.

Uzņemšana tuneļa saskarnē parasti atrisina slodzes jautājumu. Tur lasāmi galveni nozīmē, ka iekšējās paketes nekad nav šifrētas atsevišķi, savukārt augstas entropijas slodzes nozīmē, ka tās tika šifrētas. Atkārtojiet uzņemšanu ārējā saskarnē un salīdziniet abas: ja abas izskatās nejaušas, iekšējais slānis dara darbu, ko ārējais nevar atsaukt.

Pārskatiet uzticību, ko patiešām piešķīrāt

Instalēts uzņēmuma saknes sertifikāts ir fakts par klienta uzticības krātuvi, nevis apgalvojums par to, ko jebkurš starpniekserveris reģistrē vai pārbauda. Nosakiet ieviesto politiku un reālo savienojuma ceļu, tā vietā lai secinātu uzvedību no CA klātbūtnes.

Pārvaldītā aparatūrā jautājiet administratoram, kurš komponents pabeidz TLS, vai klients validē piespraustu sertifikātu vai publisku, un kāds ir slodzes formāts. Šīs trīs atbildes dod atradumu, ko vēlāk varēsiet aizstāvēt.

Rakstiet rezultātu kā robežu, nevis spriedumu. "TLS beidzas pārbaudes starpniekserverī, un iekšējā slodze ir atsevišķi šifrēta ar atslēgām, kas ir tikai galapunktiem" ir pārbaudāms apgalvojums, kas iztur piegādātāja maiņu. "WebSockets ir droši" nav.