Fuites de la Transparence des certificats : pourquoi votre URL de tunnel « secret » n'est pas secrète

Vous exécutez une seule commande, votre localhost obtient une adresse HTTPS publique comme https://k7x2m9qa.example-tunnel.dev, et vous la collez dans un chat client. Le libellé paraît aléatoire, personne ne la possède, il paraît privé.

Il peut déjà être public. Si un certificat de confiance publique a été émis pour ce nom d’hôte exact, le nom se trouve dans un journal public, en écriture append-only, que tout le monde peut lire, et des scanners automatisés surveillent ces journaux autour de l’horloge. L’obscurité n’a jamais été un contrôle d’accès, et la Transparence des certificats (CT) est la preuve la plus évidente.

Ce guide explique comment CT révèle les noms d’hôte, combien rapidement les scanners agissent sur eux, quand les certificats wildcard aident (et quand ils n’aident pas), et ce qui protège réellement un tunnel de développement. Les faits ont été vérifiés selon les sources actuelles en date de novembre 2026.

Qu’est-ce que la Transparence des certificats (et pourquoi elle existe)

La Transparence des certificats est un système de journaux publics, en écriture append-only, qui enregistrent les certificats TLS émis par des autorités de certification (CAs) reconnues publiquement. Il a été conçu comme un outil défensif : si une CA émet par erreur un certificat pour un domaine que vous possédez, le journal vous permet de le détecter. La spécification originale est RFC 6962, avec une version révisée dans RFC 9162.

Le détail crucial pour les utilisateurs de tunnels est ce qui est enregistré : l’ensemble complet des noms du sujet du certificat. Chaque nom d’hôte figurant sur le certificat devient une entrée publique.

CT n’est pas optionnel en pratique. Chrome l’exige pour les certificats EV depuis 2015 et pour la plupart des certificats publics depuis 2018, et les plateformes Apple appliquent leur propre politique CT. Un certificat de confiance publique sans SCTs valides (Signed Certificate Timestamps), qui sont les preuves signées d’inclusion des journaux, est rejeté par les navigateurs. L’écosystème continue de se resserrer : la Chrome Root Policy version 1.8, datée du 15 juin 2026, a renforcé les exigences CT et la gouvernance PKI pour tous les types de certificats publiés, et Chrome 148 (sorti le 5 mai 2026) a supprimé le support des SCTs fournis via les réponses OCSP attachées. Les SCTs doivent désormais être intégrées au certificat ou livrées via l’extension TLS.

La conséquence pratique : vous ne pouvez pas exempter un certificat de confiance publique du logging. L’entrée du journal existe aussi avant même que vous ne serviez le certificat, car les CA soumettent généralement un « pré-certificat » aux journaux d’abord pour obtenir les SCTs qu’ils intègrent dans le certificat final.

À quelle vitesse les scanners découvrent-ils un nouveau nom d’hôte ?

Plus rapidement que ce à quoi s’attendent la plupart des gens. La recherche fondamentale est l’article de la conférence ACM Internet Measurement Conference 2018, « The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem » par Scheitle et ses collègues. Les auteurs ont construit un honeypot CT et ont montré que les données des journaux CT sont utilisées pour cibler des campagnes de scan seulement quelques minutes après l’émission du certificat. Ils ont aussi développé une méthode qui combinait des étiquettes de sous-domaines extraites des certificats enregistrés avec des résolutions DNS, et elle a révélé 18,8 millions de noms d’hôtes qualifiés auparavant inconnus, environ 17,7 millions de plus que les autres listes publiques.

C’était en 2018. Aujourd’hui, les outils sont plus faciles, pas plus difficiles :

• Flux en temps réel. Des services comme Certstream exposent un flux WebSocket de certificats au fur et à mesure qu’ils sont enregistrés, ce qui permet à quiconque de filtrer par mots-clés, marques ou motifs dans les nouveaux noms d’hôte.
• Archives interrogeables. crt.sh permet à quiconque d’interroger tous les certificats jamais enregistrés pour un domaine, y compris un flux Atom pour les nouvelles entrées. L’énumération de sous-domaines via CT est une étape standard dans les tests d’intrusion car elle est gratuite et complète.
• Journaux plus rapides. Les journaux CT plus récents dits “static CT API”, comme les journaux Sunlight de Let’s Encrypt basés sur Sycamore et Willow, publient les données sous forme de fichiers statiques faciles à copier. La politique des journaux de Chrome exige que les journaux static-ct-api spécifient un délai de fusion maximal d’une minute, par rapport à environ 24 heures pour les journaux RFC 6962. L’ancien journal Oak de Let’s Encrypt devait être arrêté en février 2026.

