Phenquestions
Problèmes avec HTTP et texte brut
Internet est un canal de communication non fiable. Lorsque vous envoyez ou recevez des informations d'un ancien site HTTP http://www.Exemple.com dans votre navigateur, beaucoup de choses peuvent arriver à mi-chemin de vos paquets.
- Un mauvais acteur peut intercepter la communication, copier les données pour lui-même, avant de la renvoyer à nouveau sur le canal vers vous ou le serveur avec lequel vous parliez. À l'insu de l'une ou l'autre des parties, les informations sont compromises. Nous devons nous assurer que la communication est privé.
- Un mauvais acteur peut modifier les informations au fur et à mesure qu'elles sont envoyées sur le canal. Bob a peut-être envoyé un message "X" mais Alice recevrait "y" de Bob, car un mauvais acteur a intercepté le message et l'a modifié. En d'autres termes, le intégrité du message est compromis.
- 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. Pour en revenir au Exemple.com domaine. Comment pouvons-nous nous assurer que le serveur qui nous a répondu est bien le titulaire légitime de www.Exemple.com? À tout moment de votre réseau, vous pouvez être mal dirigé vers un autre serveur. Un DNS quelque part est responsable de la conversion d'un nom de domaine, tel que www.Exemple.com, en une adresse IP sur l'Internet public. Mais votre navigateur n'a aucun moyen de vérifier que l'adresse IP traduite DNS.
Les deux premiers problèmes peuvent être résolus en cryptant le message avant qu'il ne soit envoyé sur Internet au serveur. C'est-à-dire en passant en HTTPS. Cependant, le dernier problème, le problème de l'identité, c'est où une autorité de certification entre en jeu.
Lancement de sessions HTTP cryptées
Le principal problème avec la communication cryptée sur un canal non sécurisé est "Comment pouvons-nous le démarrer?"
La toute première étape impliquerait les deux parties, votre navigateur et le serveur, pour échanger les clés de cryptage à échanger sur le canal non sécurisé. Si vous n'êtes pas familier avec le terme clés, considérez-les 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é.
Eh bien, si les clés sont envoyées sur un canal non sécurisé, n'importe qui peut écouter cela et compromettre la sécurité de votre session HTTPS à l'avenir. De plus, comment pouvons-nous croire que la clé envoyée par un serveur prétendant être www.Exemple.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 connaître la différence.
Ainsi, le problème de l'assurance de l'identité est important si l'on souhaite 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 proposant des certificats TLS pour votre nom de domaine. Vous pouvez choisir celui qui correspond à votre besoin. Désormais, la personne/l'organisation qui possède le domaine doit prouver d'une manière ou d'une autre à son autorité de certification qu'elle contrôle effectivement le domaine. Cela peut être fait soit en créant un enregistrement DNS avec une valeur unique, comme demandé par l'autorité de certification, soit en ajoutant un fichier à votre serveur Web, avec un contenu spécifié par l'autorité de certification, l'autorité de certification peut alors lire ce fichier et confirmez que vous êtes le propriétaire valide du domaine.
Ensuite, 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 ensuite être déchiffrés par le certificat 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. Ces informations sont intégrées dans le navigateur/l'appareil dès le début (c'est-à-dire lorsqu'ils sont installés) afin qu'ils sachent qu'ils peuvent faire confiance à certaines autorités de certification. Maintenant, quand ils essaient de se connecter à www.Exemple.com sur HTTPS et voir un certificat délivré par, disons DigiCert, le navigateur peut réellement vérifier qu'en utilisant les clés stockées localement. En fait, il y a quelques étapes intermédiaires supplémentaires, mais c'est un bon aperçu simplifié de ce qui se passe.
Maintenant que le certificat fourni par www.Exemple.com est digne de confiance, 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 clé est utilisée pour crypter et décrypter 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 intéresse, vous pouvez approfondir ce sujet en creusant dans LetsEncrypt et leur TLS CA gratuit. Il y a beaucoup plus de minutie à tout ce rigmarole que ce qui est indiqué ci-dessus.
D'autres ressources que je peux recommander pour en savoir plus sur TLS sont le blog de Troy Hunt et le travail effectué par EFF comme HTTPS Everywhere et Certbot. Toutes les ressources sont d'accès gratuit et très peu coûteuses à mettre en œuvre (il vous suffit de payer pour l'enregistrement du nom de domaine et les frais horaires de VPS) et d'acquérir une expérience pratique.
