Pourquoi on est « sécurisé » en HTTPS ?

Cet article a été publié il y a 5 ans 8 mois 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Est-ce que vous avez déjà entendu parler d’HTTPS ? Est-ce que vous savez vraiment ce que c’est, à quoi ça sert, comment ça marche, et donc, de quoi on parle quand on dit que c’est sécurisé ? Vous l’aurez compris, nous voilà parti pour un nouvel article de vulgarisation dans le monde merveilleux du Web. Car HTTPS, c’est un peu la colonne vertébrale du Web moderne. Autant connaître un peu ce qui fait tenir tout ce petit monde debout. Surtout que ça vous arrive tous les jours un peu plus sous le nez, donc difficile de l’ignorer plus longtemps.

Au commencement était HTTP

HTTP, c’est la langue du web. C’est ce qui fait que votre navigateur (Internet Explorer, Firefox, Chrome, Edge, vous l’avez ?), sait comment demander l’affichage d’un site web. Comme beaucoup de langages de communication créé avant le début des années 2000 (le bon terme c’est protocole), HTTP est un protocole texte « en clair », à savoir que toutes les communications ne sont pas protégées. Toutes les informations circulent en texte brut, ce qui veut dire que toute personne qui se trouve entre votre machine et celle du site web en face peut lire tout ce que vous transmettez. Pire, on peut les modifier à la volée, ce qui permet toutes sortes de joyeusetés, comme injecter des malware à la volée, modifier des images…

Très tôt, quand on a compris qu’on pourrait faire autre chose que d’échanger des documents publics sur le web (au hasard, monter une boutique pour que des gens puissent y acheter des choses), il a fallu trouver le moyen d’éviter que ces éléments de base en clair puissent être interceptés et lus. Il serait fâcheux que votre numéro de carte bleue soit lisible par tout un chacun sans effort. Évidemment, on a vite trouvé une solution.

Au 7° jour, dieu créa HTTPS

Pas besoin de sortir de Saint-Cyr pour comprendre que le S rajouté au bout veut dire Secured, soit Sécurisé en français. Il s’agit basiquement d’ajouter une couche de chiffrement, aux fondements mathématiques suffisamment forts et souples pour permettre à une variété importante d’appareils de nature et de puissance différente de pouvoir communiquer ensemble à un niveau acceptable de sécurité. Au départ, on a utilisé SSL, pour Secure Socket Layer, qui finit par faire montre de faiblesses mathématiques (et surtout était d’abord développé par une société privée), mais entre temps il a été supplanté par TLS, Transport Layer Security, au développement ouvert et standardisé.

Celui-ci a connu quelques révisions, et si la version 1.2 est actuellement encore considérée comme sûre, son futur doit être assuré par la version 1.3 qui vient tout juste d’être publiée après quatre ans de discussions musclées entre partisans de la surveillance de masse (aussi appelée surveillance étatique), et ceux qui pensent que la sécurité est une priorité pour nos communications. Pour ceux qui voudraient se faire mal avec les détails techniques, l’excellent résumé de la RFC de Stéphane Bortzmeyer est là pour vous ravir. Et si vous voulez un résumé historique de SSL et de TLS, il y a également cet article d’OpenWeb qui est fort sympathique. Ce qu’on doit retenir c’est qu’actuellement, globalement les communications sont plutôt sures. Quand elles sont faites en HTTPS évidemment, ce qui n’est pas si trivial pour pas mal de monde : récemment j’ai passé une heure au téléphone pour expliquer et conseiller un client sur les challenges à passer ses sites en HTTPS…

Une sécurité aux buts multiples

Le but premier d’HTTPS est de rendre la communication inintelligible pour le commun des mortels qui tenteraient d’écouter aux portes de l’échange entre votre appareil et le serveur en face. L’idée est que si quelqu’un tente d’intercepter la communication, il ne verra que du bruit ou presque (il y a moyen de récupérer quelques informations comme le domaine mais ça se limite à ça).

