Les couches SSTP expliquées : ce que le paquet interne révèle encore

Deux faits sur SSTP fusionnent dans la plupart des explications, et c’est cette fusion qui rend les captures confuses. Le paquet de l’application survit à l’intérieur du canal protégé, et la connexion TCP qui porte ce canal conserve ses propres adresses tout du long. Ce qui circule sur le fil est un porteur plus sa cargaison, jamais un substitut de l’un ou de l’autre. Parcourez la pile de l’extérieur vers l’intérieur et étiquetez chaque frontière que vous franchissez.

Commencez par le porteur extérieur

La première chose sur le fil est une connexion TCP ordinaire vers le port 443, avec de vraies adresses que les routeurs acheminent. C’est cette connexion qui survit à la traduction d’adresses réseau et qu’un fournisseur d’accès peut compter. Protéger la charge utile ne supprime pas le porteur, et cela ne cache ni le volume ni le rythme.

Tout ce qui suit ce point est porté plutôt qu’acheminé. Le porteur continue de fonctionner même lorsque l’échange interne échoue.

Suivez l’encapsulation vers l’intérieur

À l’intérieur du canal protégé se trouve un échange de contrôle SSTP, puis une session PPP, puis le paquet réseau que le client veut faire livrer. Chaque couche a sa propre négociation, ses propres messages d’erreur et sa propre machine à états. Une panne peut donc ressembler à une panne TLS d’un point de vue et à une panne PPP d’un autre. Lire les couches dans l’ordre indique quelle machine à états s’est arrêtée.

Une seule capture montre rarement toute la pile. Les en-têtes extérieurs ne sont visibles qu’en dehors du point de terminaison, et les internes qu’après la désencapsulation. Cette asymétrie vient de l’endroit où vous vous tenez, pas du protocole.

Le schéma ci-dessous regroupe les couches pour qu’on puisse seulement en parler. Ce n’est pas une disposition d’octets, il ne promet pas un enregistrement par paquet et il ne dit rien du nombre d’opérations cryptographiques qu’une implémentation effectue.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Étiquetez l’observateur avant de lire une capture

Deux captures d’une même session répondent à des questions différentes, et l’interface sur laquelle elles ont été prises décide lesquelles. Sur le chemin d’accès, vous voyez le porteur et les enregistrements TLS, et vous pouvez mesurer tailles et intervalles sans voir d’adresse interne. Au point de terminaison, après la désencapsulation, le paquet interne est du trafic ordinaire sous la politique privée de transfert.

Écrivez l’interface et la direction sur chaque capture avant de l’interpréter. Une trace prise sur un adaptateur physique ne montrera jamais les adresses de l’application interne comme des champs extérieurs ordinaires, et lire cette absence comme une panne de chiffrement est une erreur courante. Une trace prise depuis l’intérieur du tunnel ne montre aucun porteur, elle ne peut donc pas répondre à une question sur la vue du fournisseur. La même discipline vaut pour les journaux du point de terminaison, qui notent l’ordre de la négociation et non les contenus.

Conservez les contrôles que le schéma ne peut pas prouver

L’ordre des couches n’établit pas qu’un déploiement valide le certificat du serveur, négocie une version de TLS prise en charge ou autorise le compte. Chacun de ces points est une décision de configuration qui échoue indépendamment de l’encapsulation.

Vérifiez-les avec un client qui rapporte ce qu’il a négocié au lieu de raisonner à partir d’un dessin. Commencez par la poignée de main TLS, puis l’échange SSTP, puis PPP, et arrêtez-vous à la première étape qui signale une erreur. La première commande affiche la chaîne et la version négociée, et la seconde liste les poignées de main présentes dans une capture.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"