Le certificat derriere votre cadenas avait deja annonce la page que vous n'aviez pas encore lancee

Un concurrent lance exactement la meme ville une semaine apres que l'equipe a termine ses tests en silence, avant meme qu'une seule publicite soit achetee ou qu'un seul lien soit publie. Un operateur apprend, par un inconnu sur un forum, que quelqu'un a fouine sur une page de connexion dont personne en dehors de l'entreprise n'aurait du connaitre l'existence. Aucun des deux cas ne ressemble a une fuite venant d'un employe, a un compte email pirate ou a un coup de chance. Les deux s'expliquent en general par quelque chose de bien plus banal: un certificat de securite, delivre automatiquement, qui fait exactement ce pour quoi il a ete concu.

Ce mecanisme s'appelle Certificate Transparency et n'a rien a voir avec un piratage. C'est un registre public et permanent des certificats HTTPS qui existe depuis 2018, consultable gratuitement, et qui contient deja l'historique complet de chaque nom d'hote que ce site, ou n'importe quel site, a place derriere un certificat fonctionnant sans avertissement du navigateur. Presque aucun operateur n'a jamais verifie sa propre entree dans ce registre. C'est le veritable vide a combler ici, non pas une faille au sens habituel, mais un registre qui a toujours ete public et n'a jamais ete traite comme tel.

Ce que devient en silence un certificat, au moment ou il est delivre

Depuis 2018, un certificat de confiance publique, celui qui fait apparaitre sur Chrome et Safari un simple cadenas au lieu d'un avertissement, doit etre enregistre dans l'un des journaux de Certificate Transparency, sinon ces navigateurs ne lui font pas confiance. Apple a ajoute la meme exigence pour Safari plus tard cette meme annee. Cela ne visait pas particulierement les sites pour adultes ou les annuaires de petites annonces: le but etait d'empecher quelqu'un d'emettre en secret un faux certificat pour le domaine d'un autre et d'en intercepter le trafic. L'effet secondaire est que le registre enregistre aussi chaque certificat reel qu'un site obtient pour lui-meme, et ce registre n'a jamais ete concu pour rester prive.

Le registre liste, par nom, chaque hote qu'un certificat couvre reellement. Un certificat delivre pour admin.exemple.com affiche exactement ce nom, en clair, pour toujours. Peu importe que la page derriere ce nom ait un jour ete liee depuis le menu du site, mentionnee dans un plan du site ou indexee par un moteur de recherche. L'autorite de certification l'a enregistre au moment meme ou elle l'a delivre, qu'il s'agisse de Let's Encrypt, de Cloudflare ou du gestionnaire automatique de certificats integre dans la plupart des panneaux d'hebergement, car tous repondent aux memes regles de navigateur.

Le verifier ne coute rien et prend moins d'une minute. Un outil gratuit appele crt.sh permet a n'importe qui de saisir un domaine et de voir tous les certificats jamais enregistres pour ce nom, sans compte, sans inscription. Saisir le domaine d'un concurrent fonctionne exactement comme saisir le sien, et c'est precisement ce qui transforme un registre technique de routine en risque commercial. Tout operateur lisant ces lignes peut ouvrir cette page des maintenant et voir, pour la premiere fois, ce que son propre domaine a deja raconte au monde entier.

Il existe une vraie exception, et elle compte pour tout ce qui suit: un certificat wildcard, celui qui couvre un modele entier comme *.exemple.com plutot qu'un nom exact, n'enregistre que ce modele dans le journal. Les noms d'hote precis qui l'utilisent vraiment, nouvelleville.exemple.com ou staging.exemple.com, n'apparaissent pas par leur nom dans le registre. Un certificat dedie a un seul sous-domaine precis, lui, apparait toujours par son nom. Cette difference est le levier concret dont dispose reellement un operateur, et on y revient plus loin.

Ce que cela livre vraiment a un inconnu, de trois facons concretes

La premiere est le timing d'une expansion. Une nouvelle page de ville ou de pays est presque toujours construite et testee sur son propre sous-domaine des jours ou des semaines avant que le marketing soit pret a l'annoncer, et la tester en HTTPS signifie que son certificat est delivre pendant cette periode silencieuse, pas le jour du lancement. Il existe des outils de surveillance gratuits, bases sur le meme registre public, qui previennent celui qui les utilise en quelques minutes a quelques heures a chaque fois qu'un nouveau certificat apparait pour un domaine qu'ils suivent. Un concurrent qui connait deja le domaine principal, public par definition, n'a pas besoin de deviner le nom de la nouvelle ville: il lui suffit de surveiller, et le registre le lui livre avant meme que l'annonce ne sorte.

La deuxieme est la carte des outils internes. Un annuaire de cette taille gere en general une page de connexion pour le personnel, une file d'attente pour les personnes qui verifient les annonces, peut-etre un panneau separe pour un prestataire externe de paiement. Si chacun d'eux a obtenu son propre certificat avec son propre nom descriptif, admin, moderation, facturation, le registre se lit desormais comme un plan du batiment. Ce plan est exactement le point de depart derriere le type d'intrusion deja traite ici, ou la facon habituelle d'entrer n'est pas un exploit spectaculaire mais un mot de passe reutilise, essaye contre la page de connexion la plus facile a trouver. Un sous-domaine au nom descriptif ne cause pas a lui seul cette intrusion, mais il supprime la premiere etape, trouver la page de connexion, qui aurait autrement ralenti l'attaquant.

