Démystifier les mythes sur HTTPS

La plupart des experts en sécurité recommanderont d'utiliser HTTPS partout. C'est indéniablement un bon conseil à appliquer.

Cependant, il est souvent trompeur pour la plupart des utilisateurs, y compris les connaisseurs en technologie.

Quel problème HTTPS résout-il ?

HTTPS implémente TLS (Transport Layer Security) pour le protocole HTTP. Vous envoyez des requêtes HTTP chaque jour lorsque vous utilisez votre navigateur pour interagir avec des sites Web, et ces interactions sont appelées requêtes et réponses HTTP.

L'idée avec TLS est d'empêcher que les données soient envoyées en texte brut (comme dans HTTP), permettant aux attaquants de les lire s'ils parviennent à intercepter les requêtes. De telles attaques sont assez fréquentes et les cybercriminels aiment sniffer le trafic de leur victime pour collecter des informations confidentielles.

TLS sécurise les communications avec des clés cryptographiques, donc théoriquement, même si quelqu'un parvient à intercepter les requêtes (par exemple, les attaques Man-In-The-Middle), les données seront impossibles à exploiter (chaînes de caractères aléatoires).

Les poignées de main TLS en bref

Dans les coulisses, une poignée de main TLS se produit entre l'appareil de l'utilisateur et le serveur. En gros, c'est ainsi que le client et le serveur conviennent d'utiliser des clés de session spécifiques pour communiquer via un canal sécurisé.

Ces poignées de main impliquent une série de messages et diverses étapes que nous ne couvrirons pas ici, mais disons simplement qu'il existe des moyens d'abuser du mécanisme.

Les chercheurs et les cybercriminels ont trouvé différents angles d'attaque pour usurper les identités et usurper l'identité du client TLS. C'est pourquoi TLS a évolué et les versions récentes ne prennent plus en charge RSA et d'autres chiffrements vulnérables aux attaques.

Certificats TLS en bref

Les services d'hébergement fournissent souvent des certificats SSL gratuitement (par exemple, Let's encrypt) ou moyennant des frais spécifiques.

Le certificat contient la clé publique du site Web et d'autres informations permettant aux appareils qui souhaitent établir une connexion de vérifier l'identité du serveur et la propriété du site Web, ce qui vise à empêcher les fausses copies.

Les certificats sont délivrés par une autorité de certification (CA) indépendante des hébergeurs, mais ces services gèrent généralement l'installation et l'activation pour leurs clients. Une fois qu'il est activé et que le certificat est valide, vous voyez une icône de verrouillage (généralement en vert) et les communications peuvent être chiffrées.

Un site Web peut également avoir un certificat auto-signé qui n'est vérifié par aucune autorité officielle (CA), mais il sera probablement signalé comme "non sécurisé" par le navigateur.

Cela ne signifie pas que les certificats auto-signés sont toujours malveillants, mais les sites Web publics qui visent à atteindre des millions d'utilisateurs doivent au moins être vérifiés par une autorité de certification.

Ne faites pas confiance au cadenas

L'icône de verrouillage peut donner une fausse impression de sécurité, car les cybercriminels peuvent également obtenir des certificats SSL légitimes pour les domaines de typo-squattage. En effet, la plupart des sites Web de phishing et d'escroquerie sont HTTPS.

Il n'est pas compliqué d'enregistrer un nom de domaine similaire à un site Web populaire et d'activer un certificat SSL pour le faire apparaître comme légitime. En 2017, Xudong Zeng a même réussi à usurper apple.com en utilisant Punycode (xn–pple-43d.com). Les clients qui n'affichent pas ces caractères spéciaux par défaut ne permettent pas aux utilisateurs de voir la différence.

Un scénario "plus sophistiqué" peut consister à router manuellement tout le trafic de la victime vers un serveur externe. Les attaquants peuvent également créer de faux réseaux ou routeurs. En d'autres termes, il est possible d'agir comme mandataire sous certaines conditions à l'insu des victimes qui ne changeraient pas leur comportement, car rien ne semblerait anormal.

Le trafic HTTPS peut être déchiffré

Un attaquant qui parvient à sniffer le trafic peut utiliser un logiciel open source tel que Wireshark pour analyser les paquets TLS. Bien sûr, TLS est précisément destiné à ce cas, mais les logiciels qui implémentent TLS (par exemple, les navigateurs) écrivent des clés et des secrets dans des fichiers spécifiques du système, permettant aux adversaires de déchiffrer les paquets interceptés s'ils peuvent lire les fichiers de configuration.

Chaque système d'exploitation a sa propre implémentation, mais lorsque vous possédez la machine de la victime, ce n'est pas la tâche la plus difficile à réaliser, par exemple, en utilisant le SSLKEYLOGFILE.

HTTPS masque-t-il les URL ?

Les connexions TCP et les requêtes DNS non chiffrées se produisent en arrière-plan lorsque vous accédez à un site Web, de sorte que HTTPS ne cache pas d'informations critiques telles que le nom d'hôte. Théoriquement, un adversaire ne peut pas voir les pages spécifiques qu'un utilisateur ciblé visite, mais si le site Web n'utilise pas HSTS (HTTP Strict Transport Security), une politique qui oblige le navigateur à utiliser uniquement les connexions HTTPS, de nombreuses attaques MITM peuvent réussir.

Des adversaires motivés peuvent également exécuter une analyse plus approfondie et déduire certains chemins avec la longueur de certaines réponses HTTP ou via des en-têtes HTTP spécifiques (par exemple, référent). C'est particulièrement vrai avec les sites Web qui ont un contenu mixte et qui utilisent certaines ressources telles que JavaScript ou CSS sur HTTP. En effet, les navigateurs modernes déclencheraient une alerte mais la victime peut l'ignorer.

Pourquoi quelqu'un ignorerait-il l'avertissement de sécurité ?

Je ne sais pas, il y a peut-être un iPhone 14 à gagner ou toute autre récompense qui expliquerait un comportement aussi fou .

Les données ne sont pas cryptées partout

Le but du HTTPS est de sécuriser le transit mais les données peuvent être interceptées à divers endroits, par exemple sur des serveurs web ou des bases de données. Les données finiront par devenir statiques, donc HTTPS ne les rendra pas "inviolables".

Emballer

HTTPS est nécessaire mais pas suffisant. Vous devez renforcer la configuration de votre navigateur ou passer à une alternative plus sécurisée qui n'autorise pas le trafic non HTTPS.

De même, si le site Web n'a pas de politique stricte, n'y allez même pas.

Le "s" dans "HTTPS" signifie "sécurisé" mais c'est trompeur, car même les sites Web de phishing peuvent l'avoir.