SSTP et SSL 3.0 : l’étiquette face à la version négociée

Deux personnes peuvent examiner le même déploiement SSTP et parvenir à des conclusions opposées. L’une lit la documentation du produit, voit les lettres SSL et suppose que le tunnel fait tourner un protocole retiré depuis des années. L’autre désigne une poignée de main moderne et conclut que la question est close. Toutes deux argumentent à partir d’étiquettes plutôt que de la version négociée, et une seule de ces approches constitue une preuve. La comparaison qui vaut la peine est celle entre ce que le nom promet et ce que le service sélectionne réellement.

Deux réponses à la même question

L’argument de l’étiquette est facile à énoncer : SSTP est décrit comme un protocole de tunnellisation sécurisée, le nom historique dit SSL, donc la connexion doit être en SSL 3.0. Il subsiste parce que le nom vient réellement de cette lignée et parce que la plupart de ceux qui le répètent n’ont jamais regardé une poignée de main. Il subsiste aussi parce que la conclusion sonne prudent, comme si supposer le pire était le choix sûr. Supposer le pire et mesurer la version réelle sont deux activités différentes, et une seule des deux change quelque chose.

L’argument de la preuve pose une question plus étroite. Sur quelle version de protocole ce client et ce serveur se sont-ils mis d’accord, à ce point de terminaison, à ce moment ? La réponse vient du service qui termine TLS, non d’une page marketing ni d’un navigateur qui a atteint un site au nom similaire.

Les deux arguments diffèrent par ce qu’ils peuvent prouver. L’étiquette ne distingue pas un ancien déploiement d’un déploiement corrigé, et la poignée de main ne peut pas vous dire ce que fait un service sans rapport sur le même hôte. Utilisez la seconde et cessez d’utiliser la première.

Lisez la version que le service sélectionne réellement

Commencez par nommer les composants : l’implémentation cliente, l’implémentation serveur, le point de terminaison TLS et tout ce qui, entre les deux, termine puis rétablit TLS. Un répartiteur de charge qui termine TLS et parle HTTP en clair au backend change l’appareil dont vous devez lire la politique.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Notez le point de terminaison et l’heure à côté du résultat, car un changement ultérieur de la politique rend une observation non datée inutile. Répétez la sonde depuis un client situé sur le même chemin réseau que les utilisateurs qui vous intéressent, car un dispositif d’interception peut terminer TLS avec ses propres réglages. Si les deux positions divergent, vous avez trouvé le composant qui compte. Si elles concordent, vous avez une preuve plutôt qu’un slogan.

Séparez le champ d’enregistrement de la négociation

Un numéro de version d’allure ancienne dans un champ n’est pas le même fait qu’une session SSL 3.0. RFC 7568 traite la version de la couche d’enregistrement et le protocole négocié comme des questions distinctes, et c’est exactement de cette distinction que viennent les réponses fausses et assurées. Lisez le protocole négocié, puis la suite de chiffrement, et seulement ensuite tirez une conclusion sur la session.

Le même document est sans ambiguïté sur le protocole lui-même : SSL 3.0 ne doit pas être utilisé, et la négociation ou le repli vers celui-ci est interdit. La raison est la construction CBC défaillante qu’a exploitée l’attaque POODLE, laquelle est une propriété du protocole et non la configuration d’une application.

C’est pourquoi « cette charge de travail est probablement difficile à exploiter » n’est pas un argument pour garder SSL 3.0 activé. L’exigence est de retirer le protocole, non de gagner un débat sur une démonstration.

Retirez SSL 3.0 avec une politique que vous pouvez assumer

Sous Windows, les réglages de protocole Schannel se trouvent sous la clé Protocols et sont lus par rôle client et par rôle serveur, ce qui explique qu’une modification corrigeant un sens laisse l’autre intact. Les réglages actuels et leurs exigences de redémarrage sont documentés par Microsoft, et une bibliothèque TLS tierce sur le même hôte les ignore totalement.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Modifiez la politique par la voie d’administration prise en charge, confirmez que le service propriétaire récupère sa configuration et conservez un retour arrière approuvé. Coller un large script de registre venu d’un autre environnement est la façon dont la correction d’un service devient une panne pour tous les clients TLS de la machine. L’étendue du redémarrage compte ici : un réglage qui semble appliqué peut encore être retenu en mémoire par un service qui ne l’a pas rechargé.

Un pair qui exige encore une version obsolète a besoin d’une mise à jour ou d’un plan de migration. Une exception non documentée qui rétablit discrètement l’ancien protocole n’est pas une stratégie de compatibilité, et elle ne survivra pas au prochain audit.

Validez le changement avec des connexions neuves

Testez avec de nouvelles sessions après le changement de politique, car une connexion établie avant le changement ne prouve rien sur la configuration désormais en vigueur. Confirmez que le protocole autorisé réussit et que le protocole interdit échoue via le processus de validation autorisé, puis laissez l’identité du certificat et les contrôles de confiance exactement tels qu’ils étaient.

Rappelez-vous ce que la poignée de main ne couvre pas. SSTP transporte une authentification PPP après la couche TLS, donc une version de protocole moderne ne dit rien sur l’utilisateur autorisé ni sur les ressources que la session peut atteindre. Ce sont des contrôles distincts avec des preuves distinctes.

Consignez le résultat sous la forme service, backend, politique autorisée et version observée. Ce relevé répond précisément à la question de sécurité, ce que ne font jamais l’argument de l’étiquette ni celui des désagréments.