Robert Heaton

Le HTTPS est tout simplement votre protocole HTTP standard recouvert d’une généreuse couche de délicieux cryptage SSL/TLS. À moins que quelque chose ne tourne mal (et cela peut arriver), il empêche des personnes comme la tristement célèbre Eve de voir ou de modifier les requêtes qui constituent votre expérience de navigation ; c’est ce qui permet de protéger vos mots de passe, vos communications et les détails de votre carte de crédit sur le fil entre votre ordinateur et les serveurs auxquels vous voulez envoyer ces données. Si le petit cadenas vert et les lettres « https » dans votre barre d’adresse ne signifient pas qu’il n’y a pas encore suffisamment de corde pour que vous et le site web que vous consultez puissiez vous pendre ailleurs, ils vous aident au moins à communiquer en toute sécurité pendant que vous le faites.

Qu’est-ce que le HTTPS et que fait-il ?

Le HTTPS prend le protocole HTTP bien connu et compris, et superpose simplement une couche de cryptage SSL/TLS (ci-après simplement appelé « SSL »). Les serveurs et les clients continuent à se parler exactement de la même manière avec le protocole HTTP, mais par le biais d’une connexion SSL sécurisée qui chiffre et décrypte leurs demandes et leurs réponses. La couche SSL a deux objectifs principaux :

• Vérifier que vous parlez directement au serveur auquel vous pensez parler
• Assurer que seul le serveur peut lire ce que vous lui envoyez et que seul vous pouvez lire ce qu’il vous renvoie

La partie vraiment, vraiment intelligente est que n’importe qui peut intercepter chacun des messages que vous échangez avec un serveur, y compris ceux où vous vous mettez d’accord sur la clé et la stratégie de cryptage à utiliser, et ne peut toujours pas lire les données réelles que vous envoyez.

Comment une connexion SSL est établie

Une connexion SSL entre un client et un serveur est établie par une poignée de main, dont les objectifs sont :

• D’assurer au client qu’il parle au bon serveur (et éventuellement visa versa)
• Pour que les parties se soient mises d’accord sur une « suite de chiffrement », qui comprend l’algorithme de chiffrement qu’elles utiliseront pour échanger des données
• Pour que les parties se soient mises d’accord sur toutes les clés nécessaires pour cet algorithme

Une fois la connexion établie, les deux parties peuvent utiliser l’algorithme et les clés convenus pour s’envoyer des messages en toute sécurité. Nous allons décomposer la poignée de main en 3 phases principales – Hello, échange de certificats et échange de clés.

1. Hello – La poignée de main commence avec le client qui envoie un message ClientHello. Celui-ci contient toutes les informations dont le serveur a besoin pour se connecter au client via SSL, notamment les différentes suites de chiffrement et la version SSL maximale qu’il prend en charge. Le serveur répond avec un ServerHello, qui contient des informations similaires requises par le client, y compris une décision basée sur les préférences du client concernant la suite de chiffrement et la version de SSL qui seront utilisées.

2. Échange de certificats – Maintenant que le contact a été établi, le serveur doit prouver son identité au client. Pour ce faire, il utilise son certificat SSL, qui est un tout petit peu comme son passeport. Un certificat SSL contient plusieurs données, dont le nom du propriétaire, la propriété (par exemple le domaine) à laquelle il est attaché, la clé publique du certificat, la signature numérique et des informations sur les dates de validité du certificat. Le client vérifie soit qu’il fait implicitement confiance au certificat, soit qu’il est vérifié et approuvé par l’une des nombreuses autorités de certification (CA) auxquelles il fait également implicitement confiance. Nous y reviendrons plus tard. Notez que le serveur est également autorisé à exiger un certificat pour prouver l’identité du client, mais cela ne se produit généralement que dans des applications très sensibles.

3. Échange de clés – Le chiffrement des données réelles du message échangé par le client et le serveur se fera à l’aide d’un algorithme symétrique, dont la nature exacte a déjà été convenue lors de la phase Hello. Un algorithme symétrique utilise une seule clé pour le cryptage et le décryptage, contrairement aux algorithmes asymétriques qui nécessitent une paire de clés publique/privée. Les deux parties doivent se mettre d’accord sur cette clé unique, symétrique, un processus qui est accompli de manière sécurisée en utilisant le chiffrement asymétrique et les clés publiques/privées du serveur.

