Le SSL Server Test (https://www.ssllabs.com/ssltest/) de SSL Labs permet de tester la configuration SSL/TCL d’un serveur web et de proposer des améliorations.
Le nouveau protocole de sécurité enfin approuvé par l'IETF
L’IETF a enfin donné le feu vert au protocole TLS 1.3, améliorant ainsi la sécurité et la rapidité de connexion. Tout en rendant la surveillance plus difficile pour les attaquants.
L’Internet Engineering Task Force (IETF), l’organisme d’élaboration des standards d’Internet, vient d’approuver la norme de sécurité TLS 1.3. Un changement de version, même mineur, est rarement anodin lorsqu’il concerne un protocole de sécurité. Bien que beaucoup l’appellent encore SSL, le protocole du HTTPS est depuis quelques temps déjà TLS. Comme son prédécesseur SSL (Secure Sockets Layer), TLS (Transport Layer Security) est un protocole de sécurisation des échanges sur Internet. Il fonctionne suivant le modèle client-serveur et permet de satisfaire à divers objectifs de sécurité, dont l’authentification du serveur, la confidentialité des données échangées via le cryptage de session, l’intégrité de ces données et, optionnellement, l’authentification du client – même si dans la réalité celle-ci est souvent assurée par le serveur. Des protocoles de sécurisation des échanges sont très largement utilisés sur Internet, leur mise en œuvre étant facilitée par le fait que les protocoles de la couche Application (comme le HTTP) n’ont pas à être profondément modifiés pour utiliser une connexion sécurisée. Néanmoins, ils ne sont implémentés qu’au-dessus des premiers (SSL ou TLS). Le protocole HTTP sécurisé (HTTPS) est par exemple une simple combinaison du HTTP avec une couche de chiffrement comme le SSL ou le TLS, mais le SSL (v2 ou v3) est mis à l’index depuis 2014 à cause de nombreuses failles de sécurité qui ont montré ses faiblesses. Le TLS est un élément fondamental de la sécurisation des connexions internet via HTTPS.
Des changements en profondeur
L’un des principaux changements opérés par TLS 1.3 est l’abandon des algorithmes de chiffrement et de hachage obsolètes, tels que MD5 et SHA-224, pour des alternatives plus sécurisées comme ChaCha20, Poly1305, Ed25519, x448 et x25519. TLS 1.3 supprime ainsi toutes les primitives et les fonctionnalités qui ont contribué à une configuration faible et permis les vulnérabilités courantes telles que Crime, Drown, Lucky 13, Poodle, Sloth, Vaudenay et bien d’autres.
Des fonctionnalités supplémentaires ont, d’un autre côté, été ajoutées pour améliorer la sécurité et la robustesse du protocole. Cette version offre en effet une protection contre les attaques de type « downgrade » par lesquelles un attaquant incite un serveur à utiliser une ancienne version du protocole ayant des vulnérabilités connues. Parmi les principales nouveautés, on peut encore citer des fonctionnalités telles que TLS False Start et Zero Round Trip Time (0-RTT) qui sont censées réduire le temps de connexion à des hôtes avec lesquels le client a déjà communiqué. Elles permettent donc d’avoir une expérience web plus rapide et plus fluide pour les sites web que vous visitez régulièrement.
Les améliorations en termes de sécurité et de rapidité de connexion apportées par TLS 1.3 pourraient se résumer à l’élimination des étapes de prise de contact inutiles et à l’utilisation forcée de nouvelles méthodes de chiffrement plus solides. La version approuvée est en fait la 28e du nom (draft 28) proposée à l’issue de quatre ans de discussion entre les membres de l’IETF. Cette nouvelle version est destinée à devenir le modèle standard en matière de sécurisation des connexions internet, offrant de plus l’avantage de les accélérer du fait de la simplification des négociations.
Le HTTPS est apparu en 1995 dans Netscape Navigator, répondant à un besoin crucial à l’époque au vu notamment de l’essor du commerce en ligne, alors naissant. Le HTTPS utilisait initialement le protocole SSL qui s’intercale entre les protocoles TCP et HTTP afin de les sécuriser. Le SSL a bien évolué depuis, allant jusqu’à changer de nom pour devenir TLS. Le SSL se décline donc en six versions : SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3. Cette nouvelle version arrive dix ans après TLS 1.2 et cinq ans après les révélations d’Edward Snowden.
Le générateur de configuration de Mozilla (https://mozilla. github.io/ server-side-tls/ ssl-configgenerator/) est très pratique pour générer rapidement un fichier de configuration TLS.
Accélération et sécurisation des connexions
TLS 1.3 améliore la vitesse de communication en accélérant la négociation grâce à la réduction des aller-retour entre le client et le serveur. Il renforce la sécurité en désactivant les vieux protocoles et en incluant de nouveaux algorithmes. Les améliorations en termes de sécurité et de rapidité de connexion apportées par TLS 1.3 sont interdépendantes : plus sûr car plus rapide et plus rapide car plus sécurisé.
Pour mieux comprendre le fonctionnement de cette relation bidirectionnelle, il faut d’abord rappeler le fonctionnement d’une connexion TLS 1.2. La connexion initiale en TLS 1.2 passe par un dialogue entre un serveur et un client sur le type de cryptage à utiliser conjointement. Une fois qu’ils se sont mis d’accord, ils commencent à partager les clés de chiffrement. TLS 1.3 élimine cette discussion sur le type de cryptage à utiliser. La connexion initiale est une simple déclaration du client spécifiant ce à quoi il veut accéder. Le serveur fournit une clé de chiffrement et le client une clé de session, et c’est tout ; la communication peut démarrer. Le serveur fournissant automatiquement une clé, les clients ne sont pas en mesure de le tromper en le forçant à utiliser des algorithmes de cryptage obsolètes. Cette pratique est connue sous le nom d’attaque de rétrogradation. TLS 1.3 force donc l’utilisation d’un nouveau cryptage et l’élimination, en sus, des aller-retour de demandes de négociations initiales inutiles (voir figures).
Les navigateurs sont dotés de TLS 1.2 depuis plusieurs années. Cependant, le parc mondial n’est malheureusement pas constitué que de navigateurs récents. Du coup, TLS 1.0 reste très souvent activé sur nombre de serveurs. Malgré leur faiblesse – et donc leur dangerosité –, SSLv2 et v3 ont encore des « adeptes » imprudents et le retrait de TLS 1.0 continue laborieusement après l’essor tardif, mais rapide, de TLS 1.1 et 1.2 alors que TLS 1.3 débarque. Les sites les plus à la pointe acceptent TLS 1.2 et 1.1 mais refusent d’ores et déjà TLS 1.0. La plupart des serveurs acceptent indifféremment TLS 1.0 à 1.3 et seuls les sites (très) à la traîne traitent même des connexions SSLv3, à leurs (grands) risques et périls. Ce découpage en trois groupes de configuration correspond grosso modo à ce que propose Mozilla sur Security/Server Side TLS : moderne, intermédiaire et « vieillot », ou, si vous préférez la classification de l’ANSSI, R3, R3− et R3−−. Il paraît évident que tous les serveurs ne peuvent posséder la même configuration SSL/ TLS. Les sites orientés B2B ont certainement plus de chances d’être consultés via des vieux navigateurs et peuvent tolérer TLS 1.0. En revanche, un site pour lequel la confidentialité et la sécurité sont primordiales ou utilisent des fonctionnalités CSS ou Flexbox récentes refusera, au contraire, TLS 1.0 voire 1.1. Aux navigateurs clients de s’y adapter, sinon tant pis.
La refonte d’un site est la parfaite occasion pour revoir une configuration TLS. Si un site est prévu pour au minimum IE 11, par exemple, et offre un affichage très dégradé avec d’anciennes versions, la configuration de TLS offrira une solution simple et radicale. Il faut juste bien réfléchir aux conséquences : voulez-vous ou non préserver l’accès via de vieux navigateurs et les risques inhérents en matière de sécurité sont-ils tolérables dans votre contexte particulier ?
Pour vérifier si TLS 1.3 est activé dans Firefox et éventuellement l’activer si ce n’est pas le cas, tapez about:config dans la barre d’adresses.
Négociation entre client et serveur
Client et serveur web doivent négocier certains éléments lors de l’établissement d’une liaison sécurisée TLS. Ils doivent s’assurer qu’ils disposent d’algorithmes en commun en vue de signer, d’échanger des clés et de chiffrer. La version du protocole SSL/ TLS à utiliser est le tout premier point sur lequel ils doivent nécessairement s’accorder, car le reste de l’établissement de la liaison sécurisée – le handshake ou poignée de mains – varie selon la version. Ce sont principalement des initialisations, des transmissions d’aléas et des calculs de sommes de contrôle (checksums) qui diffèrent. Avec TLS 1.3, un aller-retour est supprimé lors de l’établissement de la connexion.
Des anticipations ont été réalisées afin de réduire les échanges au minimum. Le client conserve la main après le « Finished ». Il peut donc transmettre une requête HTTP GET dans la foulée, réduisant ainsi l’échange complet à un seul aller-retour (1 RTT). De ceci découle un gain conséquent lorsque la latence est importante, lorsque le client passe par un réseau de communication mobile ou lorsque le client et le serveur sont très éloignés, par exemple. Le mécanisme de reprise de session a lui aussi été complètement remanié et rendu plus rapide. TLS 1.3 a la particularité d’être la première version à largement s’affranchir des recommandations du NIST (National Institute of Standards and Technology) et, de ce fait, d’une éventuelle influence de la NSA qui fait tout pour affaiblir les systèmes cryptographiques – encore merci « Edward ».
Cela s’est traduit par l’adoption d’algorithmes dérivés des travaux d’un certain Daniel J. Bernstein : ChaCha20, EdDSA, x25519 et quelques autres. Bien qu’il soit toujours possible d’utiliser des algorithmes de cryptographie à base de courbes elliptiques de type NIST, ECDSA et AES avec TLS 1.3, il existe désormais une alternative pour chacun d’eux. Un grand coup de balai a été donné dans les vieilles suites cryptographiques. Le mécanisme d’échange de clé le plus simpliste ne peut plus être utilisé – celui chiffrant le secret partagé avec la clé RSA publique du serveur qui n’offrait pas de confidentialité persistante. Le mode CBC et les vieux algorithmes de chiffrement tels que Triple DES disparaissent eux aussi.
C’est cette élimination de tous les éléments les moins robustes qui rend TLS 1.3 sûr et qui, de plus, simplifie grandement sa configuration. Le seul point sensible est la possibilité de faire du 0-RTT. En effet, TLS 1.3 utilise la reprise 0-RTT permettant à deux machines ayant précédemment établi une négociation TLS 1.3 de stocker des informations de connexion sur l’autre participant et d’utiliser d’anciennes clés pour les connexions futures. Un attaquant accédant à des informations de reprise 0-RTT peut usurper une connexion. Néanmoins, cela implique l’accès physique à une machine, ce qui heureusement complique fortement l’exploitation de cette faille. Sélectionnée par défaut, cette fonctionnalité peut être désactivée par l’administrateur.
La fin de l’imprudence ?
Ce n’est pas totalement par hasard – ni par négligence – qu’il existe encore un aussi grand nombre de serveurs configurés avec une rétrocompatibilité bien trop généreuse utilisant des suites cryptographiques plus que dépassées. Plusieurs raisons peuvent en être la cause. D’abord, la configuration SSL/TLS n’a pas toujours été clairement documentée. De fait, une fois la connexion configurée, les administrateurs sont tentés de ne plus y toucher. Et cela peut durer plusieurs années. Cet état de fait était aggravé par l’existence de certificats valables quatre ou même cinq ans. Il existe pourtant des outils forts pratiques tels que SSL Server Test (https://www.ssllabs.com/ssltest/) de SSL Labs, ou le redoutable CryptCheck d’Aeris (https://tls.imirhil.fr) permettant de tester ces configurations et de proposer des améliorations, ou encore le générateur de configuration de Mozilla pour simplifier la configuration d’un site. Ceux-ci sont malheureusement encore trop souvent méconnus. La meilleure règle à suivre est sans doute de n’utiliser que deux ou trois configurations TLS types, la « moderne » et « l’intermédiaire » de Mozilla (R3 et R3- selon l’Anssi), par exemple.
Le lancement de TLS 1.3 se fait dans un contexte très différent de celui de la version précédente TLS 1.2. TLS 1.3 a pour vocation affichée d’accompagner le passage au « tout HTTPS » afin de lutter contre le piratage et la collecte massive d’informations sur le Net. Cette version est plébiscitée par les acteurs de premier plan des réseaux : éditeurs de navigateurs, opérateurs de CDN —Content Delivery Network— et consorts qui ont participé en produisant le code nécessaire pour tester les versions préliminaires. Inutile donc de se faire du souci quant à une adoption rapide de TLS 1.3.
Cela n’empêche qu’il faudra de longues années avant que TLS 1.3 soit la version la plus répandue sur l’ensemble des serveurs web. L’un des freins les plus importants est la diffusion encore trop discrète d’OpenSSL 1.1.1 disponible seulement depuis le début 2017. Il est cependant possible et même conseillé de s’inspirer de TLS 1.3 pour mieux configurer TLS 1.2, c’est-à-dire de désactiver les réponses aux connexions utilisant des suites cryptographiques telles que SSLv3 ou TLS 1.0 et aller en plus vers des types de cryptographie basés sur les courbes elliptiques, certificats y compris. ❍
Activation de TLS 1.3 dans Firefox
Mozilla a commencé à déployer sous forme de mise à jour silencieuse un addon système activant TLS 1.3 dans Firefox depuis le 3 avril 2017. Lorsqu’il est installé, cet addon modifie le paramètre security.tls.version. max en lui affectant la valeur 4. TLS 1.3 est alors activé dans Firefox. Vous pouvez vérifier si vous utilisez TLS 1.3 dans Firefox en accédant à la page about:config et en vérifiant la valeur du paramètre security.tls.version.max. Si elle est définie sur 4, vous utilisez TLS 1.3. Si elle est définie sur 3, vous utilisez toujours TLS 1.2. Si ce n’est pas déjà fait, vous pouvez l’activer manuellement en double-cliquant sur le paramètre security.tls.version. max et en changeant la valeur à 4 dans la boîte de dialogue qui apparaîtra.
L’échec de la finance
TLS 1.3 a suscité certaines inquiétudes dans les secteurs bancaire et financier lors de son examen en 2016. La communication simplifiée en termes de négociations caractérisant TLS 1.3 empêche le décryptage et la surveillance aisée des connexions. Les professionnels de la sécurité de ces secteurs ont demandé d’inclure une porte dérobée dans TLS 1.3 afin de pouvoir continuer à surveiller le trafic TLS, ceci étant possible avec les versions antérieures. Cette réclamation n’a, fort heureusement, pas été retenue dans la version finale. Les sages membres de l’IETF ont simplement déclaré qu’une porte dérobée éliminerait les principaux avantages fournis par TLS 1.3 en matière de sécurité. Dommage pour la finance… et les hackers.