Étiquette : Certificats TLS

La dépendance aux Autorités de Certification : un risque sous-estimé ?

Les Autorités de Certifications (AC) ou Certification Authority (CA) sont des entités en charge d’émettre des certificats numériques pour authentifier l’identité des sites web, serveurs ou utilisateurs, et garantir l’intégrité des données échangées lors des communications en ligne.

Lorsqu’un site web ne dispose pas de certificat, il ne peut pas établir de connexion sécurisée via HTTPS, ce qui expose ses données à des risques d’interceptions, de modifications et d’usurpations. C’est pourquoi les navigateurs Internet des GAFAM (Google, Apple, Facebook, Amazon, Microsoft) imposent à ces AC des critères de conformité et de sécurité stricts et rigoureux, afin d’assurer une navigation sécurisée à leurs utilisateurs. Les GAFAM incarnent aussi de véritables empires, capables de façonner et de définir de manière quasi-arbitraire ou du moins unilatéralement, leurs propres règles dans le monde numérique.

Les Autorités de Certification, sont donc, d’une certaine façon, dépendantes des normes imposées par les GAFAM, ce qui devrait pousser les entreprises à ne pas s’inscrire dans un schéma de dépendance auprès d’une Autorité de Certification unique. D’autant plus que les AC peuvent faire face à des failles de sécurité, attaques, ou incidents, comme ce fut le cas pour l’Autorité de Certification hollandaise DigiNotar, forcée de mettre la clef sous la porte suite à un piratage massif en 2011.

La dernière AC en date à avoir fait face à des problèmes de sécurité est Entrust. Google Chrome a en effet annoncé mettre fin à la confiance accordée à ses certificats TLS (SSL) à partir du 31 octobre 2024, expliquant que cette décision fait suite à une évaluation approfondie des pratiques de sécurité de l’Autorité de Certification. Cela met donc en exergue certaines préoccupations concernant leur conformité à des normes strictes exigées : délais de révocations trop longs, failles répétées et risques pour les utilisateurs… Les versions 127 et ultérieures de Chrome désactiveront, à priori, en octobre, l’approbation automatique des certificats TLS/SSL délivrés par Entrust. Les sites web des entreprises utilisant leurs certificats risquent donc d’afficher des avertissements de sécurité dans Google Chrome, indiquant que le site n’est pas sécurisé, le rendant inaccessible ou dissuadant les visiteurs de poursuivre leur navigation.

Entrust, n’est évidemment pas un cas isolé. Symantec s’était retrouvée dans la tourmente en 2015 face à Google, suite notamment à l’émission de certificats TLS invalides. L’AC représentait à l’époque 30% des certificats sur le Web et affichait un revenu de 400 millions de dollars, comme le rapporte le média silicon.fr, mais Google avait progressivement banni ses certificats de Chrome et Android. L’entité a finalement été revendue à Digicert en 2021.

Les Autorités de Certification collaborent de manière étroite avec le CAB Forum et les GAFAM afin de renforcer les normes de cybersécurité, et d’améliorer leurs pratiques et protocoles de sécurité. Il est indéniable que d’immenses progrès ont été faits dans le domaine pour accroitre les standards de sécurité. L’incident récent impliquant Entrust, met néanmoins en évidence les risques qui persistent face à la souveraineté et l’influence inégalée des GAFAM : nul n’est à l’abri d’une décision arbitraire de la part de ces géants technologiques.

Face à ces failles, les entreprises ont la possibilité d’adopter une bonne pratique en optant pour une approche de multi-autorité de certification auprès d’un groupe spécialisé. En diversifiant les Autorités de Certification, les entreprises peuvent réduire le risque lié à la dépendance face à une panne, une révocation massive de certificats assurant ainsi leur continuité. Centraliser la gestion de certificats auprès d’un groupe de confiance permet aussi de standardiser les procédures, de simplifier la gestion de renouvellements ou de basculement de certificat d’une Autorité de Certification vers une autre, offrant ainsi davantage de flexibilité auprès d’un réseau compétent. Adopter une approche de gestion de ses certificats par une entité spécialisée représente ainsi un moyen d’assurer la continuité de ses services en ligne, une réduction des risques, et une optimisation de ses dépenses en cybersécurité face à une menace en constante évolution.