La troisieme est une histoire que personne ne peut effacer. Le registre n'oublie rien. Un sous-domaine de test vieux de trois ans, une page ephemere creee pour un partenaire qui n'existe plus, une copie de staging qu'un developpeur comptait supprimer et a oubliee: tout cela reste dans le registre pour toujours, meme apres l'expiration du certificat, meme apres la suppression de l'enregistrement DNS qui y pointait. Chercher aujourd'hui un domaine sur crt.sh peut faire ressortir des noms dont personne dans l'equipe actuelle ne se souvient. La partie dangereuse n'est pas l'entree elle-meme, c'est la possibilite que le serveur qui repondait a cette adresse soit toujours la, jamais mis a jour, parce que tout le monde a suppose que retirer le lien revenait a l'eteindre.

Rien de tout cela ne requiert une competence que la plupart des gens appelleraient du piratage. Il suffit de savoir qu'il existe une case de recherche gratuite et d'y saisir un nom de domaine, ce qui est precisement pourquoi cela merite d'etre pris au serieux plutot que classe parmi les problemes de securite dont quelqu'un d'autre s'occupera.

Ce qui n'arrete rien de tout cela, et ce qui fonctionne vraiment

Il est tentant de se tourner vers les memes outils utilises pour gerer la facon dont les moteurs de recherche voient un site, mais aucun d'eux ne s'applique ici. Les choix que cet annuaire fait deja sur quels robots peuvent voir quelles pages passent par robots.txt et par l'indexation des moteurs de recherche, un systeme completement different dont un registre de certificats n'a jamais entendu parler. Bloquer un robot, desindexer une page ou la marquer noindex ne change rien au fait que son certificat apparaisse dans le registre, parce que le registre note le certificat lui-meme, pas la visibilite de la page pour les moteurs de recherche.

Il n'existe pas non plus de moyen legitime d'obtenir un certificat qui fonctionne sans avertissement dans le navigateur d'un visiteur tout en le gardant hors du registre. Demander a un hebergeur ou a une autorite de certification de faire une exception, c'est demander quelque chose qui n'existe pas pour une activite tournee vers le public: les seuls certificats exemptes d'enregistrement sont ceux delivres par une autorite de certification privee et interne, que les navigateurs des visiteurs ordinaires ne reconnaissent pas du tout, ce qui les rend inutiles pour tout ce qu'un client ou un annonceur a reellement besoin d'ouvrir.

Renommer ou supprimer un sous-domaine apres coup ne resout rien non plus, parce que l'ancienne entree du registre reste exactement ou elle etait. Il n'existe aucun nettoyage retroactif pour un nom deja enregistre de cette facon: la seule chose qu'un operateur puisse vraiment changer, c'est ce qui se passe a partir de maintenant.

Ce qui fonctionne vraiment, c'est le certificat wildcard decrit plus haut, utilise de maniere deliberee. Les outils internes, les copies de staging et tout ce qui est teste avant un lancement public devraient fonctionner derriere un seul certificat couvrant un modele entier, plutot qu'un nouveau certificat delivre par nom a chaque fois. La plupart des panneaux d'hebergement et des reseaux de diffusion de contenu delivrent par defaut un certificat nomme automatiquement des qu'un nouveau sous-domaine est ajoute, parce que ce reglage par defaut est plus simple a construire, pas parce que c'est le choix le plus sur; demander a l'hebergeur ou au developpeur de changer precisement ce reglage pour tout ce qui n'est pas une page marketing publique est une question concrete et verifiable, pas une demande vague d'amelioration de la securite.

La deuxieme veritable solution consiste a cesser de s'appuyer sur un nom obscur comme s'il s'agissait d'une serrure. Une page de connexion, une file de moderation ou un panneau de facturation ont besoin d'une veritable verification par mot de passe et, quand c'est possible, d'une restriction a un ensemble connu d'adresses de bureau ou de personnel, quel que soit leur nom, parce que le nom n'a jamais ete le seul moyen de les trouver: d'autres methodes techniques existent pour reveler les sous-domaines d'un site et n'ont rien a voir avec les certificats. Traiter un nom difficile a deviner comme la defense principale est la veritable erreur ici, pas le choix du certificat en lui-meme. Ce choix decide seulement si ce nom est offert gratuitement avant meme que quiconque ait besoin de le chercher.

Ce qu'il faut vraiment verifier cette semaine

La premiere etape ne coute rien et prend cinq minutes: ouvrir crt.sh, saisir le domaine de ce site et lire la liste complete de tout ce qui en ressort. Toute entree non reconnue merite une question directe a la personne qui gere l'hebergement: est-ce encore en service, et si oui, pourquoi l'internet public connait-il son adresse aujourd'hui.

Pour tout ce qui, dans cette liste, s'avere etre une fonctionnalite abandonnee, un test termine ou un projet pour un partenaire qui n'existe plus, la solution n'est pas seulement de retirer l'enregistrement DNS. Ce qui se trouvait derriere cette adresse devrait etre eteint au niveau du serveur, avec confirmation qu'il ne repond plus du tout a une requete, plutot que laisse en fonctionnement silencieux pendant qu'on ne retire que le panneau qui y menait.

Pour le prochain lancement d'une ville ou d'un pays, la phase de test devrait tourner sous un certificat wildcard ou un certificat interne partage, plutot que sous un certificat delivre avec le nom precis de cette ville, pour que le registre n'annonce pas l'expansion avant le marketing. C'est un seul reglage a confirmer avec un developpeur ou un hebergeur avant le prochain lancement, pas la reconstruction de quelque chose deja en ligne.

Pour chaque page interne de connexion, de moderation ou de facturation deja active aujourd'hui, la question n'est pas de savoir si son nom est difficile a deviner. C'est de savoir si un veritable mot de passe, et la ou c'est possible une restriction par adresse, s'y trouve bien, quel que soit le nom, parce que c'est cela qui tient vraiment une fois que le nom lui-meme est deja public, ce qui, apres avoir verifie crt.sh, est tres probablement deja le cas.