TLS ry binne die beheerkanaal, nie die hele tonnel nie
Die eweknieë ruil hul eie pakkette uit, en TLS loop binne die beheer-uitruiling. ’n Proksie wat HTTPS verstaan, het geen idee wat hierdie verkeer is nie.
Om die woord TLS in ’n VPN-beskrywing raak te lees en af te lei dat ’n webproksie die verkeer sal verstaan, is ’n algemene kortpad. Binne hierdie protokol ruil die eweknieë hul eie pakkette uit, en TLS loop as deel van een kanaal binne daardie uitruiling. Die vrag waaroor die gebruiker hom bekommer, reis in ’n ander boodskapformaat, en daarom pas die twee nooit by ’n gewone HTTPS-sessie nie.
Die omhulsel kom eerste
Elke tonnelpakket begin met die protokol se eie kop: ’n boodskaptipe, ’n sleutelidentifiseerder en, oor ’n greiestroom-vervoer, ’n lengtevoorvoegsel wat aandui waar die pakket eindig. ’n Leser wat daardie omhulsel nie ontleed nie, kan nie weet waar die volgende veld begin nie.
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)
Daardie skets is ’n kaart eerder as ’n greitabel, want die presiese velde hang van die boodskaptipe af, hoewel die eerste okteet altyd die opkode en die sleutelidentifiseerder saam verpak. Om die boodskaptipe uit die poortnommer te raai, is hoe dekodeerders dit uiteindelik verkeerd benoem. Die volgorde is wat vir diagnose saak maak: vervoer, dan die protokolomhulsel, dan een van twee soorte werk. Lees die omhulsel voordat jy enige mening vorm oor wat daarop volg. ’n Dekodeerder wat op die verkeerde plek begin, lewer selfversekerde onsin.
Die betroubaarheidslaag hoort by die protokol
Beheerboodskappe het geordende, bevestigde aflewering nodig, en die protokol voorsien dit self met bevestigings en herversendings. ’n Bevestiging kan as sy eie boodskap aankom of saam met ’n ander beheerboodskap reis, wat spore onreëlmatig laat lyk vir enigiemand wat een skoon uitruiling verwag.
Die voordeel is dat die TLS-handdruk ’n betroubare draer kry selfs wanneer die buitenste vervoer UDP is. Die koste is dat ’n enkele datagram net ’n deel van daardie gesprek kan bevat, so om dit as ’n selfstandige TLS-rekord te behandel, lewer onsin. Hervergadering moet op die protokolvlak plaasvind. Daarom lyk ’n vasgevangde pakket selde soos ’n volledige handdrukstap.
Om die buitenste vervoer na TCP te skakel, verwyder nie hierdie laag nie. Betroubare vervoer beteken minder herversendings op die protokolvlak, nie dat die raamwerk verdwyn of dat die verkeer HTTP word nie.
Datapakkette gebruik ’n ander formaat
Sodra die sessie bestaan, kom die nuttige vrag as databoodskappe wat binneste IP-pakkette of Ethernet-raamwerke dra. Hulle word met hul eie sleutels en hul eie verwerking beskerm, en hulle is nie TLS-toepassingsrekords in enige sin wat ’n TLS-biblioteek sou aanvaar nie.
Daardie skeiding is in konfigurasie sigbaar: die beheerkanaal en die datakanaal het afsonderlike syferinstellings, so ’n logreël wat een noem, sê jou niks oor die ander nie. Om ’n sterk beheersyfer as bewys van ’n sterk datasyfer te lees, is ’n algemene verslagfout.
Hou ook ’n verwante wanopvatting uit die verduideliking. TLS is nie ’n publiekesleutelkanaal langs ’n simmetriese datakanaal nie, want TLS beskerm sy eie rekords simmetries sodra sleutels gevestig is. Die werklike onderskeid is rol en pakketformaat, nie watter soort kriptografie elke kant gebruik nie.
Waarom ’n HTTPS-proksie nie kan help nie
’n Proksie wat TLS termineer, verwag ’n TLS-rekordstroom en dan ’n toepassingsprotokol daarbinne. Hierdie protokol se beheerkanaal word binne sy eie raamwerk gedra met ’n betroubaarheidslaag daarom, so ’n terminerende proksie lees daardie raamwerk as korrupte invoer.
’n Deursigtige deurstuurder wat grepe of datagramme sonder interpretasie deurgee, kan werk, mits dit nie die stroom herskryf of hervergader nie. Die vraag om oor enige tussenganger te vra, is of dit die werklike vervoer en raamwerk deurstuur, nie of dit êrens TLS ondersteun nie. Vra dit voordat jy ’n aand aan proksiereëls spandeer. Die meeste mislukkings hier is argitektonies eerder as ’n ontbrekende instelling.
Om ’n spoor korrek te lees
Verwag eers ’n beheer-uitruiling, dan ’n veel groter aantal databoodskappe, albei op een vervoer. As die beheerfase voltooi en die datafase vasloopplek, gaan die fout oor sleutels, roetering of filtering van die datapad eerder as die handdruk. Vang ’n paar databoodskappe en kyk of hulle die kliënt hoegenaamd verlaat. Daardie enkele waarneming halveer die soektog.
Historiese sleutelmetode-beskrywings in die protokoldokumentasie impliseer nie dat ’n gegewe weergawe nog elke ou formaat ondersteun nie. Kontroleer die weergawe wat jy gebruik voordat jy ’n verwagting bou op ’n paragraaf wat beskryf hoe dinge vroeër gewerk het.