Qu’il s’agisse d’un bot qui explore votre tunnel en trente secondes ou en trente minutes, cela varie, et personne ne peut promettre un chiffre. L’hypothèse sûre est celle que la recherche soutient : une fois qu’un certificat contenant votre nom d’hôte existe, traitez ce nom comme public.

Avertissement fin septembre sur les Quick Tunnels

Ce n’est pas un risque abstrait pour les utilisateurs de tunnels. Fin septembre 2026, TechSpot a couvert la tendance « une commande suffit pour mettre localhost sur Internet » autour des Cloudflare Quick Tunnels et a noté que ces URL sont publiques et que les bots ont tendance à les trouver rapidement.

Quelques éléments sur ce produit :

• Cloudflare a introduit Quick Tunnels en septembre 2021, et la fonctionnalité a été développée par un stagiaire, Rishabh Bector.
• Une seule commande cloudflared renvoie une adresse temporaire trycloudflare.com sans compte, domaine ou redirection de port nécessaire.
• La documentation de Cloudflare indique des limites : pas de garantie de disponibilité, jusqu’à 200 requêtes en vol par tunnel (des requêtes supplémentaires renvoient un 429), et pas de support Server-Sent Events.

Les chercheurs en sécurité ont noté une seconde voie de découverte au-delà de CT. Un rapport d IT-Connect a montré qu’une recherche site:trycloudflare.com sur Google renvoie des pages servies par Quick Tunnels. Les ingénieurs de détection y prêtent également attention : Elastic livre une règle pour des attaquants abusant des quick tunnels pour proxy du trafic de commande et contrôle. Si les défenseurs et les attaquants observent tous deux un motif d’hôte, votre URL « temporaire » n’est pas obscure.

La réponse de Cloudflare est révélatrice. Le 2 octobre 2026, il a ajouté un drapeau --allowed-mail à Quick Tunnels : les visiteurs doivent entrer un code PIN à usage unique envoyé à une adresse e-mail autorisée, et vous pouvez autoriser une adresse, plusieurs, ou un domaine d’adresse e-mail entier. L’accès se termine lorsque le processus cloudflared s’arrête. Avant cela, selon les notes de version, toute personne détenant un lien Quick Tunnel pouvait ouvrir le service. Un fournisseur ajoutant une porte d’accès reconnaît que l’URL seule n’est pas une porte.

Certificats par sous-domaine vs certificats wildcard

Ce que CT révèle dépend de la manière dont votre fournisseur de tunnel (ou vous-même) obtient les certificats. C’est le cœur de la question de découverte.

	Certificat par sous-domaine	Certificat wildcard
Ce qui apparaît dans les journaux CT	Le nom d’hôte exact, par ex. staging-api.example.com	Seulement le motif, par ex. *.example.com
Découverte par les analyseurs de journaux	Immédiate et spécifique	Révèle que des sous-domaines existent, mais pas lesquels
Validation Let’s Encrypt	HTTP-01, DNS-01, ou TLS-ALPN-01	DNS-01 uniquement
Couverture	Un nom (ou jusqu’à 100 noms sur un certificat SAN)	Un seul niveau de sous-domaines
Rayon de compromission de clé	Nom d’hôte unique	Chaque sous-domaine couvert partageant la clé
Utilisation typique	Services de production avec des noms stables	Dev, staging, sous-domaines par client ou par session

Une entrée wildcard apparaît dans le journal sous la forme *.example.com, un seul enregistrement quel que soit le nombre de sous-domaines servis. Ainsi, internal-dev.example.com ou une étiquette de tunnel par session n’apparaissent pas individuellement. C’est pourquoi les praticiens, y compris les membres de la communauté Let’s Encrypt, pointent les wildcards comme la méthode standard pour éviter d’exposer les listes de sous-domaines.Les outils d’énumération de sous-domaines s’appuient fortement sur CT, et un wildcard atténue cette technique.

Les wildcards comportent des compromis qu’il faut énoncer honnêtement. Ils exigent une validation DNS-01 avec Let’s Encrypt, ce qui signifie un accès automatisé à l’API de votre fournisseur DNS. Une seule clé privée protège désormais de nombreux noms d’hôtes, ce qui augmente le rayon d’attaque en cas de compromission. Et un wildcard ne couvre qu’un seul niveau d’étiquette : *.example.com ne couvre pas a.b.example.com.

Pour les services de tunnel, la situation comporte deux volets :

