TLS circule dans le canal de contrôle, pas dans tout le tunnel

Voir le mot TLS dans une description de VPN et conclure qu’un proxy web comprendra le trafic est un raccourci courant. À l’intérieur de ce protocole, les pairs échangent leurs propres paquets, et TLS s’exécute dans l’un des canaux de cet échange. La charge utile qui intéresse l’utilisateur voyage dans un autre format de message, et c’est pourquoi les deux ne correspondent jamais à une session HTTPS ordinaire.

L’enveloppe vient en premier

Chaque paquet du tunnel commence par l’en-tête propre au protocole : un type de message, un identifiant de clé et, sur un transport en flux d’octets, un préfixe de longueur qui marque la fin du paquet. Un lecteur qui n’analyse pas cette enveloppe ne peut pas savoir où commence le champ suivant.

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)

Ce croquis est une carte et non une table d’octets, car les champs exacts dépendent du type de message, même si le premier octet emballe toujours l’opcode et l’identifiant de clé ensemble. Deviner le type de message à partir du numéro de port, c’est ainsi que les décodeurs finissent par mal nommer ce qu’ils voient. L’ordre est ce qui compte pour le diagnostic : le transport, puis l’enveloppe du protocole, puis l’un des deux types de travail. Lisez l’enveloppe avant de vous faire une opinion sur ce qui suit. Un décodeur qui commence au mauvais endroit produit un non-sens plein d’assurance.

La couche de fiabilité appartient au protocole

Les messages de contrôle ont besoin d’une livraison ordonnée et acquittée, et le protocole l’assure lui-même avec des accusés de réception et des retransmissions. Un accusé de réception peut arriver comme message propre ou voyager avec un autre message de contrôle, ce qui rend les traces irrégulières pour qui attend un échange propre.

L’avantage est que la poignée de main TLS dispose d’un support fiable même lorsque le transport extérieur est UDP. Le coût est qu’un seul datagramme peut ne contenir qu’une partie de cette conversation, si bien le traiter comme un enregistrement TLS autonome produit un non-sens. Le réassemblage doit se faire au niveau du protocole. C’est pourquoi un paquet capturé ressemble rarement à une étape complète de la poignée de main.

Passer le transport extérieur à TCP ne supprime pas cette couche. Un transport fiable signifie moins de retransmissions au niveau du protocole, pas que l’encadrement disparaisse ni que le trafic devienne du HTTP.

Les paquets de données utilisent un autre format

Une fois la session établie, la charge utile arrive sous forme de messages de données transportant des paquets IP internes ou des trames Ethernet. Ils sont protégés par leurs propres clés et leur propre traitement, et ce ne sont pas des enregistrements d’application TLS au sens où une bibliothèque TLS l’accepterait.

Cette séparation est visible dans la configuration : le canal de contrôle et le canal de données ont des réglages de chiffrement distincts, si bien qu’une ligne de journal qui nomme l’un ne dit rien de l’autre. Lire un chiffrement de contrôle fort comme preuve d’un chiffrement de données fort est une erreur de rapport courante.

Gardez aussi une idée fausse connexe hors de l’explication. TLS n’est pas un canal à clé publique à côté d’un canal de données symétrique, car TLS protège lui-même ses enregistrements de façon symétrique une fois les clés établies. La vraie distinction est le rôle et le format des paquets, pas le type de cryptographie utilisé par chaque côté.

Pourquoi un proxy HTTPS ne peut pas aider

Un proxy qui termine TLS attend un flux d’enregistrements TLS puis un protocole d’application à l’intérieur. Le canal de contrôle de ce protocole est transporté dans son propre encadrement, avec une couche de fiabilité autour, si bien qu’un proxy terminant lit cet encadrement comme une entrée corrompue.

Un redirecteur transparent qui laisse passer des octets ou des datagrammes sans les interpréter peut fonctionner, à condition qu’il ne réécrive ni ne réassemble le flux. La question à poser sur tout intermédiaire est de savoir s’il transmet le transport et l’encadrement réels, et non s’il prend en charge TLS quelque part. Posez-la avant de passer une soirée sur des règles de proxy. La plupart des échecs ici sont architecturaux et non un réglage manquant.

Lire une trace correctement

Attendez d’abord un échange de contrôle, puis un nombre bien plus grand de messages de données, les deux partageant un même transport. Si la phase de contrôle se termine et que la phase de données bloque, la panne concerne les clés, le routage ou le filtrage du chemin de données, et non la poignée de main. Capturez quelques messages de données et vérifiez s’ils quittent vraiment le client. Cette seule observation divise la recherche en deux.

Les descriptions historiques des méthodes de clé dans la documentation du protocole n’impliquent pas qu’une version donnée prenne encore en charge tous les anciens formats. Vérifiez la version que vous exécutez avant de fonder une attente sur un paragraphe qui décrit comment les choses fonctionnaient auparavant.