TLS kjører inne i kontrollkanalen, ikke gjennom hele tunnelen

Å se ordet TLS i en VPN-beskrivelse og konkludere med at en nettproxy vil forstå trafikken, er en vanlig snarvei. Inne i denne protokollen utveksler partene sine egne pakker, og TLS kjører som en del av én kanal i den utvekslingen. Nyttelasten brukeren bryr seg om, reiser i et annet meldingsformat, og derfor passer de to aldri sammen med en vanlig HTTPS-økt.

Konvolutten kommer først

Hver tunnelpakke begynner med protokollens egen header: en meldingstype, en nøkkelidentifikator og, over en bytestrømtransport, et lengdeprefiks som markerer hvor pakken slutter. En leser som ikke parser den konvolutten, kan ikke vite hvor det neste feltet begynner.

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 er et kart og ikke en byttetabell, fordi de nøyaktige feltene avhenger av meldingstypen, selv om den første oktetten alltid pakker opkoden og nøkkelidentifikatoren sammen. Å gjette meldingstypen fra portnummeret er hvordan dekodere ender opp med å navngi det de ser feil. Rekkefølgen er det som betyr noe for diagnostikk: transport, deretter protokollkonvolutten, deretter en av to typer arbeid. Les konvolutten før du danner deg en mening om det som følger. En dekoder som starter på feil sted, produserer selvsikker tull.

Pålitelighetslaget tilhører protokollen

Kontrollmeldinger trenger ordnet, bekreftet levering, og protokollen sørger selv for det med bekreftelser og retransmisjoner. En bekreftelse kan ankomme som sin egen melding eller reise med en annen kontrollmelding, noe som får spor til å se uregelmessige ut for alle som forventer én ren utveksling.

Fordelen er at TLS-håndtrykket får en pålitelig bærer selv når den ytre transporten er UDP. Prisen er at et enkelt datagram kanskje bare inneholder en del av den samtalen, så å behandle det som en frittstående TLS-post produserer tull. Gjenmontering må skje på protokollaget. Derfor ser en fanget pakke sjelden ut som et fullstendig håndtrykkstrinn.

Å bytte den ytre transporten til TCP fjerner ikke dette laget. Pålitelig transport betyr færre retransmisjoner på protokollnivå, ikke at innrammingen forsvinner eller at trafikken blir HTTP.

Datapakker bruker et annet format

Når økten finnes, ankommer den nyttige lasten som datameldinger som bærer indre IP-pakker eller Ethernet-rammer. De er beskyttet med egne nøkler og egen behandling, og de er ikke TLS-applikasjonsposter i noen forstand et TLS-bibliotek ville godta.

Den separasjonen er synlig i konfigurasjonen: kontrollkanalen og datakanalen har separate chifferinnstillinger, så en logglinje som navngir den ene, forteller deg ingenting om den andre. Å lese en sterk kontrollchiffer som bevis på en sterk datachiffer er en vanlig rapporteringsfeil.

Hold også en beslektet misforståelse ute av forklaringen. TLS er ikke en offentlig nøkkel-kanal ved siden av en symmetrisk datakanal, fordi TLS selv beskytter postene sine symmetrisk når nøklene er etablert. Den virkelige forskjellen er rolle og pakkeformat, ikke hvilken type kryptografi hver side bruker.

Hvorfor en HTTPS-proxy ikke kan hjelpe

En proxy som terminerer TLS, forventer en TLS-poststrøm og deretter en applikasjonsprotokoll inne i den. Denne protokollens kontrollkanal bæres inne i sin egen innramming med et pålitelighetslag rundt, så en terminerende proxy leser den innrammingen som korrupt input.

En gjennomsiktig videresender som slipper byte eller datagrammer gjennom uten å tolke dem, kan fungere, forutsatt at den ikke skriver om eller gjenmonterer strømmen. Spørsmålet man bør stille om enhver mellomledd, er om den videresender den faktiske transporten og innrammingen, ikke om den støtter TLS et eller annet sted. Spør om det før du bruker en kveld på proxyregler. De fleste feilene her er arkitektoniske og ikke en manglende innstilling.

Å lese et spor riktig

Forvent først en kontrollutveksling, deretter et mye større antall datameldinger, begge deler én transport. Hvis kontrollfasen fullføres og datafasen stopper, gjelder feilen nøkler, ruting eller filtrering av datastien og ikke håndtrykket. Ta opp noen få datameldinger og sjekk om de i det hele tatt forlater klienten. Den ene observasjonen deler søket i to.

Historiske nøkkelmetodebeskrivelser i protokolldokumentasjonen betyr ikke at en gitt utgivelse fortsatt støtter hvert gammelt format. Sjekk versjonen du kjører før du bygger en forventning på et avsnitt som beskriver hvordan tingene pleide å fungere.