Le client génère une clé aléatoire à utiliser pour l’algorithme principal, symétrique. Il la chiffre à l’aide d’un algorithme également convenu lors de la phase Hello, et de la clé publique du serveur (qui se trouve sur son certificat SSL). Il envoie cette clé chiffrée au serveur, où elle est déchiffrée à l’aide de la clé privée du serveur, et les parties intéressantes de la poignée de main sont terminées. Les parties sont suffisamment satisfaites pour savoir qu’elles parlent à la bonne personne et ont secrètement convenu d’une clé pour chiffrer de manière symétrique les données qu’elles sont sur le point de s’envoyer. Les demandes et les réponses HTTP peuvent maintenant être envoyées en formant un message en clair, puis en le chiffrant et en l’envoyant. L’autre partie est la seule à savoir comment déchiffrer ce message, et les attaquants Man In The Middle sont donc incapables de lire ou de modifier les requêtes qu’ils peuvent intercepter.

Certificats

À son niveau le plus basique, un certificat SSL est simplement un fichier texte, et toute personne disposant d’un éditeur de texte peut en créer un. Vous pouvez en fait créer trivialement un certificat prétendant que vous êtes Google Inc. et que vous contrôlez le domaine gmail.com. Si c’était le cas, le SSL serait une blague ; la vérification de l’identité consisterait essentiellement pour le client à demander au serveur « êtes-vous Google ? », le serveur répondant « euh, oui, tout à fait, voici un morceau de papier avec « je suis Google » écrit dessus » et le client disant « OK, super, voici toutes mes données ». La magie qui empêche cette farce réside dans la signature numérique, qui permet à une partie de vérifier que le morceau de papier d’une autre partie est vraiment légitime.

Il y a 2 raisons raisonnables pour lesquelles vous pourriez faire confiance à un certificat :

• S’il figure sur une liste de certificats auxquels vous faites implicitement confiance
• S’il est capable de prouver qu’il a la confiance du contrôleur de l’un des certificats de la liste ci-dessus

Le premier critère est facile à vérifier. Votre navigateur dispose d’une liste préinstallée de certificats SSL de confiance provenant d’autorités de certification (CA) que vous pouvez consulter, ajouter et supprimer. Ces certificats sont contrôlés par un groupe centralisé d’organisations (en théorie, et généralement en pratique) extrêmement sûres, fiables et dignes de confiance comme Symantec, Comodo et GoDaddy. Si un serveur présente un certificat de cette liste, alors vous savez que vous pouvez lui faire confiance.

Le deuxième critère est beaucoup plus difficile. Il est facile pour un serveur de dire « er ouais, mon nom est er, Microsoft, vous faites confiance à Symantec et er, ils me font totalement confiance, donc tout est cool ». Un client un peu intelligent pourrait alors demander à Symantec : « J’ai ici un Microsoft qui dit que vous lui faites confiance, est-ce vrai ? ». Mais même si Symantec répond « oui, nous les connaissons, Microsoft est légitime », vous ne savez toujours pas si le serveur qui prétend être Microsoft est réellement Microsoft ou quelque chose de bien pire. C’est là que les signatures numériques entrent en jeu.

3.2 Signatures numériques

Comme déjà noté, les certificats SSL ont une paire de clés publique/privée associée. La clé publique est distribuée dans le cadre du certificat, et la clé privée est gardée de manière incroyablement sûre. Cette paire de clés asymétriques est utilisée dans la poignée de main SSL pour échanger une autre clé permettant aux deux parties de crypter et décrypter symétriquement les données. Le client utilise la clé publique du serveur pour chiffrer la clé symétrique et l’envoyer en toute sécurité au serveur, et le serveur utilise sa clé privée pour la déchiffrer. Tout le monde peut chiffrer en utilisant la clé publique, mais seul le serveur peut déchiffrer en utilisant la clé privée.

Le contraire est vrai pour une signature numérique. Un certificat peut être « signé » par une autre autorité, par laquelle l’autorité s’enregistre effectivement en disant « nous avons vérifié que le contrôleur de ce certificat contrôle également la propriété (domaine) indiquée sur le certificat ». Dans ce cas, l’autorité utilise sa clé privée pour chiffrer (au sens large) le contenu du certificat, et ce texte chiffré est joint au certificat en tant que signature numérique. N’importe qui peut décrypter cette signature à l’aide de la clé publique de l’autorité et vérifier que le résultat est la valeur décryptée attendue. Mais seule l’autorité peut chiffrer le contenu en utilisant la clé privée, et donc seule l’autorité peut réellement créer une signature valide en premier lieu.