1. Si le fournisseur termine TLS avec un wildcard sur son propre domaine, les noms de tunnel individuels ne sont pas publiés via CT par ce certificat. L’exposition se déplace ailleurs (voir ci-dessous).
2. Si vous apportez votre propre domaine et que la configuration émet un certificat par nom d’hôte de tunnel, chaque nom d’hôte est publié au moment où le certificat est enregistré.

Demandez à votre fournisseur quel modèle il utilise. Ne supposez pas.

Les wildcards cachent le nom à CT, pas à tout le monde

Un wildcard résout une voie de fuite unique. Un sous-domaine reste un nom DNS simple, et les noms se propagent :

• Visibilité DNS et réseau. Les résolveurs, les bases de données DNS passives et les proxys d’entreprise voient les recherches. Le SNI (Server Name Indication) est envoyé en clair lors de la poignée de main TLS, sauf si Encrypted Client Hello est utilisé.
• Vous le partagez. L’URL passe dans Slack, les tickets, les commentaires de pull request et les e-mails. Les aperçus de liens et les archives de messages peuvent le récupérer et le stocker.
• Navigateurs et referers. L’historique du navigateur, la synchronisation, les extensions et les en-têtes Referer sur les liens sortants peuvent transmettre l’URL à des tiers.
• Moteurs de recherche et crawlers. Comme le montre le rapport d’indexation des Quick Tunnels, une URL publique peut se retrouver dans les résultats de recherche si elle est liée quelque part qu’un crawler visite.
• Journaux. Tout ce que votre application, votre CDN ou votre pile d’analyse consigne comprend le nom d’hôte.

Un certificat wildcard réduit une voie passive de découverte, mais il ne fait pas du nom d’hôte une authentification.

Pourquoi une URL aléatoire n’est pas un contrôle d’accès

Le contrôle d’accès consiste à vérifier qui vous êtes et refuser à tous les autres. Un nom d’hôte aléatoire ne fait pas cela. Quiconque connaît l’adresse peut accéder, sans trace de qui il est.

Les mathématiques sont parfois utilisées à tort comme défense. Un identifiant aléatoire en base-36 de huit caractères offre environ 2,8 billions de possibilités, ce qui semble immense. Mais la robustesse d’un secret dépend de s’il a fuité, et pas seulement du nombre de tentatives possibles. Une fois le nom dans un journal CT, dans un flux Certstream, dans une export Slack ou dans l’historique de synchronisation d’un navigateur, son entropie devient sans importance. Les attaquants n’ont pas besoin de deviner un nom qu’ils peuvent lire.

Trois problèmes supplémentaires suivent :

• Aucune révocation. Vous ne pouvez pas « faire tourner » une URL divulguée sans mettre le tunnel hors service.
• Aucune identité. Vous ne pouvez pas distinguer votre client d’un bot.
• Aucune portée (scope). Quiconque trouve l’URL accède à l’ensemble du service derrière celle-ci : les routes d’administration, les endpoints de débogage, les gestionnaires de webhooks, les bases de données locales exposées par l’application.

Traitez une URL de tunnel comme vous traiteriez une adresse IP publique avec un port ouvert, car fonctionnellement c’est ce que c’est.

Ce qui protège réellement un Dev Tunnel

Supposez la découverte. Puis rendez-la sans danger. Une approche en couches fonctionne :

1. Authentifier à la périphérie. Mettez une vérification d’identifiants devant le tunnel afin qu’une URL découverte renvoie un défi de connexion plutôt que votre application. Avec InstaTunnel, les flags CLI incluent --password pour la protection par mot de passe et --auth user:pass pour l’HTTP Basic Auth, et --subdomain pour un nom personnalisé et stable. # Password-protect a tunnel instatunnel 3000 --password "a-long-random-passphrase" # HTTP Basic Auth instatunnel 3000 --auth demo:a-long-random-passphrase # Stable name plus protection instatunnel 3000 --subdomain client-demo --password "a-long-random-passphrase"

Flags et niveaux changent, donc vérifiez instatunnel --help et la documentation actuelle avant de compter sur l’un ou l’autre.

