Les autorités de certification ne sont pas responsables du phishing

J’ai vu un post sur LinkedIn à propos d’URLs qui semblent légitimes mais mènent vers des sites de phishing. Quelqu’un a commenté: “Concernant la couleur verte du certificat, cela indique que l’usurpateur a fait la démarche auprès d’une autorité de certification. Cette situation pose des questions sur la responsabilité d’une telle organisation.”

Non. C’est complètement faux, et cette idée reçue doit disparaitre.

Vous cliquez sur https://www.google.com/ et atterrissez sur un site de phishing. La barre d’URL affiche exactement ce que vous attendez. Le cadenas est là. Tout semble parfait.

Sauf que ce n’est pas Google.

Comment fonctionnent les attaques homographes

L’attaque utilise des caractères Unicode visuellement identiques aux lettres latines. ο grec au lieu de o, а cyrillique au lieu de a. Un attaquant enregistre gοοgle.com avec des omicrons grecs. Vos yeux voient “google.com”. Le DNS voit autre chose.

Le cadenas n’est pas le problème

Le site de phishing a HTTPS et un certificat valide. C’est exactement comme ça que ça doit être.

Les certificats Domain Validation (DV) vérifient que vous contrôlez un domaine. Ils chiffrent le trafic. Ils ne vérifient pas l’identité.

Avant Let’s Encrypt, les certificats coutaient cher et prenaient des jours. La plupart des sites tournaient en HTTP. Vos mots de passe et cartes bancaires voyageaient en clair, visibles par les FAI, les WiFi publics, les gouvernements.

Les certificats DV ont réglé ça. Gratuits, automatiques, instantanés. Le web entier s’est retrouvé chiffré! Une des améliorations de sécurité les plus importantes de l’histoire d’internet.

Blâmer les autorités de certification pour avoir émis des certificats à des domaines de phishing, c’est comme blâmer la Poste pour avoir livré des lettres d’arnaqueurs. Ils vérifient que l’adresse existe, pas que l’expéditeur est fiable.

HTTPS signifie connexion chiffrée. Ca n’a jamais signifié destination sûre.

Les certificats OV et EV existent pour ça

Les certificats Organization Validation (OV) et Extended Validation (EV) vérifient l’entité légale derrière un domaine. L’autorité de certification vérifie l’enregistrement de l’entreprise, l’adresse physique, parfois même appelle un représentant.

Les certificats qualifiés européens vont plus loin avec les exigences strictes d’eIDAS.

Le problème: les navigateurs ont arrêté de les différencier dans l’interface. Chrome a retiré la barre verte et le nom d’entreprise des certificats EV dans Chrome 77 (septembre 2019). Firefox a suivi avec la version 70. Le raisonnement de Google: l’indicateur EV “ne protège pas les utilisateurs comme prévu” et la recherche en sécurité a montré qu’il n’empêchait pas le phishing. Les utilisateurs ne peuvent plus faire la différence d’un coup d’oeil.

On a donc une infrastructure de vérification d’identité que les navigateurs n’exposent pas. Super!

Protections des navigateurs

Les navigateurs modernes convertissent les domaines IDN suspects en Punycode dans la barre d’URL. Ce gοοgle.com avec des caractères grecs s’affiche comme xn--ggle-0nd.com.

Ca fonctionne quand le domaine entier utilise des scripts non-latins. Ca échoue quand les attaquants mélangent les scripts intelligemment. Certaines combinaisons passent entre les mailles.

Firefox permet de forcer l’affichage Punycode pour tous les domaines IDN dans about:config avec network.IDN_show_punycode = true. Moche mais sûr.

Défenses pratiques

Utilisez des favoris pour les sites sensibles. Ne cliquez pas sur des liens vers votre banque. Tapez l’URL ou utilisez un favori. Cette seule habitude bloque la plupart du phishing.

Les gestionnaires de mots de passe ne remplissent pas sur les faux domaines. Le gestionnaire voit le vrai domaine, pas la représentation visuelle. S’il ne propose pas de remplir les identifiants, quelque chose ne va pas.

Vérifiez le certificat manuellement. Cliquez sur le cadenas, affichez les détails du certificat, regardez le domaine réel. Fastidieux mais définitif.

Activez le MFA partout. Des identifiants volés sont inutiles sans le second facteur. Protection imparfaite mais friction significative pour les attaquants.

En entreprise: bloquez les domaines IDN. Si vos utilisateurs n’ont pas besoin de domaines internationalisés, bloquez-les au niveau DNS ou proxy. Brutal mais efficace.

Le vrai problème

Les protections techniques existent. Elles sont incomplètes et incohérentes entre navigateurs. Le problème fondamental est que les URLs ont été conçues pour les machines et on demande aux humains de les vérifier.

Le phishing fonctionne parce qu’on fait confiance à ce qu’on voit. Les attaques homographes exploitent cette confiance au niveau du caractère.

Aucune quantité de sensibilisation utilisateur ne corrige un système où l’identifiant critique pour la sécurité est visuellement ambigu. Il faut que les navigateurs exposent mieux les informations d’identité, ou qu’on arrête de prétendre que les URLs sont des indicateurs de sécurité lisibles par les humains.

En attendant: favoris, gestionnaires de mots de passe, MFA. Considérez chaque lien comme hostile jusqu’à preuve du contraire.