Donc, si un serveur se présente en prétendant avoir un certificat pour Microsoft.com qui est signé par Symantec (ou une autre AC), votre navigateur n’a pas à le croire sur parole. S’il est légitime, Symantec aura utilisé sa clé privée (ultra-secrète) pour générer la signature numérique du certificat SSL du serveur, et votre navigateur pourra donc utiliser sa clé publique (ultra-publique) pour vérifier la validité de cette signature. Symantec aura pris des mesures pour s’assurer que l’organisation pour laquelle ils signent possède réellement Microsoft.com, et donc étant donné que votre client fait confiance à Symantec, il peut être sûr qu’il parle réellement à Microsoft Inc.

3.3 Auto-signature

Notez que tous les certificats de l’AC racine sont « auto-signés », ce qui signifie que la signature numérique est générée en utilisant la propre clé privée du certificat. Il n’y a rien d’intrinsèquement spécial à propos du certificat d’une AC racine – vous pouvez générer votre propre certificat auto-signé et l’utiliser pour signer d’autres certificats si vous le souhaitez. Mais puisque votre certificat aléatoire n’est pas préchargé en tant qu’AC dans aucun navigateur, aucun d’entre eux ne vous fera confiance pour signer vos propres certificats ou ceux des autres. Vous dites effectivement « er ouais, je suis totalement Microsoft, voici un certificat officiel d’identité émis et signé par moi-même », et tous les navigateurs fonctionnant correctement afficheront un message d’erreur très effrayant en réponse à vos informations d’identification douteuses.

Cela fait peser un énorme fardeau sur tous les éditeurs de navigateurs et de systèmes d’exploitation pour qu’ils ne fassent confiance qu’aux AC racine squeaky clean, car ce sont les organisations auxquelles leurs utilisateurs finissent par faire confiance pour contrôler les sites Web et garder les certificats sûrs. Ce n’est pas une tâche facile.

3.4 À quoi faites-vous confiance ?

Il est intéressant de noter que votre client n’essaie techniquement pas de vérifier s’il doit faire confiance à la partie qui lui a envoyé un certificat, mais s’il doit faire confiance à la clé publique contenue dans le certificat. Les certificats SSL sont complètement ouverts et publics, de sorte que n’importe quel attaquant pourrait s’emparer du certificat de Microsoft, intercepter la demande d’un client à Microsoft.com et lui présenter le certificat légitime. Le client l’accepterait et commencerait volontiers la poignée de main. Cependant, lorsque le client crypte la clé qui sera utilisée pour le cryptage réel des données, il le fera en utilisant la véritable clé publique de Microsoft provenant de ce véritable certificat. Comme l’attaquant ne dispose pas de la clé privée de Microsoft pour la décrypter, il est maintenant coincé. Même si la poignée de main est terminée, il ne sera toujours pas en mesure de décrypter la clé, et ne pourra donc pas décrypter les données que le client lui envoie. L’ordre est maintenu tant que l’attaquant ne contrôle pas la clé privée d’un certificat de confiance. Si le client est d’une manière ou d’une autre amené à faire confiance à un certificat et à une clé publique dont la clé privée est contrôlée par un attaquant, les ennuis commencent.

4.1 Un café peut-il surveiller mon trafic HTTPS sur son réseau ?

Nope. La magie de la cryptographie à clé publique signifie qu’un attaquant peut regarder chaque octet de données échangées entre votre client et le serveur et n’avoir toujours aucune idée de ce que vous vous dites au-delà de la quantité approximative de données que vous échangez. Cependant, votre trafic HTTP normal reste très vulnérable sur un réseau wi-fi non sécurisé, et un site Web peu fiable peut être victime d’un certain nombre de contournements qui vous amènent à envoyer le trafic HTTPS par le biais du HTTP normal ou au mauvais endroit. Par exemple, même si un formulaire de connexion soumet un combo nom d’utilisateur/mot de passe sur HTTPS, si le formulaire lui-même est chargé de manière non sécurisée sur HTTP, alors un attaquant pourrait intercepter le HTML du formulaire sur son chemin vers votre machine et le modifier pour envoyer les détails de connexion à leur propre endpoint.

