TLS udhëton brenda kanalit të kontrollit, jo nëpër gjithë tunelin

Të shohësh fjalën TLS në një përshkrim VPN dhe të konkludosh se një proxy web do ta kuptojë trafikun është një shkurtore e zakonshme. Brenda këtij protokolli palët shkëmbejnë paketat e tyre, dhe TLS punon si pjesë e një kanali brenda atij shkëmbimi. Ngarkesa që i intereson përdoruesit udhëton në një format tjetër mesazhi, dhe për këtë arsye të dyja nuk përputhen kurrë me një sesion normal HTTPS.

Zarfi vjen i pari

Çdo paketë tuneli fillon me kokën e vetë protokollit: një lloj mesazhi, një identifikues çelësi dhe, mbi një transport rryme bajtesh, një prefiks gjatësie që shënon ku përfundon paketa. Një lexues që nuk e analizon atë zarf nuk mund ta dijë ku fillon fusha tjetër.

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)

Ai skicë është një hartë dhe jo një tabelë bajtesh, sepse fushat e sakta varen nga lloji i mesazhit, megjithëse okteti i parë i paketon gjithmonë së bashku kodin e operacionit dhe identifikuesin e çelësit. Të hamendësosh llojin e mesazhit nga numri i portit është mënyra se si dekoduesit përfundojnë duke emërtuar gabimisht atë që shohin. Rendi është ai që ka rëndësi për diagnostikimin: transporti, pastaj zarfi i protokollit, pastaj një nga dy llojet e punës. Lexo zarfin para se të formosh ndonjë mendim për atë që vjen më pas. Një dekodues që fillon në vendin e gabuar prodhon marrëzi të vetësigurt.

Shtresa e besueshmërisë i takon protokollit

Mesazhet e kontrollit kërkojnë dërgim të renditur dhe të konfirmuar, dhe protokolli e siguron vetë këtë me konfirmime dhe ritransmetime. Një konfirmim mund të vijë si mesazh i vetë ose të udhëtojë me një mesazh tjetër kontrolli, gjë që i bën gjurmët të duken të parregullta për këdo që pret një shkëmbim të pastër.

Avantazhi është se shtrëngimi i duarve TLS merr një bartës të besueshëm edhe kur transporti i jashtëm është UDP. Kostoja është se një datagram i vetëm mund të përmbajë vetëm një pjesë të atij bisedimi, kështu që trajtimi i tij si një regjistrim TLS i pavarur prodhon marrëzi. Rimontimi duhet të ndodhë në shtresën e protokollit. Prandaj një paketë e kapur rrallë duket si një hap i plotë i shtrëngimit të duarve.

Ndërrimi i transportit të jashtëm në TCP nuk e heq këtë shtresë. Transport i besueshëm do të thotë më pak ritransmetime në nivel protokolli, jo që kornizimi zhduket ose që trafiku bëhet HTTP.

Paketat e të dhënave përdorin një format tjetër

Pasi sesioni ekziston, ngarkesa e dobishme vjen si mesazhe të dhënash që mbajnë paketa IP të brendshme ose korniza Ethernet. Ato mbrohen me çelësat e tyre dhe përpunimin e tyre, dhe nuk janë regjistrime aplikacioni TLS në asnjë kuptim që do të pranonte një bibliotekë TLS.

Ai ndarje është e dukshme në konfigurim: kanali i kontrollit dhe kanali i të dhënave kanë cilësime të veçanta shifrimi, kështu që një rresht log që emërton njërin nuk thotë asgjë për tjetrin. Të lexosh një shifrim të fortë kontrolli si provë të një shifrimi të fortë të dhënash është një gabim i zakonshëm raportimi.

Mbaj edhe një keqkuptim të lidhur jashtë shpjegimit. TLS nuk është një kanal me çelës publik pranë një kanali të dhënash simetrik, sepse vetë TLS i mbron regjistrimet e tij në mënyrë simetrike pasi çelësat janë vendosur. Dallimi i vërtetë është roli dhe formati i paketës, jo çfarë lloj kriptografie përdor secila palë.

Pse një proxy HTTPS nuk mund të ndihmojë

Një proxy që përfundon TLS pret një rrymë regjistrimesh TLS dhe pastaj një protokoll aplikacioni brenda saj. Kanali i kontrollit i këtij protokolli bartet brenda kornizimit të vet me një shtresë besueshmërie përreth, kështu që një proxy që përfundon e lexon atë kornizim si hyrje të korruptuar.

Një përcjellës transparent që lë të kalojnë bajt ose datagrame pa i interpretuar mund të funksionojë, me kusht që të mos e rishkruajë ose rimontojë rrymën. Pyetja që duhet bërë për çdo ndërmjetës është nëse ai përcjell transportin dhe kornizimin e vërtetë, jo nëse mbështet TLS diku. Pyete këtë përpara se të shpenzosh një mbrëmje me rregullat e proxy-t. Shumica e dështimeve këtu janë arkitekturore dhe jo një cilësim që mungon.

Leximi i saktë i një gjurme

Prit fillimisht një shkëmbim kontrolli, pastaj një numër shumë më të madh mesazhesh të dhënash, të dyja ndajnë një transport. Nëse faza e kontrollit përfundon dhe faza e të dhënave ngec, defekti ka të bëjë me çelësat, rrugëtimin ose filtrimin e rrugës së të dhënave dhe jo me shtrëngimin e duarve. Kap disa mesazhe të dhënash dhe kontrollo nëse ato largohen fare nga klienti. Ai një vëzhgim e ndan kërkimin në gjysmë.

Përshkrimet historike të metodave të çelësit në dokumentacionin e protokollit nuk nënkuptojnë që një version i caktuar ende mbështet çdo format të vjetër. Kontrollo versionin që ekzekuton përpara se të ndërtosh një pritshmëri mbi një paragraf që përshkruan si funksiononin gjërat më parë.