En somme, la dépendance aux Autorités de Certification est un risque qui pourrait se montrer coûteux, tant en termes financiers que de réputation. Voilà pourquoi, afin d’assurer la sécurité et la résilience de ses infrastructures numériques, une stratégie multi-AC peut s’imposer comme le rempart essentiel face aux imprévus des menaces cyber.

Source de l’image : Unsplash

ALERTE : Certificats TLS/SSL – Vigilance phishing

ALERTE : Certificats TLS/SSL - Vigilance phishing

Important : information relative à la situation en Russie, Biélorussie et Ukraine.

Au regard de la situation géopolitique en Ukraine, nous tenons à vous informer que de nombreuses autorités de certifications suspendent l’émission et la réémission de tous les types de certificats affiliés à la Russie et à la Biélorussie.

Cela inclut la suspension de la délivrance et de la réémission de certificats liés aux TLDs de la Russie et de la Biélorussie, à savoir .ru, .su, .by, .рф, ainsi qu’aux organisations ayant des adresses en Russie ou en Biélorussie. Nous vous tiendrons informés dès le retour à la normale.

Par ailleurs, nous constatons une augmentation importante des attaques par phishing. Nous vous invitons à une vigilance accrue, en surveillant notamment les nouveaux dépôts de noms de domaine reprenant vos marques.

Nameshield se tient bien sûr à votre disposition pour vous accompagner et vous conseiller dans ce contexte complexe.

Source de l’image : Freepik Storyset

Nouvelle fiche « 5 minutes pour comprendre – Le vol de données d’un site Internet » à découvrir sur le site de Nameshield

Fiche 5 minutes pour comprendre - Cybersécurité - Vol de données - Nameshield

Chaque jour, de nouvelles cyberattaques viennent mettre à mal les systèmes de défense des entreprises, et fragilisent encore plus les relations avec l’internaute, en particulier sur les sites marchands. Usurpation d’identité et vol de données sont devenus habituels.

Les risques qu’une personne malveillante intercepte les données transmises par l’internaute sur votre site Internet et plus largement toutes les informations transmises entre le navigateur et le serveur de votre site, sont en forte augmentation.

Retrouvez dans cette fiche « 5 minutes pour comprendre », disponible en téléchargement sur le site de Nameshield, quelle est la solution à mettre en place face à ces risques.

DECOUVRIR

Firefox 83 lance le mode HTTPS-Only

Mozilla a sorti, le 17 novembre dernier, la version 83 du navigateur Firefox, promettant notamment des performances accrues sur le chargement des pages et la réactivité dans la navigation ainsi qu’une baisse significative de la mémoire utilisée.

Mais Mozilla introduit surtout une grande nouveauté dans le petit monde des navigateurs, une option « HTTPS-Only Mode » pour limiter la navigation aux seules connexions sécurisées en HTTPS *.

Firefox 83 lance le mode HTTPS-only - Nameshield
Source de l’image : Mozilla Security Blog

Mozilla enfonce le clou en ce qui concerne la volonté des principaux navigateurs de faire passer le protocole HTTPS comme le protocole de navigation par défaut en lieu et place du HTTP non chiffré et donc totalement visible.

Quel affichage lors de la navigation ?

Lorsque l’option est activée, n’importe quelle page web ne disposant pas d’un certificat SSL/TLS (permettant d’afficher le HTTPS et le cadenas de sécurité dans la barre d’adresse du navigateur) se verra précédée du message d’alerte ci-dessous, rédhibitoire pour les internautes. 

Firefox 83 lance le mode HTTPS-only - Nameshield
Source de l’image : Mozilla Security Blog

A quoi s’attendre dans les années à venir ?

Si l’option n’est pas encore activée par défaut, la direction de Mozilla indique s’attendre à ce que le HTTPS devienne la norme pour naviguer sur le Web. Incités par les évolutions successives des navigateurs et de leurs affichages de plus en plus ostentatoires de l’absence de sécurité, de plus en plus de sites Web migrent vers le HTTPS par défaut. Il y a fort à parier que les fabricants de navigateurs décident de déprécier complètement les connexions HTTP dans un avenir proche, rendant de facto le HTTPS protocole par défaut de la navigation sur le Web.

