Depuis 2018, Google a imposé l’usage du protocole HTTPS comme protocole de sécurisation des sites Web. Il est probable que votre propre site ait intégré cette protection. Faudrait-il pourtant croire que vous pouvez vous reposer sur vos lauriers ? Pas forcément. En réalité, les connexions HTTPS peuvent être vulnérables si elles ne sont pas bien configurées. Il faut idéalement que la protection TLS qu’elles intègrent soit de niveau élevé. Les explications suivent…
Internet est devenu populaire auprès du grand public à partir de 1995. Assez rapidement, la nécessité d’établir des normes de sécurité est apparue.
En réalité, ce souci avait été ressenti près de 10 ans auparavant lorsqu’Internet touchait avant tout le public des chercheurs et des universitaires. Dès 1986, le gouvernement américain avait créé un organisme de normalisation – devenu indépendant par la suite – l’IETF ou Internet Engineering Task Force.
En 1999, au vu de la montée en puissance du Web et des risques que ce nouveau média pouvait représenter en termes de sécurité, l’IETF a créé un protocole de sécurité baptisé TLS – Transport Layer Security. Son objectif : chiffrer les communications entre deux systèmes connectés à Internet. La version la plus récente (TLS 1.3) date de 2018.
Si vous utilisez un site Web, celui-ci répond probablement à la norme HTTPS, laquelle repose sur la norme de chiffrement SSL. Faut-il croire que votre site Web est à l’abri de toutes menaces ? Pas forcément.
HTTPS intègre le TLS
Initialement, les sites Web étaient à la norme HTTP, laquelle n’était pas du tout sécurisée. Les données étaient transmises telles quelles, d’un serveur jusqu’à l’ordinateur utilisé pour la consultation. Il était donc assez aisé pour un hacker d’intercepter ce contenu, ce qui pouvait inclure les mots de passe, les données entrées dans un formulaire, etc.
Afin de rendre le Web plus fiable, la société Netscape, créatrice du premier navigateur Web à succès a développé un protocole de chiffrement appelé SSL. Les sites Web intégrant cette protection se sont distingués par la mention HTTPS. Vers la fin des années 2010, Google a estimé que ce chiffrement était essentiel et, afin d’inciter les sites Web à évoluer vers HTTPS, a commencé à pénaliser les sites HTTP dans son moteur de recherche.
Quelle est la différence entre le HTTPS et le TLS ? Foncièrement, elle n’existe pas. Le SSL et donc le protocole HTTPS intègre l’algorithme TLS.
De fait, HTTPS désigne une implémentation du chiffrement TLS en surcouche du protocole HTTP. Et donc, un site web qui utilise le HTTPS s’appuie bel et bien sur le chiffrement TLS.
Si vous avez lu ce que nous avons énoncé plus haut, vous avez toutefois eu le sentiment que le HTTPS n’était pas forcément une protection suffisante dans tous les cas de figure. Comment l’expliquer ? Parce que certaines implémentations HTTPS reposent encore sur la norme initiale de 1999, soit TLS 1.0.
Il faut donc s’assurer que le certificat TLS à HTTPS désigne bien le TLS 1.3. Pourquoi en est-il ainsi ?
Qu'est-ce qu'un certificat TLS ?
Un site Web protégé avec HTTPS intègre un certificat TLS. Il contient des données sur le propriétaire du domaine, et aussi la clé publique du serveur (calculée à partir de la clé privée qui, elle, reste confidentielle), soit des informations cruciales pour l’authentification du serveur. Ce type de certificat est délivré par une autorité de certification telle que Let’s Encrypt, DigiCert ou GoDaddy, au propriétaire d’un domaine.
Il vous est aisé de consulter le certificat de n’importe quel site que vous visitez. Juste avant l’adresse d’un site Web, cliquez sur le petit icône présent dans la barre d’adresse. Vous allez alors pouvoir consulter le certificat TLS présent sur le serveur – il est parfois désigné comme « certificat SSL », en raison d’une certaine confusion autour de la dénomination de ces protocoles de chiffrement.
La négociation TLS
Pour mieux comprendre comment fonctionne le certificat, détaillons ce qui se passe lorsqu’une connexion est établie entre un ordinateur et un serveur Web via TLS.
Lorsque vous tapez ou sélectionnez l’adresse d’un site Web dans votre navigateur, une « négociation TLS » (TLS handshake) démarre entre votre ordinateur ou smartphone et le serveur qui héberge ce site Web.
Lors de cette négociation, l’ordinateur et le serveur :
- Indiquent quelle version de TLS (TLS 1.0, 1.2, 1.3.) est utilisée.
- S’accordent sur le chiffrement qui sera mis en œuvre durant cette session de communication entre l’ordinateur de l’usager et le serveur. Rappelons que c’est ce chiffrement qui va masquer les données échangées à un tiers qui tenterait d’intercepter les échanges.
- Authentifient l’identité du serveur, grâce à son certificat TLS. En d’autres termes, le serveur doit prouver son identité à l’ordinateur qui effectue la consultation.
- Génèrent des clés cryptographiques qui vont gérer le chiffrement des données échangées entre les deux parties.
Ce qui a changé avec TLS 1.3
Nous l’avons vu. La première étape de la négociation concerne l’identification de la version de TLS utilisée. Or, les versions TLS 1.0 et 1.1 sont aujourd’hui considérées comme obsolètes et insuffisamment sécurisées.
Plusieurs attaques qui ont eu lieu aux alentours de 2010 ont montré qu’il existait des failles à la protection TLS de base. Parmi les agressions identifiées figuraient
- BEAST (2011).
- CRIME (2012) et BREACH (2013).
- Heartbleed (2014)
Les grandes plateformes de cloud ne gèrent plus TLS 1.0 depuis belle lurette. L’usage qui est recommandé est celui de TLS 1.3. Pourquoi en est-il ainsi ?
TLS 1.3, intègre la notion de Perfect Forward Secrecy (PFS). Chaque session repose sur une clé de protection éphémère. Si jamais la clé privée d’un serveur devait être compromise, il ne serait pas possible à un hacker de reconstituer les données d’une session précédente – le déchiffrement ne fonctionnerait pas.
S’il est donc un message à faire passer c’est qu’il est important de maintenir les bibliothèques TLS à jour, en particulier sur un site de e-commerce. Des outils tels que SSL Labs de Qualys vous permettent d’en avoir le cœur net.