1. Utiliser des identifiants longs et aléatoires. L’authentification HTTP basique n’a pas de défense intégrée contre les attaques par force brute, et les scanners qui trouvent un point de terminaison essaieront des mots de passe courants. Générez une phrase de passe à partir d’un gestionnaire de mots de passe; ne réutilisez jamais.
2. Maintenir HTTPS activé. L’authentification HTTP basique envoie les identifiants dans un encodage réversible, et non chiffré, ce qui n’est acceptable que via TLS.
3. Savoir où les mots de passe côté périphérique ne conviennent pas. Les appels automatisés tels que les expéditeurs de webhooks ne répondent généralement pas à une invite de mot de passe du navigateur. Pour ceux-là, vérifiez les signatures du fournisseur (HMAC ou en-têtes signés) sur votre propre serveur, et limitez le tunnel aux routes dont le fournisseur a besoin. Testez tout portail avec le client réel avant une démonstration.
4. Réduire la durée de vie. Un tunnel qui dure pendant une démonstration est exposé moins longtemps que celui qui reste actif toute la semaine. Utilisez instatunnel --list pour voir ce qui tourne et --kill <sous-domaine> pour en arrêter un.
5. N’exposez pas ce que vous ne publieriez pas. N’attachez le service local qu’à ce que vous avez l’intention de partager, supprimez les routes de débogage et utilisez des données de test. Ne tunnelisez pas une base de données ou une console d’administration sans une couche d’authentification supplémentaire dans l’application elle-même.
6. Surveiller vos propres noms. Si vous exploitez votre propre domaine, abonnez-vous à la surveillance CT (flux crt.sh ou filtres Certstream) pour ce domaine. Vous verrez exactement ce que voit un attaquant et pourrez repérer les certificats inattendus tôt.
7. Préférez un portail d’accès basé sur l’identité pour les équipes. Pour les liens de staging partagés, une authentification à la périphérie qui lie l’accès à une identité vérifiée, comme des codes PIN envoyés par e-mail à usage unique ou OAuth/OIDC au niveau du proxy, bat un mot de passe partagé car vous pouvez le restreindre par personne.

Questions fréquentes

Puis-je empêcher que le nom d’hôte de mon tunnel soit enregistré dans CT ? non avec un certificat de confiance publique. L’enregistrement est une condition de confiance du navigateur. Les approches possibles sont un certificat wildcard (pour que le nom exact ne soit pas enregistré) ou une CA privée pour les noms internes uniquement, qui ne seront pas approuvés par les navigateurs externes.

Un certificat wildcard rend-il mon tunnel privé ? Non. Il supprime une voie de découverte, CT, pour les noms d’hôtes individuels. Le partage, les referers, la visibilité DNS et les crawlers restent applicables, donc une authentification reste nécessaire.

À quelle vitesse les scanners trouvent-ils un nouveau nom d’hôte ? Des recherches de 2018 montrent des balayages arrivant en quelques minutes après l’émission; les infrastructures et outils des journaux n’ont fait que s’améliorer depuis. Prévoyez une découverte quasi immédiate.

Un sous-domaine long et aléatoire suffit-il pour une démonstration courte ? Pour quelque chose de réellement inoffensif, un lien à durée limitée non listé comporte peu de risques. Pour tout ce qui implique des données clients, des identifiants ou des outils internes, ajoutez une authentification. Il suffit d’un seul flag.

Les Basic Auth et la protection par mot de passe suffisent-ils ? Ils bloquent la découverte casual et automatisée qui atteindre votre app. Ils ne remplacent pas la sécurité au niveau de l’application, les webhooks signés ou l’accès basé sur l’identité pour les tâches sensibles.

En résumé

La Transparence des certificats rend lisibles tous les noms d’hôtes publiquement confiés, et les outils pour les lire en temps réel sont gratuits. Un certificat par sous-domaine publie le nom exact de votre tunnel, et un wildcard cache le nom dans CT mais pas dans les nombreuses autres places où les noms fuient. Dans les deux cas, le modèle mental correct reste le même : l’URL est une adresse, pas un mot de passe.

Mettez une authentification devant tout ce que vous tunnelisez, gardez des identifiants longs et aléatoires, et limitez l’exposition. Si vous faites cela, la découverte d’un nom d’hôte par un scanner vous coûtera une invite de connexion plutôt qu’un incident.

Sources

• Scheitle et al., The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem, ACM IMC 2018
• Encryption Consulting, Certificate Transparency monitoring
• Chrome, Policy de Transparence des certificats (Certificate Transparency Log Policy)
• Let’s Encrypt, Certificate Transparency (CT) Logs
• Apple, Certificate Transparency policy
• TechSpot, One command trick can put localhost on the internet
• Cloudflare, Documentation Quick Tunnels et Cloudflare: Quick Tunnels: Anytime, Anywhere
• Cloudflare changelog, Protect Quick Tunnels with email authentication (via Tproger)
• IT-Connect, TryCloudflare Quick Tunnels are being indexed on Google
• Elastic, Potential Protocol Tunneling via Cloudflared
• InstaTunnel, npm package README