Comment les entreprises peuvent-elles se préparer ?

La plupart des entreprises ont déjà entamé la migration vers le HTTPS par défaut de leur(s) site(s) Web. Il est important de maintenir à jour un inventaire exhaustif des sites et pages Web de l’entreprise, de maîtriser les certificats SSL-TLS associés dont les risques principaux sont les erreurs de renouvellement et mauvaise installation. Il est primordial d’établir des procédures claires et d’y associer une bonne communication à destination des interlocuteurs en charge des sites Web. Des acteurs tels que Nameshield sont là pour vous accompagner dans cette démarche. Ils disposent de l’expertise et des outils nécessaires à la simplification de ces tâches et à la réduction du risque d’erreur.

* HTTPS : quelques liens utiles au besoin

REPLAY WEBINAR CYBERSÉCURITÉ – SSL & HTTPS : définition, importance et risques liés aux certificats SSL

La croisade de Google pour l’adoption du HTTPS par défaut

Référencement naturel et certificats SSL : faut-il passer au HTTPS:// ?

Les dangers des certificats Wildcard

Certificats wildcard - certificat SSL/TLS
Source de l’image : skylarvision via Pixabay

Les certificats TLS/SSL sont utilisés pour authentifier les serveurs (Web le plus souvent) et chiffrer le trafic entre les sites Web et les utilisateurs. Ils garantissent ainsi l’intégrité des données échangées et empêchent l’espionnage de celles-ci. La digitalisation de l’entreprise et du monde en général, ainsi que la volonté des navigateurs d’imposer le HTTPS:// par défaut, ont multiplié de manière exponentielle les besoins en matière de certificats.

Pour répondre à ces besoins croissants, le certificat wildcard (*.nomdedomaine.com) est de plus en plus envisagé par les entreprises. S’il présente certains avantages, notamment en matière de réduction des coûts et de flexibilité, il convient d’en connaître les inconvénients pour choisir le bon certificat en toute connaissance de cause. Petit tour d’horizon du certificat wildcard.

Qu’est-ce qu’un certificat wildcard ?

Un certificat TLS standard permet de sécuriser un nom d’hôte (CN pour Common Name ou FQDN pour Fully Qualified Domain Name) explicite, défini dans ses métadonnées. Exemple, Google détient un certificat pour mail.google.com.

  • Ce certificat est valide uniquement pour : https://mail.google.com/
  • Il ne peut être utilisé pour : https://google.com/ – https://images.google.com/ – https://my.mail.google.com/

En d’autres termes, le nom d’hôte doit être une correspondance exacte. Si vous essayez d’utiliser ce certificat sur https://my.mail.google.com/ vous obtenez une erreur de certificat de votre navigateur.

Un certificat TLS wildcard est différent. Comme son nom l’indique, il utilise une correspondance générique plutôt qu’une correspondance exacte. Cette correspondance générique est matérialisée par « * » dans le CN et couvre tous les sous-domaines d’un même niveau. Exemple avec le certificat *.google.com.

  • Ce certificat est valide pour : https://mail.google.com/ ET https://images.google.com/ ainsi que tous les sous-domaines possibles de google.com.
  • Il ne peut être utilisé pour : https://google.com/ (sans sous-domaine) ou https://my.mail.google.com/ (le niveau de sous-domaine n’est pas le même).

Le côté pratique du certificat wildcard ?

Dans certaines situations, le certificat wildcard est très utile. Un hébergeur qui propose des sites web pour différents clients, hébergés sur un serveur mutualisé, et accessibles via des sous-domaines différents… client1.monsite.com,  client2.monsite.com, client3… Il est peu pratique, techniquement plus compliqué et de facto plus cher de demander un nouveau certificat pour chaque client qui s’inscrit ; l’option la plus simple est un certificat wildcard pour *.monsite.com, certificat unique qui couvrira tous les clients. Le cas est identique pour une entreprise qui souhaite accéder à ses sites web via des FQDN dérivés d’un même domaine et hébergés sur un même serveur web, *.monentreprise.com. Jusque-là tout va bien.

Mais alors, quel est le risque ?

