Limites de HTTPS
Mise en situation
Bien qu'introduisant des mécanismes de chiffrement dans HTTP, HTTPS ne doit pas être vu comme une sécurité absolue sur le web. Il est important de bien comprendre que HTTPS permet de protéger les échanges, mais pas de protéger contre un site malveillant par exemple.
Nous nous attarderons aussi sur la manière dont les certificats sont obtenus, et les changements de politique à ce sujet ces dernières années.
Rappel :
Le champ d'action de HTTPS se limite au chiffrement des communications.
Périmètre de protection de HTTPS
HTTPS garantit :
que le site auquel on accède est bien celui que l'on a demandé (une personne malveillante ne peux pas usurper l'identité du serveur), grâce au certificat
que les données échangées seront chiffrées entre le client et le serveur
À l'inverse HTTPS ne garantit pas :
que le site consulté n'est pas un site malveillant ou de phishing
que le site stocke les données de manières chiffrée/sécurisée
Attention :
Il est souvent mis en avant que "un site avec le cadenas vert (donc un site utilisant HTTPS) est un site sécurisé". Comme vous pouvez le comprendre maintenant, cette formulation est un dangereux raccourci. Si tant est que l'on puisse définir ce qu'est un "site sécurisé", il est certain que HTTPS serait une condition nécessaire mais non suffisante.
Exemple : Phishing : mabanque.fr et mabnaque.fr
Un premier exemple serait un site malveillant, de phishing, qui tente de voler vos identifiants bancaires. Imaginons que votre banque ai pour adresse www.mabanque.fr.
Une personne malveillante pourrait créer une copie conforme (en apparence) de ce site, et l'héberger sur le site www.mabnaque.fr. L'objectif serait de jouer sur une faute de frappe ou d'inattention des personnes souhaitant se rendre sur le site de la banque. Cette personne malveillante n'aurait aucun mal à obtenir (puis à présenter) un certificat HTTPS, en effet il est bel et bien propriétaire de www.mabnaque.fr ! HTTPS (et le certificat) vous garantit simplement que vous aller envoyer vos informations sur le serveur du site malveillant, et pas que c'est bien le site de votre banque.
Exemple : Authentification : résultat de laboratoire
Un second exemple, rapide, serait le site d'un laboratoire qui propose de récupérer vos résultats d'examens médicaux. Sur sa page d’accueil le site affiche, tout fier, être "entièrement sécurisé". Vous constatez que le site utilise bien HTTPS mais ne propose pas d'authentification : tous les résultats d'examens de tous les patients sont accessibles publiquement.
On voit ici aussi que HTTPS ne garantit en rien que la gestion du site soit réellement sécurisée.
Exemple : Stockage : panier d'achat
Si vous communiquez avec un site de vente en ligne via HTTPS :
les données sont bien chiffrées et déchiffrées par le site ;
rien ne garanti que ses serveurs ne seront pas victimes d'intrusion par des tiers ;
ou qu'il ne partage pas ces données volontairement avec des tiers.
Obtention des certificats
Les certificats peuvent être créés par n'importe qui, mais il est nécessaire de passer par une autorité de certification (AC) pour que celui-ci soit reconnu par les navigateurs.
Les AC ont donc une responsabilité importante : elles ne doivent attribuer des certificats qu'aux personnes ayant prouvé leur identité, à savoir qu'elles sont bien propriétaires du nom de domaine qu'elles souhaitent certifier.
Pendant des années, le processus pour obtenir un certificat était donc le suivant : le propriétaire d'un nom de domaine devait attester auprès d'une autorité de certification de son identité civile, et prouver que c'était bien lui qui était en possession du nom de domaine. Le processus était souvent manuel (et parfois même, par un canal hors-ligne), prenait quelques heures ou jours, et coûtait cher. Une autorité de certification classique facturait, en général, plusieurs centaines d'euros par an pour un certificat.
Du fait de la lourdeur et du coût de la procédure, HTTPS a ainsi longtemps été réservé à des professionnels et/ou des acteurs pour qui les enjeux de sécurité étaient important. Ceci a fortement contribué à l'image "cadenas vert/HTTPS = site sécurisé".
Let's Encrypt, la démocratisation de HTTPS
En 2014, l'Electronic Frontier Foundation (EFF) créé, en coopération avec l'université du Michigan et Mozilla, l'organisation à but non lucratif, Internet Security Research Group (ISRG). L'objectif de cette organisation est, entre autre, de lancer le projet Let's Encrypt : une autorité de certification permettant de rendre accessible l'obtention d'un certificat, et donc de généraliser l'adoption de HTTPS.
En 2015 l'autorité de certification Let's Encrypt est lancée et obtient rapidement les certifications nécessaires pour être présente dans tout les navigateurs. Let's Encrypt propose à n'importe quelle personne possédant un nom de domaine d'obtenir, de manière entièrement automatisée, un certificat gratuit pour son domaine. Le changement est majeur : on passe d'une procédure complexe et coûteuse à une procédure automatisée, simple, et gratuite.
L'adoption est massive, et HTTPS se généralise, ne restant plus cantonné à des sites professionnels. En 2020, Let's Encrypt annonce fournir des certificats pour plus de 225 millions de nom de domaines, et les analyses du site Censys estiment que plus de 50% des certificats TLS du monde sont fournit par Let's Encrypt.
Enjeux politique sur les autorités de certification
Les autorités de certification ont, comme nous l'avons vu, un rôle primordial et critique dans la mise en place d'une chaîne de confiance, et donc de HTTPS. La possibilité d'émettre des certificats qui seront acceptés par les navigateurs est un pouvoir très important : si une AC décide de créer un certificat sans vérifier l'identité du demandeur, ou tout simplement pour usurper l'identité d'un site, elle en a la possibilité.
Lorsque les autorités de certification sont des agences gouvernementales ou de grandes entreprises, on peut souligner le fait que ce pouvoir risque d'être utilisé à des fins non-légitimes (politique, espionnage industriel, etc.). De la même manière, lorsqu'une AC ne sécurise pas un minimum ses procédures et ses certificats, un attaquant peut les récupérer et s'en servir pour créer de faux certificats. Et, malheureusement, ce genre d'abus et d'incidents ont déjà été observé.
Exemple :
En 2012, la société de transport publics de Ankara (EGO), en Turquie, a mis en place un certificat lui permettant d'usurper l'identité de tout les sites visités en HTTPS sur son réseau local. Le but étant d'espionner le contenu des sites visités par les employés. Ce faux certificat lui a été fournit par TurkTrust, une autorité de certification gouvernementale turque, qui, à l'époque, était présente dans la liste des certificats de confiance des principaux navigateurs.
Un article résume entièrement l'incident et, même si il semble qu'il n'y ai pas eu de malveillance volontaire de la part de TurkTrust, l'autorité de certification a clairement faillit à son rôle ici.
À retenir
HTTPS n'est pas une solution miracle, c'est un protocole qui permet de chiffrer les communication HTTP, rien de plus.
Les autorités de certification ont un rôle crucial et un pouvoir conséquent dans la mise en place de ce protocole.