4.2 Mon entreprise peut-elle surveiller mon trafic HTTPS sur son réseau ?

Si vous utilisez également une machine contrôlée par votre entreprise, alors oui. Rappelez-vous qu’à la racine de chaque chaîne de confiance se trouve une AC de confiance implicite, et qu’une liste de ces autorités est stockée dans votre navigateur. Votre entreprise pourrait utiliser son accès à votre machine pour ajouter son propre certificat auto-signé à cette liste d’autorités de certification. Elle pourrait alors intercepter toutes vos requêtes HTTPS, en présentant des certificats prétendant représenter le site Web approprié, signés par leur fausse AC et bénéficiant donc de la confiance inconditionnelle de votre navigateur. Puisque vous crypteriez toutes vos requêtes HTTPS en utilisant la clé publique de leur certificat douteux, ils pourraient utiliser la clé privée correspondante pour décrypter et inspecter (voire modifier) votre requête, puis l’envoyer à l’endroit prévu. Ils ne le font probablement pas. Mais ils pourraient.

Incidemment, c’est aussi la façon dont vous utilisez un proxy pour inspecter et modifier les requêtes HTTPS autrement inaccessibles faites par une application iPhone.

4.3 Alors, que s’est-il passé avec Lavabit et le FBI ?

Lavabit était le fournisseur de messagerie super-sécurisé d’Edward Snowden pendant la folie des fuites de la NSA en 2013. Comme nous l’avons vu, aucun piratage standard ne pouvait permettre au FBI de voir les données en cours de route entre Lavabit et ses clients. Sans la clé privée du certificat SSL de Lavabit, l’agence était fichue. Cependant, un juge américain bienveillant a dit au fondateur de Lavabit, Ladar Levison, qu’il devait remettre cette clé, donnant ainsi au FBI le droit de fouiller dans le trafic à sa guise. Levison a vaillamment tenté de gagner du temps en remettant la clé de 2 560 caractères dans 11 pages imprimées en caractères 4 points, mais il a été frappé d’une ordonnance l’obligeant à remettre la clé dans un format utile ou à s’exposer à une amende de 5 000 dollars par jour jusqu’à ce qu’il le fasse.

Une fois qu’il s’est exécuté, GoDaddy, l’AC de Lavabit, a révoqué le certificat, l’ayant (à juste titre) jugé compromis. Cela a ajouté le certificat Lavabit à une liste de révocation de certificats (CRL), une liste de certificats discrédités auxquels les clients ne doivent plus faire confiance pour assurer une connexion sécurisée. Les certificats compromis, auto-signés ou indignes de confiance affichent un grand message d’erreur rouge et découragent ou interdisent carrément toute action ultérieure de l’utilisateur. Malheureusement, les navigateurs continueront à faire confiance à un certificat cassé jusqu’à ce qu’ils tirent les dernières mises à jour de la LCR, un processus qui est apparemment imparfait dans la pratique.

Conclusion

HTTPS n’est pas incassable, et le protocole SSL doit évoluer constamment à mesure que de nouvelles attaques contre lui sont découvertes et écrasées. Mais il s’agit tout de même d’un moyen impressionnant et robuste de transmettre des données secrètes sans se soucier de savoir qui voit vos messages. Il existe bien sûr de nombreux détails de mise en œuvre qui ne sont pas mentionnés ici, tels que le format et l’ordre exacts des messages de la poignée de main, les poignées de main abrégées permettant de récupérer les sessions récentes sans avoir à renégocier les clés et les suites de chiffrement, et les nombreuses options de chiffrement disponibles à chaque étape. Ce qu’il faut retenir, c’est que si le protocole HTTPS assure la sécurité des données sur le fil jusqu’à leur destination, il ne vous protège en aucun cas (en tant qu’utilisateur ou développeur) contre les XSS, les fuites de bases de données ou toutes les autres choses qui se produisent la nuit. Soyez heureux qu’il vous protège, mais restez vigilant. Dans les mots immortels de Will Smith, « Marchez dans l’ombre, déplacez-vous en silence, protégez-vous contre la violence extra-terrestre. »

Si vous avez apprécié ceci, vous apprécierez probablement mon billet expliquant les détails de la vulnérabilité FREAK de 2015 dans SSL.