Un autre but du HTTPS est de garantir à un visiteur l’identité du site visité. Ce qui n’est pas si idiot si on veut que la communication soit confidentielle. En effet, le protocole repose sur l’utilisation de certificat dit X509 (on parle de certificat SSL par abus de langage), dont la génération repose sur des autorités de certification qui sont des intermédiaires de confiance. Lorsque le site présente son certificat, il est marqué d’une signature cryptographique propre à l’autorité en question, et le navigateur vérifie si la signature est correcte. En cas d’erreur, pas de communication.

On peut aussi optionnellement s’assurer de l’identité du client avec le même type de certificat, ça se fait sur certaines applications notamment en entreprise. Mais ce n’est pas réservé à l’entreprise, Djerfy a fait un article il y a quelques années pour montrer comment verrouiller l’administration d’un blog WordPress avec cette méthode.

Et enfin, et c’est lié à la garantie de l’identité du site, le protocole assure que les contenus émis par le serveur ou le client ne sont pas modifiés en route. Si c’est le cas, la communication est coupée car elle n’est plus mathématiquement propre. Vous pensez que c’est inutile ? Un opérateur au Canada commence à injecter des publicités par dessus le contenu des sites que vous visitez s’ils ne sont pas en HTTPS.

Petite introduction au fonctionnement du protocole

Allez, on va pas échapper à une petite section technique, si ça vous embête passez au chapitre suivant, personne ne vous en voudra et ce n’est pas vital pour terminer l’article. Donc, vous cherchez à atteindre https://www.facebook.com, que ce soit via votre navigateur ou l’application mobile. Votre appareil va alors initier une demande de connexion chiffrée en indiquant si possible le domaine (www.facebook.com) sur lequel il veut se connecter. Il annonce en même temps la version maximale du protocole de chiffrement qu’il supporte, ainsi que les algorithmes de chiffrement qu’il aimerait utiliser.

En face, le serveur répond en affichant son certificat, ainsi que sa propre version maximale et les algorithmes qu’il supporte. Votre appareil, avant de continuer, vérifie que ce certificat a été émis par une autorité de certification reconnue. Si ce n’est pas le cas, il vous crachera une erreur et n’ira pas plus loin, car l’un des deux prérequis à l’utilisation, la garantie de l’identité, n’est pas vérifié. S’ensuit alors une série d’échanges pour finaliser les différents paramètres cryptographiques (avec notamment la signature du certificat qui repose sur une clé privée et une clé publique), qui permettront de chiffrer la communication et surtout de la rendre unique. A la fin c’est le serveur qui décide, vu que c’est lui qui dispose du certificat.

Ces deux premières étapes sont appelées « handshake », littéralement poignée de main, qui est souvent un signe qu’on s’est mis d’accord; J’ai pu lire chez Stéphane Bortzmeyer « protocole de salutation » qui est une jolie traduction non littérale 🙂 Parmi ces échanges sont définies mathématiquement des clés de chiffrement qui seront uniques. De sorte que même si avec le temps on arrive à déchiffrer une communication enregistrée au préalable, les clés découvertes ne pourront pas permettre de déchiffrer de futures  communications entre les mêmes participants. Voilà ce que peut indiquer votre navigateur quand la connexion est établie :

On voit que le site a été vérifié, et que le certificat utilisé a une date d’expiration. En bas, dans les détails techniques, on voit la version de TLS utilisée (1.3, oui oui, fraîchement finalisé qu’il est déjà déployé par certains gros acteurs), ainsi que de la suite de chiffrement, dans laquelle ont voir de l’AES sur 128 bit en mode GCM, ce qui est loin d’être dégueulasse même si pas le top du top qui existe, avec une méthode de hashage SHA256, qui est toujours considéré comme sûr à l’heure actuelle. Donc techniquement parlant, on est sur du très bon, pas le plus furieux mais je pense que c’est sélectionné pour des raisons de performance : on pourrait par exemple passer sur AES256 mais le coût en calcul est beaucoup plus élevé puisqu’on double la taille de la clé. Idem pour SHA256, il est possible d’utiliser encore plus élevé, avec les mêmes conséquences, ça serait lus lourd à calculer et du coup tout paraîtrait plus lent.

