Le chiffrement du tunnel WSS s'arrête au terminateur TLS, pas à l'application

Un tunnel transporté dans un WebSocket sécurisé possède exactement le chiffrement que le client y a mis, pas plus. Le schéma wss:// dit que TLS protège une connexion sur un saut. Il ne dit rien sur le fait que les octets à l'intérieur des messages WebSocket soient protégés séparément, et cette distinction décide qui peut lire votre trafic quand quelque chose au milieu termine TLS.

Deux couches qui ressemblent à une seule

Un WebSocket sécurisé est TLS avec une poignée de main WebSocket exécutée par-dessus, comme le décrit RFC 6455 dans ses sections sur la connexion et la sécurité. La couche TLS authentifie le serveur et chiffre le flux, puis la couche WebSocket encadre ce que l'application décide d'envoyer.

Ce sont deux décisions indépendantes, et un schéma qui dessine un seul cadenas sur tout le chemin cache la seconde. Demandez qui termine la connexion TLS. Demandez ensuite ce que le client place à l'intérieur de chaque message. Tout le reste du déploiement découle de ces deux réponses.

Conception A : le transport est le seul chiffrement

Dans la conception la plus simple, le client prend des paquets IP bruts et les enveloppe dans des messages WebSocket. Rien à l'intérieur n'est chiffré, donc le composant qui détient la session TLS lit des charges utiles en clair. Quand ce composant est votre propre serveur de tunnel, c'est le point de terminaison prévu et la conception est cohérente, car le serveur allait de toute façon voir le trafic.

Cela devient une autre disposition quand un proxy d'inspection se place sur le chemin et termine TLS avec un certificat auquel le client fait confiance. Ce proxy détient désormais le même texte en clair que le serveur aurait détenu, et aucune quantité d'encadrement WebSocket n'y change rien. Le magasin de confiance du client a décidé de ce résultat bien avant l'ouverture du tunnel, car il a choisi d'accepter ce certificat pour ce nom. Le proxy voit aussi l'hôte demandé et la taille de chaque message, ce qui suffit à prendre l'empreinte de beaucoup d'activité sans rien déchiffrer de plus.

Conception B : la charge porte ses propres clés

Dans la seconde conception, le client chiffre et authentifie ses paquets avec un protocole VPN qui possède sa propre identité de pair et son propre échange de clés, puis transporte le résultat dans des messages WebSocket. Terminer le TLS extérieur ici expose du texte chiffré, non du trafic. Le proxy peut voir les tailles et le minutage des messages, et rien d'autre dans la charge. C'est une exposition bien plus faible, et ce sont tout de même des métadonnées qu'il vaut la peine de nommer lors d'une revue plutôt que d'écarter d'un revers de main.

Les points de terminaison propres au protocole intérieur voient encore du texte en clair, ce qui est l'intérêt de la disposition et aussi sa limite. Si un composant du point de terminaison est autorisé à lire des données avant le chiffrement ou après le déchiffrement, la couche supplémentaire ne le contraint pas. Les clés, et le logiciel qui les manipule, restent la frontière qui compte.

Une étiquette VPN, une icône de client familière ou une page marketing ne prouvent pas que cette conception existe. Lire le format de la charge, oui.

Tracez où le texte en clair apparaît réellement

Le schéma d'URL vous donne un seul fait, alors obtenez le reste auprès des interfaces. Exécutez les vérifications ci-dessous dans l'ordre, car chacune rétrécit la suivante :

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Commencez par la connexion extérieure. Une session TCP de longue durée vers le port TLS est l'aspect d'un porteur WebSocket, et une seconde session vers un hôte sans rapport mérite une explication avant d'aller plus loin. Trouvez ensuite l'interface de tunnel sur le client, car un périphérique tun ou tap vous dit que le client traite des paquets IP plutôt que de proxyfier un seul flux applicatif.

La capture sur l'interface de tunnel tranche généralement la question de la charge. Des en-têtes lisibles y signifient que les paquets intérieurs n'ont jamais été chiffrés séparément, tandis que des charges à forte entropie signifient qu'ils l'ont été. Répétez la capture sur l'interface extérieure et comparez les deux : si les deux semblent aléatoires, la couche intérieure fait un travail que l'extérieure ne peut pas défaire.

Examinez la confiance que vous avez réellement accordée

Un certificat racine d'entreprise installé est un fait sur le magasin de confiance du client, pas une affirmation sur ce qu'un proxy journalise ou inspecte. Établissez la politique déployée et le chemin de connexion réel au lieu de déduire un comportement de la présence d'une AC.

Sur du matériel géré, demandez à l'administrateur quel composant termine TLS, si le client valide un certificat épinglé ou un certificat public, et quel est le format de la charge. Ces trois réponses produisent une conclusion que vous pourrez défendre plus tard.

Écrivez le résultat comme une frontière plutôt qu'un verdict. « TLS se termine au proxy d'inspection, et la charge intérieure est chiffrée séparément avec des clés détenues uniquement par les points de terminaison » est une affirmation vérifiable qui survit à un changement de fournisseur. « Les WebSockets sont sûrs » ne l'est pas.