TLS kører inde i kontrolkanalen, ikke gennem hele tunnelen

At se ordet TLS i en VPN-beskrivelse og konkludere, at en webproxy vil forstå trafikken, er en almindelig genvej. Inde i denne protokol udveksler parterne deres egne pakker, og TLS kører som en del af én kanal i den udveksling. Den nyttelast, brugeren bekymrer sig om, rejser i et andet meddelelsesformat, og derfor passer de to aldrig sammen med en almindelig HTTPS-session.

Kuverten kommer først

Hver tunnelpakke begynder med protokollens eget header: en meddelelsestype, en nøgleidentifikator og, over en bytestrømstransport, et længdepræfiks, der markerer, hvor pakken slutter. En læser, der ikke parser den kuvert, kan ikke vide, hvor det næste felt begynder.

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)

Den skitse er et kort og ikke en bytetabel, fordi de præcise felter afhænger af meddelelsestypen, selvom den første oktet altid pakker opkoden og nøgleidentifikatoren sammen. At gætte meddelelsestypen ud fra portnummeret er, hvordan dekodere ender med at kalde det, de ser, forkert. Rækkefølgen er det, der betyder noget for diagnosticering: transport, derefter protokollens kuvert, derefter en af to slags arbejde. Læs kuverten, før du danner dig en mening om det, der følger. En dekoder, der starter det forkerte sted, producerer selvsikker nonsens.

Pålidelighedslaget hører til protokollen

Kontrolmeddelelser kræver ordnet, bekræftet levering, og protokollen sørger selv for det med bekræftelser og gensendinger. En bekræftelse kan ankomme som sin egen meddelelse eller rejse med en anden kontrolmeddelelse, hvilket får spor til at se uregelmæssige ud for enhver, der forventer én ren udveksling.

Fordelen er, at TLS-håndtrykket får en pålidelig bærer, selv når den ydre transport er UDP. Prisen er, at et enkelt datagram måske kun indeholder en del af den samtale, så at behandle det som en selvstændig TLS-post producerer nonsens. Genopsamling skal ske på protokollaget. Derfor ligner en opfanget pakke sjældent et fuldstændigt håndtrykstrin.

At skifte den ydre transport til TCP fjerner ikke dette lag. Pålidelig transport betyder færre gensendinger på protokolniveau, ikke at indramningen forsvinder, eller at trafikken bliver HTTP.

Datapakker bruger et andet format

Når sessionen findes, ankommer den nyttige last som datameddelelser, der bærer indre IP-pakker eller Ethernet-rammer. De er beskyttet med deres egne nøgler og deres egen behandling, og de er ikke TLS-applikationsposter i nogen forstand, som et TLS-bibliotek ville acceptere.

Denne adskillelse er synlig i konfigurationen: kontrolkanalen og datakanalen har separate chifferindstillinger, så en loglinje, der navngiver den ene, fortæller dig intet om den anden. At læse en stærk kontrolchiffer som bevis på en stærk datachiffer er en almindelig rapporteringsfejl.

Hold også en relateret misforståelse ude af forklaringen. TLS er ikke en offentlig nøgle-kanal, der sidder ved siden af en symmetrisk datakanal, fordi TLS selv beskytter sine poster symmetrisk, når nøglerne er etableret. Den virkelige forskel er rolle og pakkeformat, ikke hvilken slags kryptografi hver side bruger.

Hvorfor en HTTPS-proxy ikke kan hjælpe

En proxy, der terminerer TLS, forventer en TLS-poststrøm og derefter en applikationsprotokol inde i den. Denne protokols kontrolkanal bæres inde i sin egen indramning med et pålidelighedslag omkring, så en terminerende proxy læser den indramning som korrupt input.

En transparent videresender, der sender bytes eller datagrammer videre uden at fortolke dem, kan fungere, forudsat at den ikke omskriver eller genopsamler strømmen. Spørgsmålet, man bør stille om enhver mellemled, er, om den videresender den faktiske transport og indramning, ikke om den understøtter TLS et eller andet sted. Spørg om det, før du bruger en aften på proxyregler. De fleste fejl her er arkitektoniske snarere end en manglende indstilling.

At læse et spor korrekt

Forvent først en kontroludveksling, derefter et meget større antal datameddelelser, som begge deler én transport. Hvis kontrolfasen fuldføres, og datafasen går i stå, vedrører fejlen nøgler, routing eller filtrering af datastien snarere end håndtrykket. Optag nogle få datameddelelser, og kontroller, om de overhovedet forlader klienten. Den ene observation deler søgningen på midten.

Historiske nøglemetodebeskrivelser i protokoldokumentationen betyder ikke, at en given udgivelse stadig understøtter ethvert gammelt format. Kontroller den version, du kører, før du bygger en forventning på et afsnit, der beskriver, hvordan tingene plejede at fungere.