Mais ça ne sont que les paramètres sur lesquels mon Firefox et Facebook se sont mis d’accord. Si on regarde tout ce que Facebook supporte, on voit qu’il est capable de proposer bien pire. Pour une raison simple : même si vous avez encore un ordinateur sous Windows XP, ou un smartphone avec Android 2.X, alors vous pourrez tout de même consulter Facebook. Mais dans ce cas vous êtes un bon candidat à la crucifixion, parce que c’est juste irresponsable d’utiliser encore ce genre de configuration de nos jours.

De quoi HTTPS ne protège pas ?

Le rôle d’HTTPS est donc de garantir l’intégrité du transport du contenu d’un site du serveur vers le client ainsi que de l’identité dudit serveur et/ou dudit client. Mais ce n’est pas son rôle de s’occuper du contenu en question, ni du reste de l’environnement du client et du serveur. HTTP, c’est HyperText Transfer Protocol, pas antivirus. Si votre machine est déjà infectée par divers malwares conçus pour voler des informations, le fait que le transport de celles-ci soit protégé n’empêchera pas nécessairement le malware de capturer la saisie avant l’envoi et de retransmettre ces informations à une personne malveillante.

Même si vous êtes clean, on a déjà un historique plutôt fourni de sites qui se sont vus infectés pour servir du code malveillant aux visiteurs. Et là non plus HTTPS n’est d’aucune aide, puisque le contenu est compromis en amont. Il est donc tout à fait possible de se faire également voler des infos et infecter dans ce contexte.

Un dernier élément est le phishing, traduit hameçonnage en français (ça va c’est pas affreux comme traduction). Si vous recevez un faux mail se faisant passer pour votre opérateur de téléphonie ou votre banque, vous invitant à cliquer sur un lien et entrer vos coordonnées, notamment bancaires, si le site ressemble comme deux gouttes d’eau à l’original, qu’il est sur un domaine complètement différent mais que le certificat est valide, l’utilisateur la plupart du temps verra « cadenas vert » et ne se posera pas plus de questions sur l’adresse réelle qui se trouve à côté. Et pourtant on est clairement dans une situation où les informations saisies seront récupérées à des fins malveillantes. HTTPS n’est donc d’aucune aide dans le mauvais comportement des utilisateurs.

Alors, sécurisé ou pas ? Les navigateurs mentent-ils ?

Évidemment que l’on est sécurisé en HTTPS, mais il faut bien comprendre les limites de cette sécurité. Comme souvent en informatique, le meilleur des outils ne sera aussi bon que par l’usage qui en est fait par les gens. D’un certain point de vue les actions de Google, décidément trop influent sur le monde numérique, sont malgré tout à saluer, à savoir favoriser le HTTPS dans les résultats de son moteur de recherche, ainsi qu’alerter méchamment sur son navigateur qu’un site n’est pas sécurisé quand il est chargé « en clair ». Mais tout n’est pas parfait et il est possible de galvauder un peu cette sécurité, de sorte qu’il faut continuer à éduquer les gens sur les dangers du phishing, qui reste une activité très lucrative pour les criminels; quand bien même les ransongiciels et les mineurs de cryptomonnaies ont le vent en poupe. Avec un trafic mail estimé à 95% de spam, pas étonnant que ça reste un morceau de choix.

Ironie du sort, Android à salement tendance à utiliser leurs serveurs DNS maison plutôt que celui fourni par votre connexion (4G, Wifi), de sorte que toute personne qui utilise son smartphone partage en permanence à minima les domaines qu’il utilise avec la maison mère. Et quand les utilisateurs ajoutent un compte Google dessus, là c’est toute l’activité en ligne qui se retrouve enregistrée là-bas. Après on va hurler que Firefox est hypocrite quant à la vie privée de ses utilisateurs (c’est en partie vrai), mais là, hein, ça ne semble déranger personne…