TLS viatja dins del canal de control, no per tot el túnel

Veure la paraula TLS en una descripció de VPN i concloure que un proxy web entendrà el trànsit és un drecera habitual. Dins d’aquest protocol els parells intercanvien els seus propis paquets, i TLS funciona com a part d’un canal dins d’aquest intercanvi. La càrrega útil que interessa l’usuari viatja en un format de missatge diferent, i per això les dues coses mai no coincideixen amb una sessió HTTPS ordinària.

El sobre arriba primer

Cada paquet del túnel comença amb la capçalera pròpia del protocol: un tipus de missatge, un identificador de clau i, sobre un transport de flux de bytes, un prefix de longitud que marca on acaba el paquet. Un lector que no analitza aquest sobre no pot saber on comença el camp següent.

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)

Aquest esquema és un mapa i no una taula de bytes, perquè els camps exactes depenen del tipus de missatge, tot i que el primer octet sempre empaqueta l’opcode i l’identificador de clau junts. Endevinar el tipus de missatge a partir del número de port és com els decodificadors acaben etiquetant malament el que veuen. L’ordre és el que importa per al diagnòstic: transport, després el sobre del protocol, després un dels dos tipus de feina. Llegeix el sobre abans de formar-te cap opinió sobre el que ve després. Un decodificador que comença al lloc equivocat produeix disbarats amb molta confiança.

La capa de fiabilitat pertany al protocol

Els missatges de control necessiten una entrega ordenada i reconeguda, i el protocol ho proporciona ell mateix amb reconeixements i retransmissions. Un reconeixement pot arribar com a missatge propi o viatjar amb un altre missatge de control, cosa que fa que les traces semblin irregulars a qui espera un intercanvi net.

L’avantatge és que l’handshake TLS rep un portador fiable fins i tot quan el transport exterior és UDP. El cost és que un sol datagrama pot contenir només una part d’aquesta conversa, així que tractar-lo com un registre TLS autònom produeix disbarats. El reassemblatge ha de passar a la capa del protocol. Per això un paquet capturat poques vegades sembla un pas complet de l’handshake.

Canviar el transport exterior a TCP no elimina aquesta capa. Un transport fiable significa menys retransmissions a nivell de protocol, no que l’enquadrament desaparegui ni que el trànsit es torni HTTP.

Els paquets de dades fan servir un format diferent

Un cop existeix la sessió, la càrrega útil arriba com a missatges de dades que porten paquets IP interns o trames Ethernet. Estan protegits amb les seves pròpies claus i el seu propi processament, i no són registres d’aplicació TLS en cap sentit que una biblioteca TLS acceptaria.

Aquesta separació és visible a la configuració: el canal de control i el canal de dades tenen paràmetres de xifratge separats, així que una línia de registre que nomena un no diu res de l’altre. Llegir un xifratge de control fort com a prova d’un xifratge de dades fort és un error habitual als informes.

Mantingues també una idea equivocada relacionada fora de l’explicació. TLS no és un canal de clau pública assegut al costat d’un canal de dades simètric, perquè TLS mateix protegeix els seus registres de manera simètrica un cop establertes les claus. La distinció real és el paper i el format del paquet, no quin tipus de criptografia fa servir cada costat.

Per què un proxy HTTPS no pot ajudar

Un proxy que termina TLS espera un flux de registres TLS i després un protocol d’aplicació a dins. El canal de control d’aquest protocol es transporta dins del seu propi enquadrament amb una capa de fiabilitat al voltant, així que un proxy que termina llegeix aquest enquadrament com a entrada corrupta.

Un reenviador transparent que passa bytes o datagrames sense interpretar-los pot funcionar, sempre que no reescrigui ni reassembli el flux. La pregunta que cal fer sobre qualsevol intermediari és si reenvia el transport i l’enquadrament reals, no si admet TLS en algun lloc. Pregunta-ho abans de passar una nit amb regles de proxy. La majoria de fallades aquí són arquitectòniques i no pas un paràmetre que falta.

Llegir una traça correctament

Espera primer un intercanvi de control, després un nombre molt més gran de missatges de dades, tots dos compartint un transport. Si la fase de control es completa i la fase de dades s’atura, la fallada afecta claus, encaminament o filtratge del camí de dades i no l’handshake. Captura uns quants missatges de dades i comprova si surten del client. Aquesta sola observació parteix la recerca per la meitat.

Les descripcions històriques dels mètodes de clau a la documentació del protocol no impliquen que una versió determinada encara admeti tots els formats antics. Comprova la versió que executes abans de construir una expectativa sobre un paràgraf que descriu com funcionaven les coses abans.