TLS circulă în interiorul canalului de control, nu prin tot tunelul

Să vezi cuvântul TLS într-o descriere VPN și să concluzionezi că un proxy web va înțelege traficul este o scurtătură obișnuită. În interiorul acestui protocol partenerii își schimbă propriile pachete, iar TLS rulează ca parte a unui canal din acel schimb. Sarcina utilă care contează pentru utilizator călătorește într-un alt format de mesaj, motiv pentru care cele două nu se potrivesc niciodată cu o sesiune HTTPS obișnuită.

Plicul vine primul

Fiecare pachet de tunel începe cu antetul propriu al protocolului: un tip de mesaj, un identificator de cheie și, pe un transport în flux de octeți, un prefix de lungime care marchează unde se termină pachetul. Un cititor care nu analizează acel plic nu poate ști unde începe următorul câmp.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Această schiță este o hartă și nu un tabel de octeți, deoarece câmpurile exacte depind de tipul mesajului, deși primul octet împachetează întotdeauna codul de operație și identificatorul de cheie împreună. Ghitirea tipului de mesaj după numărul de port este felul în care decodoarele ajung să denumească greșit ceea ce văd. Ordinea este ce contează pentru diagnostic: transport, apoi plicul protocolului, apoi unul dintre cele două tipuri de muncă. Citește plicul înainte de a-ți forma o părere despre ce urmează. Un decodor care începe în locul greșit produce prostii încrezătoare.

Stratul de fiabilitate aparține protocolului

Mesajele de control au nevoie de livrare ordonată și confirmată, iar protocolul o asigură singur prin confirmări și retransmisii. O confirmare poate sosi ca mesaj propriu sau poate călători cu un alt mesaj de control, ceea ce face urmele să pară neregulate pentru oricine așteaptă un singur schimb curat.

Avantajul este că strângerea de mână TLS primește un purtător fiabil chiar și atunci când transportul exterior este UDP. Costul este că un singur datagramă poate conține doar o parte din acea conversație, așa că tratarea lui ca înregistrare TLS de sine stătătoare produce prostii. Reasamblarea trebuie să aibă loc la nivelul protocolului. De aceea un pachet capturat rareori arată ca un pas complet al strângerii de mână.

Trecerea transportului exterior la TCP nu elimină acest strat. Transport fiabil înseamnă mai puține retransmisii la nivel de protocol, nu că încadrarea dispare sau că traficul devine HTTP.

Pachetele de date folosesc un format diferit

Odată ce sesiunea există, sarcina utilă sosește ca mesaje de date care transportă pachete IP interne sau cadre Ethernet. Sunt protejate cu propriile chei și propria prelucrare și nu sunt înregistrări de aplicație TLS în niciun sens pe care o bibliotecă TLS l-ar accepta.

Această separare este vizibilă în configurație: canalul de control și canalul de date au setări de cifrare separate, așa că o linie de jurnal care numește unul nu spune nimic despre celălalt. Citirea unei cifrări de control puternice ca dovadă a unei cifrări de date puternice este o eroare frecventă de raportare.

Ține și o concepție greșită înrudită în afara explicației. TLS nu este un canal cu cheie publică aflat lângă un canal de date simetric, pentru că TLS însuși își protejează înregistrările simetric odată ce cheile sunt stabilite. Distincția reală este rolul și formatul pachetului, nu ce tip de criptografie folosește fiecare parte.

De ce un proxy HTTPS nu poate ajuta

Un proxy care termină TLS așteaptă un flux de înregistrări TLS și apoi un protocol de aplicație în interiorul lui. Canalul de control al acestui protocol este purtat în interiorul propriei încadrări, cu un strat de fiabilitate în jurul ei, așa că un proxy care termină citește acea încadrare ca intrare coruptă.

Un redirector transparent care lasă să treacă octeți sau datagrame fără să le interpreteze poate funcționa, cu condiția să nu rescrie și să nu reasambleze fluxul. Întrebarea care trebuie pusă despre orice intermediar este dacă transmite transportul și încadrarea reale, nu dacă acceptă TLS undeva. Întreabă asta înainte de a petrece o seară pe reguli de proxy. Majoritatea eșecurilor de aici sunt arhitecturale și nu o setare lipsă.

Citirea corectă a unei urme

Așteaptă-te mai întâi la un schimb de control, apoi la un număr mult mai mare de mesaje de date, ambele împărțind un transport. Dacă faza de control se încheie și faza de date se blochează, defecțiunea privește cheile, rutarea sau filtrarea căii de date și nu strângerea de mână. Capturează câteva mesaje de date și verifică dacă părăsesc clientul. Acea singură observație împarte căutarea în două.

Descrierile istorice ale metodelor de cheie din documentația protocolului nu implică faptul că o anumită versiune mai suportă fiecare format vechi. Verifică versiunea pe care o rulezi înainte de a construi o așteptare pe un paragraf care descrie cum funcționau lucrurile odinioară.