TLS reser inuti kontrollkanalen, inte genom hela tunneln

Att se ordet TLS i en VPN-beskrivning och dra slutsatsen att en webbproxy kommer att förstå trafiken är en vanlig genväg. Inuti detta protokoll utbyter paren sina egna paket, och TLS körs som en del av en kanal i det utbytet. Den nyttolast användaren bryr sig om reser i ett annat meddelandeformat, och därför stämmer de två aldrig överens med en vanlig HTTPS-session.

Kuvertet kommer först

Varje tunnelpaket börjar med protokollets egen header: en meddelandetyp, en nyckelidentifierare och, över en byteströmstransport, ett längdprefix som markerar var paketet slutar. En läsare som inte tolkar det kuvertet kan inte veta var nästa fält börjar.

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 skissen är en karta och inte en bytestabell, eftersom de exakta fälten beror på meddelandetypen, även om den första oktetten alltid packar opkoden och nyckelidentifieraren tillsammans. Att gissa meddelandetypen från portnumret är hur avkodare till slut namnger det de ser fel. Ordningen är det som betyder något för diagnostik: transport, sedan protokollkuvertet, sedan en av två typer av arbete. Läs kuvertet innan du bildar dig en uppfattning om det som följer. En avkodare som börjar på fel ställe producerar självsäkert nonsens.

Pålitlighetslagret tillhör protokollet

Kontrollmeddelanden behöver ordnad, bekräftad leverans, och protokollet sörjer själv för det med bekräftelser och omsändningar. En bekräftelse kan anlända som eget meddelande eller resa med ett annat kontrollmeddelande, vilket får spår att se oregelbundna ut för alla som förväntar sig ett rent utbyte.

Fördelen är att TLS-handskakningen får en pålitlig bärare även när den yttre transporten är UDP. Priset är att ett enda datagram kanske bara innehåller en del av det samtalet, så att behandla det som en fristående TLS-post producerar nonsens. Återmontering måste ske på protokollagret. Därför ser ett fångat paket sällan ut som ett fullständigt handskakningssteg.

Att byta den yttre transporten till TCP tar inte bort detta lager. Pålitlig transport betyder färre omsändningar på protokollnivå, inte att ramningen försvinner eller att trafiken blir HTTP.

Datanpaket använder ett annat format

När sessionen finns anländer den nyttiga lasten som datameddelanden som bär inre IP-paket eller Ethernet-ramar. De skyddas med egna nycklar och egen bearbetning, och de är inte TLS-applikationsposter i någon mening som ett TLS-bibliotek skulle acceptera.

Den separationen syns i konfigurationen: kontrollkanalen och datakanalen har separata chifferinställningar, så en logglinje som namnger den ena säger ingenting om den andra. Att läsa ett starkt kontrollchiffer som bevis på ett starkt datachiffer är ett vanligt rapporteringsfel.

Håll också en besläktad missuppfattning utanför förklaringen. TLS är inte en öppen nyckel-kanal vid sidan av en symmetrisk datakanal, eftersom TLS självt skyddar sina poster symmetriskt när nycklarna är etablerade. Den verkliga skillnaden är roll och paketformat, inte vilken typ av kryptografi varje sida använder.

Varför en HTTPS-proxy inte kan hjälpa

En proxy som terminerar TLS förväntar sig en TLS-postström och sedan ett applikationsprotokoll inuti den. Den här protokollens kontrollkanal bärs inuti sin egen ramning med ett pålitlighetslager runt omkring, så en terminerande proxy läser den ramningen som korrupt indata.

En genomskinlig vidarebefordrare som släpper igenom byte eller datagram utan att tolka dem kan fungera, förutsatt att den inte skriver om eller återmonterar strömmen. Frågan man bör ställa om varje mellanled är om den vidarebefordrar den faktiska transporten och ramningen, inte om den stöder TLS någonstans. Fråga det innan du spenderar en kväll på proxyregler. De flesta fel här är arkitektoniska och inte en saknad inställning.

Att läsa ett spår korrekt

Förvänta dig först ett kontrollutbyte, sedan ett mycket större antal datameddelanden, båda delar en transport. Om kontrollfasen slutförs och datutfasen stannar, gäller felet nycklar, routing eller filtrering av datavägen och inte handskakningen. Fånga några datameddelanden och kontrollera om de överhuvudtaget lämnar klienten. Den enda observationen delar sökningen på mitten.

Historiska nyckelmetodbeskrivningar i protokolldokumentationen betyder inte att en given utgåva fortfarande stöder varje gammalt format. Kontrollera versionen du kör innan du bygger en förväntan på ett stycke som beskriver hur sakerna brukade fungera.