Les autorités de certification sont l’une des pierres angulaires les plus importantes de la sécurité sur Internet. Une autorité de certification est quelqu’un qui a la confiance de tous, au début, lorsque personne ne fait confiance à personne d’autre. Une autorité de certification est importante non seulement pour le protocole HTTPS utilisé par les navigateurs et les applications Web, mais aussi pour les courriers électroniques cryptés, les mises à jour logicielles signées, les VPN et bien d’autres choses encore. Nous allons prendre l’exemple prototypique de HTTPS et nous renseigner sur l’AC, dans ce contexte particulier. Bien que vous puissiez extrapoler le résultat à toute autre suite logicielle.

L’Internet est un canal de communication non fiable. Lorsque vous envoyez ou recevez des informations d’un vieux site HTTP http://www.example.com dans votre navigateur, beaucoup de choses peuvent se produire à mi-chemin de vos paquets.

1. Un mauvais acteur peut intercepter la communication, copier les données pour lui-même, avant de les renvoyer à nouveau sur le canal vers vous ou le serveur auquel vous parliez. A l’insu des deux parties, l’information est compromise. Nous devons nous assurer que la communication est privée.
2. Un mauvais acteur peut modifier l’information au fur et à mesure qu’elle est envoyée sur le canal. Bob pourrait avoir envoyé un message « x » mais Alice recevrait « y » de Bob, parce qu’un mauvais acteur a intercepté le message, et l’a modifié. En d’autres termes, l’intégrité du message est compromise.
3. Enfin, et c’est le plus important, nous devons nous assurer que la personne à qui nous parlons est bien celle qu’elle prétend être. Revenons au domaine exemple.com. Comment pouvons-nous nous assurer que le serveur qui nous a répondu est bien le détenteur légitime de www.example.com ? À tout moment dans votre réseau, vous pouvez être mal orienté vers un autre serveur. Un DNS, quelque part, est chargé de convertir un nom de domaine, tel que www.example.com, en une adresse IP sur l’internet public. Mais votre navigateur n’a aucun moyen de vérifier que le DNS a traduit l’adresse IP.

Les deux premiers problèmes peuvent être résolus en cryptant le message avant qu’il ne soit envoyé sur Internet vers le serveur. C’est-à-dire en passant au protocole HTTPS. Cependant, le dernier problème, celui de l’identité, est celui où une autorité de certification entre en jeu.

Initier des sessions HTTP cryptées

Le principal problème de la communication cryptée sur un canal non sécurisé est « Comment la démarrer ? »

La toute première étape impliquerait que les deux parties, votre navigateur et le serveur, échangent les clés de cryptage à échanger sur le canal non sécurisé. Si vous n’êtes pas familier avec le terme clés, pensez-y comme un très long mot de passe généré aléatoirement avec lequel vos données seront cryptées avant d’être envoyées sur le canal non sécurisé.

Bien, si les clés sont envoyées sur un canal non sécurisé, n’importe qui peut écouter dessus et compromettre la sécurité de votre session HTTPS à l’avenir. De plus, comment pouvons-nous être sûrs que la clé envoyée par un serveur prétendant être www.example.com est bien le propriétaire réel de ce nom de domaine ? Nous pouvons avoir une communication cryptée avec une partie malveillante se faisant passer pour un site légitime et ne pas faire la différence.

Donc, le problème de la garantie de l’identité est important si nous voulons assurer un échange de clés sécurisé.

Autorités de certification

Vous avez peut-être entendu parler de LetsEncrypt, DigiCert, Comodo et de quelques autres services qui offrent des certificats TLS pour votre nom de domaine. Vous pouvez choisir celui qui correspond à votre besoin. Maintenant, la personne ou l’organisation qui possède le domaine doit prouver d’une manière ou d’une autre à son autorité de certification qu’elle a bien le contrôle du domaine. Cela peut être fait soit en créant un enregistrement DNS avec une valeur unique dans celui-ci, comme demandé par l’autorité de certification, ou vous pouvez ajouter un fichier à votre serveur web, avec un contenu spécifié par l’autorité de certification, l’AC peut alors lire ce fichier et confirmer que vous êtes un propriétaire valide du domaine.

Puis vous négociez un certificat TLS avec l’AC, et cela se traduit par une clé privée et un certificat TLS public émis pour votre domaine. Les messages chiffrés par votre clé privée peuvent alors être déchiffrés par le cert public et vice versa. C’est ce qu’on appelle le cryptage asymétrique

Les navigateurs clients, comme Firefox et Chrome (parfois même le système d’exploitation) ont la connaissance des autorités de certification. Cette information est intégrée au navigateur/appareil dès le début (c’est-à-dire lorsqu’ils sont installés) afin qu’ils sachent qu’ils peuvent faire confiance à certaines AC. Désormais, lorsqu’ils essaient de se connecter à www.example.com via HTTPS et qu’ils voient un certificat émis par DigiCert, par exemple, le navigateur peut le vérifier en utilisant les clés stockées localement. En fait, il y a quelques autres étapes intermédiaires, mais c’est un bon aperçu simplifié de ce qui se passe.

Maintenant que le certificat fourni par www.example.com peut être fiable, il est utilisé pour négocier une clé de chiffrement symétrique unique qui est utilisée entre le client et le serveur pour le reste de leur session. Dans le cryptage symétrique, une seule clé est utilisée pour le cryptage ainsi que le décryptage et est généralement beaucoup plus rapide que son homologue asymétrique.

Nuances

Si l’idée de TLS et de la sécurité Internet vous séduit, vous pouvez approfondir ce sujet en creusant dans LetsEncrypt et leur CA TLS gratuite. Il y a beaucoup plus de minutie dans tout ce charabia que ce qui est indiqué ci-dessus.