Dans les cas ci-dessus, tous les sites sont hébergés sur un seul serveur. Dans les grandes entreprises, ou pour les sites web importants, les hébergements sont souvent plus complexes et sur des serveurs différents. Reprenons notre exemple de Google avec images.google.com et mail.google.com, ces deux applications sont liées à des services différents de l’entreprise, hébergées sur des serveurs différents et gérées par des équipes techniques différentes. Ce genre d’organisation est extrêmement fréquent dans l’entreprise. Et c’est là que la sécurité des certificats wildcard s’arrête.

Le problème du certificat wildcard, et dans une moindre mesure des certificats contenant des entrées multiples (les fameux SAN, Subject Alternative Names), vient du fait de les déployer sur plusieurs serveurs. En effet, pour assurer la sécurité d’un certificat TLS/SSL, il faut absolument protéger la clé privée associée au certificat. Idéalement la mettre au coffre ou dans un HSM. Lorsqu’on installe un certificat sur plusieurs serveurs, les clés privées associées circulent, augmentant l’exposition au risque de compromission.

Cas de la compromission d’un certificat

En cas de compromission d’un certificat, ou d’erreur sur le certificat (problème de renouvellement), il convient d’intervenir rapidement pour limiter les dommages causés. Demande d’un nouveau certificat (ou renouvellement), installation du nouveau certificat et, le cas échéant, révocation du certificat compromis.

Dans notre exemple de création de sites Web sur serveur unique, ce n’est pas un problème. Nous avons un seul serveur, il a été compromis, le certificat volé/expiré/compromis ne fonctionne que pour ce seul serveur ; nous avons limité les dégâts autant que possible.

Dans un scénario à « plusieurs serveurs », si le certificat d’un seul des serveurs est affecté, il devient compromis sur l’ensemble des serveurs, ce qui va entraîner des conséquences sur l’ensemble de ceux-ci et demander une intervention bien plus large, le plus souvent en urgence, pour réparer les dégâts, et en supposant que l’ensemble des serveurs affectés soit identifié. En effet il n’est pas rare que le certificat circule au sein de plusieurs équipes et installé sans être répertorié sur nombre de serveurs. L’impact peut être considérable.

En reprenant notre exemple de Google. Imaginons que seul le serveur images.google.com ait été piraté et que mail.google.com n’ait pas été affecté. Le certificat pour images.google.com étant un certificat wildcard pour *.google.com commun à mail.google.com, le cyber-attaquant ayant compromis le service d’images a par ricochet usurpé l’identité du serveur mail.google.com et peut intercepter le trafic du service de messagerie alors que ce serveur n’a jamais été piraté !

Bonne pratique à respecter : un certificat TLS/SSL par serveur… 

Dans notre dernier exemple, si nous avions eu deux certificats et non un seul, chacun des serveurs n’ayant accès qu’à son propre certificat, nous aurions limité le risque. Dans un monde idéal, chaque certificat ne doit être utilisé que pour un serveur (ou un cluster homogène de serveurs). Différents services sur différents serveurs doivent avoir leurs propres certificats, généralement non wildcard.

Un wildcard peut être utilisé si vous avez beaucoup de noms d’hôte, de type sous-domaine, pointant vers le même service sur le même serveur. Attention cependant que ce certificat générique ne couvre pas également des noms d’hôte pointant vers d’autres serveurs ; auquel cas chaque service devrait avoir ses propres certificats.

Enfin si vous avez quelques noms d’hôte pointant vers des serveurs uniques et tout le reste sur un seul service, alors il est préférable de dissocier les noms d’hôte. Par exemple, vous pouvez avoir un certificat pour login.monsite.com et un certificat (wildcard) pour *.clients.monsite.com. Sur ce dernier exemple, si le nombre de clients est fixe ou clairement défini, il vaut mieux s’orienter vers un certificat avec une liste de SAN précise, pour mieux maîtriser les noms d’hôte sécurisés et ne pas permettre le httpS:// sur des noms d’hôte non maîtrisés.

Conclusion

L’option du certificat wildcard existe et c’est une bonne chose pour certains besoins très spécifiques. Dans les faits, on ne devrait jamais avoir besoin de mettre en place un certificat wildcard, pas plus qu’on ne devrait installer un même certificat sur différents serveurs non bâtis en cluster.