HTTPS et certificats : ce que prouve le cadenas, et ce qu’il ne prouve pas

La première leçon mentionnait que les adresses https:// utilisent le chiffrement. Cette leçon examine de plus près comment ce chiffrement est mis en place, ce que l’icône de cadenas de votre navigateur garantit réellement, et où s’arrête cette garantie.

TLS : le protocole derrière le cadenas

HTTPS est le protocole web ordinaire, HTTP, exécuté à l’intérieur de Transport Layer Security (TLS), un protocole publié pour la première fois en 1999 et aujourd’hui dans sa version 1.3. Le centre d’apprentissage de Cloudflare résume ce qu’accomplit TLS en trois volets : le chiffrement, qui cache les données à quiconque d’autre sur le réseau ; l’authentification, qui vérifie que vous parlez bien au serveur que vous croyez ; et l’intégrité, qui détecte si les données ont été modifiées en transit. Avant tout échange de contenu, votre Mac et le serveur effectuent une « négociation TLS » (handshake) : ils s’accordent sur une version de TLS, sur les méthodes cryptographiques à utiliser, et génèrent les clés qui chiffreront le reste de la session.

Ce qu’un certificat certifie réellement

Pour que cette négociation ait un sens, votre navigateur a besoin d’une preuve que la clé publique du serveur appartient vraiment au site que vous avez tapé. Cette preuve est le certificat TLS. Selon Cloudflare, un certificat regroupe le nom de domaine, la clé publique, une date d’expiration, et la signature numérique de son émetteur : une autorité de certification (CA), une organisation en laquelle votre navigateur et votre système d’exploitation ont déjà confiance. Let’s Encrypt, une autorité de certification gratuite largement utilisée, décrit le processus sans détour : avant de délivrer un certificat, son logiciel vérifie que le demandeur contrôle réellement le domaine, par exemple en lui demandant de publier un fichier précis sur ce site ou un enregistrement DNS précis. Ce n’est qu’après cette vérification qu’elle signe un certificat.

Cela compte car cela définit la limite de ce que prouve un certificat standard. Il prouve que celui qui l’a demandé contrôle le nom de domaine à cet instant. Il ne vérifie pas l’entreprise derrière le site, ne contrôle pas si l’exploitant est honnête, et ne garantit pas que le contenu est sûr. N’importe qui, y compris un escroc, peut enregistrer un domaine et obtenir un certificat valide pour celui-ci en quelques minutes.

Bien lire le cadenas

Le guide Surveillance Self-Defense de l’Electronic Frontier Foundation énonce directement le point sous-jacent : « Le simple fait qu’un service utilise HTTPS ne signifie pas qu’il protège pleinement la vie privée de ses utilisateurs. » HTTPS protège le tuyau ; il ne dit rien de ce que la destination fait de ce qui y arrive. Le même guide note que HTTPS cache aux espions du réseau la page précise d’un site que vous avez visitée, mais le site lui-même reçoit toujours tout ce que vous tapez — recherches, messages, identifiants de connexion — en clair, car il est l’autre bout de la connexion chiffrée, pas un simple observateur de celle-ci.

Certificats auto-signés et expirés

Cloudflare explique aussi ce qui se passe sans autorité de certification de confiance : n’importe qui peut générer son propre certificat « auto-signé », mais les navigateurs n’ont aucune autorité externe pour le vérifier, donc ils marquent ces sites comme non sécurisés ou refusent carrément de les charger. Un certificat expiré produit un avertissement similaire. Aucun des deux avertissements ne signifie nécessairement qu’une attaque est en cours, mais cela signifie que le navigateur ne peut pas actuellement vérifier à qui il parle, ce qui est exactement la vérification que TLS est censé fournir.