Un défaut critique de validation des domaines chez SSL.com — l’une des autorités de certification (CA) reconnues par des navigateurs comme Chrome, Firefox et Safari — a mis en péril l’intégrité de l’écosystème SSL/TLS. Cette vulnérabilité permet à des acteurs malveillants d’obtenir des certificats valides pour des domaines qu’ils ne contrôlent pas, ouvrant la porte à des attaques de phishing et d’espionnage sans que les utilisateurs reçoivent d’avertissement.

Vulnérabilité dans la méthode DCV : comment fonctionnait l’attaque

L’incident concerne le mécanisme Domain Control Validation (DCV), spécifiquement la méthode 3.2.2.4.14 définie dans les exigences de base du CA/Browser Forum. Cette méthode utilise une adresse courriel spécifiée dans un enregistrement DNS TXT pour valider que le demandeur d’un certificat a le contrôle sur un domaine.

L’implémentation défectueuse de SSL.com permettait de valider des domaines en se basant sur le domaine de l’adresse e-mail du demandeur, sans vérifier s’il avait réellement le contrôle. En d’autres termes, si un attaquant utilisait une adresse comme usuario@aliyun.com (provenant d’un fournisseur de courriel connu), SSL.com pouvait valider le domaine aliyun.com dans son intégralité et émettre un certificat pour aliyun.com ou même www.aliyun.com, sans en être le propriétaire.

Un exemple détaillé de l’attaque a été partagé sur Bugzilla de Mozilla, où il est démontré comment reproduire le défaut avec des domaines arbitraires et des comptes de courriel gratuits.

Certificats valides, risque invisible

Le danger de ce défaut réside dans le fait que le certificat SSL/TLS émis est techniquement valide et approuvé par tous les navigateurs. Cela signifie qu’un attaquant pourrait :

• Créer une copie exacte d’un site légitime avec un cadenas HTTPS valide.
• Réaliser des attaques Man-in-the-Middle (MITM) sans générer d’alertes de sécurité.
• Diffuser des logiciels malveillants ou lancer des campagnes de phishing difficiles à détecter.

Qui est en risque ?

Toute organisation ayant des courriels accessibles publiquement et qui ne limite pas explicitement quelles CA peuvent émettre des certificats pour ses domaines (via des enregistrements DNS CAA) est potentiellement vulnérable. Cela inclut :

• Des entreprises avec des courriels tels que info@, admin@, webmaster@ sans contrôle strict.
• Des projets open source ou des domaines personnels sans enregistrements CAA configurés.
• Des fournisseurs de services de courriel qui permettent l’ajout d’adresses externes à des domaines légitimes.

La réponse de SSL.com et prochaines étapes

SSL.com a reconnu le problème, a révoqué le certificat émis par erreur et a désactivé temporairement la méthode DCV affectée. Un rapport préliminaire est attendu avant le 21 avril 2025, selon l’entreprise.

Cependant, cet incident est un rappel clair que la confiance dans HTTPS ne peut pas reposer uniquement sur le protocole ou sur les cadenas visibles dans le navigateur. L’infrastructure des CA — bien qu’elle soit robuste — peut faire défaut, et lorsque cela se produit, l’impact peut être silencieux et dévastateur.

Recommandations pour les responsables techniques et de la sécurité

Les équipes d’infrastructure, DevOps et sécurité doivent examiner d’urgence leur stratégie de gestion des certificats :

1. Implémenter des enregistrements CAA sur tous les domaines d’entreprise pour limiter les CA autorisées.
2. Surveiller les journaux de transparence des certificats (CT logs) avec des outils comme crt.sh ou des services tels que TrackSSL.
3. Auditer les adresses de courriel utilisées pour la validation des certificats.
4. Évaluer la fiabilité de leurs autorités de certification actuelles, et envisager des CA qui appliquent des validations plus strictes.
5. Automatiser la gestion et la révision des certificats pour détecter les anomalies avant qu’elles ne deviennent des incidents.

La révocation suffit-elle ?

Bien que SSL.com ait agi rapidement pour révoquer le certificat, la révocation en elle-même n’est pas une garantie de sécurité immédiate. De nombreux navigateurs ne valident pas en temps réel l’état des certificats, ce qui signifie qu’un certificat révoqué pourrait continuer à être accepté pendant des semaines. C’est pourquoi les experts recommandent de combiner la révocation avec une détection précoce et des politiques préventives.

En conclusion, cette faille chez SSL.com souligne l’importance d’adopter une posture active et vigilante dans la gestion des certificats numériques. Dans un environnement où la confiance dans HTTPS est essentielle, compter uniquement sur les contrôles des CA n’est plus suffisant. La sécurité du canal chiffré commence par des décisions éclairées de la part des équipes techniques et une défense en profondeur qui ne laisse aucune faiblesse.

Source : Actualités de la sécurité