TLS reist binnen het besturingskanaal, niet door de hele tunnel

Het woord TLS in een VPN-beschrijving zien en concluderen dat een webproxy het verkeer zal begrijpen, is een veelgebruikte snelweg. Binnen dit protocol wisselen de peers hun eigen pakketten uit, en TLS draait als onderdeel van één kanaal binnen die uitwisseling. De payload waar de gebruiker om geeft, reist in een ander berichtformaat, en daarom komen de twee nooit overeen met een gewone HTTPS-sessie.

De envelop komt eerst

Elk tunnelpakket begint met de eigen header van het protocol: een berichttype, een sleutelidentificatie en, over een bytestroomtransport, een lengtevoorvoegsel dat markeert waar het pakket eindigt. Een lezer die die envelop niet parseert, kan niet weten waar het volgende veld begint.

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)

Die schets is een kaart en geen bytetabel, omdat de exacte velden van het berichttype afhangen, hoewel het eerste octet altijd de opcode en de sleutelidentificatie samen verpakt. Het berichttype uit het poortnummer raden is hoe decoders uiteindelijk verkeerd benoemen wat ze zien. De volgorde is wat voor diagnose telt: transport, dan de protocolenvelop, dan een van twee soorten werk. Lees de envelop voordat je een mening vormt over wat volgt. Een decoder die op de verkeerde plek begint, produceert zelfverzekerde onzin.

De betrouwbaarheidslaag hoort bij het protocol

Controleberichten hebben geordende, bevestigde aflevering nodig, en het protocol zorgt daar zelf voor met bevestigingen en hertransmissies. Een bevestiging kan als eigen bericht aankomen of met een ander controlebericht meereizen, waardoor sporen onregelmatig lijken voor iedereen die één schone uitwisseling verwacht.

Het voordeel is dat de TLS-handshake een betrouwbare drager krijgt, zelfs wanneer het buitenste transport UDP is. De prijs is dat één datagram misschien maar een deel van dat gesprek bevat, zodat het behandelen als een zelfstandig TLS-record onzin oplevert. Herassemblage moet op de protocolaag gebeuren. Daarom ziet een opgevangen pakket er zelden uit als een volledige handshakestap.

Het buitenste transport naar TCP omzetten verwijdert deze laag niet. Betrouwbaar transport betekent minder hertransmissies op protocolniveau, niet dat de framing verdwijnt of dat het verkeer HTTP wordt.

Datapakketten gebruiken een ander formaat

Zodra de sessie bestaat, komt de bruikbare payload binnen als databerichten die interne IP-pakketten of Ethernet-frames dragen. Ze zijn beschermd met hun eigen sleutels en hun eigen verwerking, en het zijn geen TLS-applicatierecords in enige zin die een TLS-bibliotheek zou accepteren.

Die scheiding is zichtbaar in de configuratie: het besturingskanaal en het datakanaal hebben aparte cipherinstellingen, dus een logregel die het ene noemt, zegt niets over het andere. Een sterke controlecipher lezen als bewijs van een sterke datacipher is een veelgemaakte rapportagefout.

Houd ook een verwante misvatting buiten de uitleg. TLS is geen publieke-sleutelkanaal naast een symmetrisch datakanaal, omdat TLS zelf zijn records symmetrisch beschermt zodra de sleutels zijn vastgesteld. Het echte onderscheid is rol en pakketformaat, niet welk soort cryptografie elke kant gebruikt.

Waarom een HTTPS-proxy niet kan helpen

Een proxy die TLS termineert, verwacht een TLS-recordstroom en daarna een applicatieprotocol daarin. Het besturingskanaal van dit protocol wordt binnen zijn eigen framing gedragen met een betrouwbaarheidslaag eromheen, dus een terminerende proxy leest die framing als beschadigde invoer.

Een transparante doorstuurder die bytes of datagrammen doorlaat zonder ze te interpreteren, kan werken, mits hij de stroom niet herschrijft of herassembleert. De vraag die je over elke tussenlaag moet stellen, is of die het werkelijke transport en de framing doorstuurt, niet of die ergens TLS ondersteunt. Vraag dat voordat je een avond aan proxyregels besteedt. De meeste fouten hier zijn architectonisch en niet een ontbrekende instelling.

Een spoor correct lezen

Verwacht eerst een controle-uitwisseling, dan een veel groter aantal databerichten, beide op één transport. Als de controlefase voltooit en de datafase stagneert, betreft de fout sleutels, routering of filtering van het datapad en niet de handshake. Leg een paar databerichten vast en controleer of ze de client überhaupt verlaten. Die ene observatie halveert het zoeken.

Historische sleutelmethodebeschrijvingen in de protocoldocumentatie betekenen niet dat een bepaalde release nog elk oud formaat ondersteunt. Controleer de versie die je draait voordat je een verwachting bouwt op een alinea die beschrijft hoe dingen vroeger werkten.