Étiquette : Certificats TLS

Durée des certificats SSL/TLS réduite à 45 jours en 2027 : Apple fait le premier pas

Le 9 octobre, Apple a révélé au CA/B Forum avoir publié un projet de vote pour commentaires sur GitHub au sujet de deux évènements importants sur la durée de vie des certificats SSL/TLS :

  • réduire progressivement la durée maximale des certificats SSL/TLS publics à 45 jours d’ici 2027 ;
  • réduire progressivement la période de réutilisation des challenges DCV à 10 jours d’ici 2027.

En mars 2023, Google annonçait, dans sa roadmap « Moving Forward, Together », son intention de proposer au CA/B Forum la réduction de la durée de validité maximale possible des certificats TLS publics de 398 jours à 90 jours. Depuis cette annonce, le marché attendait fébrilement la confirmation de Google et surtout le calendrier d’applicabilité… sans succès. Mozilla annonçait quant à lui il y a quelques semaines, son intention d’emboîter le pas à Google pour son navigateur Firefox, mais sans plus de précisions.

C’est finalement Apple qui a fait le premier pas la semaine dernière en annonçant le 9 octobre, sa double volonté de réduire d’une part la durée de vie des certificats à  45 jours (alors que tout le marché s’attendait à 90 jours) et d’autre part la limitation de la durée du challenge DCV à 10 jours, le tout selon le calendrier ci-dessous. Une véritable petite bombe :   

15-sep-2025 => durées certificats et validation DCV réduites à 200 jours

15-sep-2026 => durées certificats et validation DCV réduites à 100 jours

15-avr-2027 => durées certificats et validation DCV réduites à 45 jours

15-sep-2027 => durée de validation DCV 10 jours

Quelques informations sur le contexte et l’analyse de cette annonce, les impacts attendus et comment s’y préparer seront sans doute utiles :

Contexte et Analyse :

A ce stade, il s’agit d’une publication susceptible d’être commentée par les acteurs du marché avant la rédaction formelle d’un ballot au sein du CA/B Forum, lui-même amené à être voté par ses membres : les éditeurs de navigateurs Internet d’un côté (Google, Mozilla, Apple et Microsoft…) et les Autorités de Certification de l’autre. Des modifications ne manqueront pas d’être apportées, mais l’idée générale est là et la machine se met en marche.

En effet, les éditeurs de navigateurs sont tous alignés sur le besoin de réduire la durée de vie des certificats et parmi les Autorités de Certification, Sectigo, un des acteurs majeurs de l’industrie des certificats, soutient d’ores et déjà l’initiative. Il y a fort à parier que les choses vont bouger rapidement dorénavant avec peu de commentaires et une rédaction du ballot dans les semaines ou mois qui viennent. Nous en saurons alors plus sur la confirmation des durées et du calendrier, nous vous tiendrons bien sûr informés.

Impacts attendus :

  • Durée des certificats : qu’elle soit in fine de 90 jours, 45 jours ou même moins, cette réduction n’est plus une surprise et son impact sera important pour les parcs de certificats publics. Ils ne pourront plus être gérés de manière manuelle. Le marché a commencé sa transition vers l’automatisation en s’appuyant notamment sur les CLM (Certificate Lifecycle Manager). La clé pour les entreprises et les organisations sera de s’appuyer sur des partenaires qui pourront offrir le plus d’interconnexions possibles entre les Organisations, les Autorités de Certification et les CLM.
  • Durée du challenge DCV : réduire à 10 jours la durée d’utilisation du challenge DCV, si c’était validé, aurait un impact considérable, peut-être plus encore que la réduction de la durée de vie des certificats. Jusqu’à présent, l’industrie pré-validait les noms de domaine pour une durée de 398 jours, en utilisant une seule fois le challenge DCV. L’annonce d’Apple forcerait à utiliser un challenge DCV pour quasiment toutes les commandes, ce qui serait un changement de paradigme majeur et impliquerait l’interconnexion avec une brique supplémentaire de l’écosystème : le DNS. En effet, le challenge DCV pour Domain Control Validation implique d’intervenir dans la zone du ou des noms de domaine listé(s) dans le certificat, idéalement de manière instantanée pour valider celui-ci.
  • Durée d’authentification des Organisations : Apple n’a rien annoncé au sujet de la durée de validité de l’authentification d’une organisation pour les certificats de type OV, actuellement de 825 jours. Pour autant, de nombreuses rumeurs courent sur une réduction à 398 jours voire 365 jours.

Comment se préparer :

La clé d’une bonne gestion à venir des certificats repose sur l’automatisation. 45 jours de durée des certificats représentent 9 interventions par an par certificat, la gestion manuelle deviendra utopique. Il faut donc s’appuyer sur :

  1. Fournisseur de certificats / Autorité de Certification (AC) : un partenaire de confiance qui vous accompagnera dans les problématiques d’authentification des organisations et domaine. Le niveau de service est la clé pour une bonne gestion. Un partenaire multi-AC est recommandé pour limiter la dépendance à une seule AC, cas des récents déboires d’Entrust.
  1. Registrar / DNS Primaire : maîtriser le DNS primaire des noms de domaine listés dans les certificats va devenir la clé de la livraison. Chaque émission de certificat entrainera l’installation d’un TXT ou d’un CNAME sur la ou les zones concernées. Avoir une interconnexion entre l’AC et le DNS est primordial.
  1. Editeur CLM : inventorier le parc de certificats, définir des règles de gestion du parc et assurer l’automatisation complète du processus de commande depuis la génération des CSR jusqu’au déploiement des certificats sur les serveurs, c’est le travail du CLM. Et celui-ci pour fonctionner, s’appuie sur des connecteurs avec les AC ou fournisseurs de Certificats.

Se préparer c’est donc identifier les solutions qui vous conviennent sur ces trois points et lancer cette réflexion pour comprendre les impacts en matière de processus, de technologie et de budget, dans un monde idéal, avant la fin du premier semestre 2025.

L’approche de Nameshield :

Nameshield occupe une place unique sur le marché en étant registrar et fournisseur de certificats multi-AC. Depuis plus de 10 ans, nous gérons au quotidien toutes les problématiques liées à l’authentification des organisations et des domaines liés aux certificats en ayant d’un côté, une relation privilégiée avec les plus grandes AC du marché (Digicert, Sectigo, GlobalSign), et en maitrisant de l’autre la brique DNS pour la validation DCV. De ce fait, nous émettons des certificats publics de manière quasi instantanée. Enfin, en ce qui concerne la brique CLM, Nameshield dispose de connecteurs avec les plus grands acteurs du marché pour vous permettre d’assurer une connexion complète entre les différentes briques liées à la gestion des certificats. Nous vous accompagnons ainsi dans l’anticipation de l’ensemble des problématiques mentionnées ci-dessus.

Durée des certificats SSL/TLS réduite à 45 jours en 2027 : Apple fait le premier pas

Pour plus d’informations, n’hésitez pas à contacter notre Equipe Commerciale ou notre Equipe Certificats.

Crédit image : Nameshield with storyset.com

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.

Let’s Encrypt, ne pas confondre confidentialité et sécurité

Let’s Encrypt a récemment fait parler dans le petit monde des certificats TLS, en révoquant soudainement 3 048 289 certificats qui n’auraient pas dû être délivrés. Un bug dans leur logiciel de validation empêchait les contrôles des enregistrements CAA, et les certificats en question n’auraient pas dû être initialement délivrés. Des perturbations importantes ont résulté de cette révocation massive, mais il est difficile de se plaindre d’un service gratuit. 

On me demande souvent ce que je pense de Let’s Encrypt, et j’ai toujours cette même réponse : Let’s Encrypt a fait énormément pour chiffrer le web, mais met à mal la sécurité du web. Le chiffrement permet d’assurer la confidentialité (personne ne peut espionner) et l’intégrité (personne ne peut modifier) des échanges. Mais le chiffrement seul ne peut suffire si je n’ai aucune garantie de l’identité de celle ou celui avec qui j’échange (légitime ou frauduleux ?)… Et c’est bien là tout le problème.

Let's Encrypt - Certificats SSL TLS - Nameshield

En 2015, l’initiative Let’s Encrypt, supportée par les grands noms de l’Internet (EFF, Mozilla, Cisco, Akamaï…) voyait le jour avec pour objectif de diffuser en masse et gratuitement des certificats SSL au monde entier. Plus de cinq ans après sa création, l’organisation sécurise 190 millions de sites web et vient d’annoncer avoir distribué un milliard de certificats. Le cap a été franchi le 27 février 2020. C’est indiscutablement une belle performance.

96% du web chiffré en janvier 2020

En 2015, moins de la moitié du trafic web était chiffrée, pour grimper à 96% en janvier 2020. Bien sûr Let’s Encrypt n’est pas le seul acteur responsable de cet essor. Edward Snowden a lancé la première alerte, Google s’est largement engouffré dans la brèche, entre politique de référencement et modification des indicateurs de sécurité web. Mais en mettant à la disposition de tous, des certificats gratuits et basés sur un système largement automatisé, Let’s Encrypt a démocratisé le chiffrement… et mis aux oubliettes la notion d’identité.

Pas d’identité, pas de sécurité

Let's Encrypt - Certificats SSL TLS - Nameshield

Le credo de Let’s Encrypt est la simplicité, pour « simplifier à l’extrême le déploiement du HTTPS et en finir avec sa bureaucratie horriblement complexe » (dixit l’EFF dans la campagne de lancement). La bureaucratie horriblement complexe a pourtant une raison d’être : l’authentification forte, garante de l’identité du titulaire du certificat. Peut-être pas une garantie absolue de légitimité, pas une garantie de contenu non plus, mais la garantie d’une société enregistrée, légitimement propriétaire du nom de domaine concerné et avec un certificat validé selon une procédure drastique.

Let’s Encrypt, se contente de vérifier le contrôle du nom de domaine (DV, Domain Validation). Il suffit de cliquer sur un lien dans un email ou de renseigner un record TXT sur la zone DNS du nom de domaine. Or l’enregistrement de noms de domaine dans la plupart des TLD est purement déclaratif. Il est assez facile d’enregistrer un nom de domaine, de demander un certificat à Let’s Encrypt et de publier un site web en HTTPS://.

Résultat des courses ?

En cinq ans, l’ensemble des sites de phishing et sites frauduleux sont passés en HTTPS://. Dès 2016, Vincent Lynch alertait sur ce problème, 15 270 certificats contenant le terme « Paypal » avaient été émis par Let’s Encrypt, dont 14 766 frauduleux.

Le marché a été tiré vers le bas en termes de niveau d’authentification. Let’s Encrypt est loin d’être le seul responsable, Google et Mozilla, du haut de leurs 70% de parts de marché, ayant largement soutenu l’initiative, les gros hébergeurs du Cloud ont suivi, de même que les Autorités de Certification, challengées sur les prix. Nous avons aujourd’hui un web sécurisé avec 77% (novembre 2019) de certificats dont la légitimité du propriétaire n’est pas vérifiée.

L’authentification forte change la donne 

Le web est devenu chiffré par défaut. Est-il plus sûr pour autant ? Rien n’est moins sûr. L’internaute, éduqué depuis 20 ans à vérifier la présence du cadenas dans sa barre d’adresse, fait confiance à un web dont tous les sites frauduleux affichent le cadenas de sécurité. L’Internet est aujourd’hui confidentiel, mais il n’est pas sûr pour autant.

Il est urgent de revenir à l’authentification forte. L’authentification forte garantit un ensemble d’étapes obligatoires, drastiques et contrôlées pour l’obtention des certificats. Les procédures sont édictées par le CA/B Forum, renforcées régulièrement et suivies d’audit des Autorités de Certification.

23% des certificats sont encore délivrés sur la base de l’authentification forte, la plupart dans le monde de l’entreprise où les RSSI poussent pour la préserver. Nous devons tous nous appuyer sur eux, et soutenir les initiatives supportant les certificats OV (Organization Validation) et EV (Extended Validation), en particulier EV pour garantir l’identité des sites visités par les internautes. Si l’identité sur Internet semble avoir été quelque peu oubliée depuis quelques temps au profit de la confidentialité, elle risque de revenir rapidement sur le devant de la scène, poussée notamment par les internautes et le besoin de protection des données personnelles.

Apple annonce la limitation de la durée des certificats SSL à 1 an dans Safari

Apple Safari SSL - Blog Nameshield
Source de l’image : kropekk_pl via Pixabay

Apple a annoncé cette semaine que la durée de vie maximale des certificats SSL/TLS sur ses appareils et son navigateur Safari serait limitée à 398 jours (1 an, et 1 mois pour couvrir la période de renouvellement). Le changement, annoncé par Apple lors de la réunion CA / Browser Forum à Bratislava, en Slovaquie, entrera en vigueur pour les certificats émis après le 31 août 2020.

L’annonce d’Apple fait suite à un échec du vote du CA/B Forum sur les certificats d’un an (bulletin SC22), qui s’est tenu en août 2019, et reflète une tendance continue à raccourcir la durée de vie des certificats. A la suite de ce vote, Google avait d’ailleurs exprimé son intention de réduire la durée de vie des certificats en dehors du cadre du CA/B forum si celui-ci ne se positionnait pas rapidement. Cette annonce est une demi-surprise, nous aurions plutôt pensé que Google ou Mozilla ferait le premier pas.

Quelles conséquences pour les sociétés et leurs certificats SSL/TLS?

La validité plus courte est-elle une bonne chose?

Plus la période de validité d’un certificat est courte, plus le certificat est sûr. En exigeant le remplacement des certificats sur une période plus courte, les mises à jour de sécurité sont apportées aux certificats, elles se déploient plus rapidement. La durée de vie de la clé privée d’un certificat, plus courte, est aussi une forte recommandation des acteurs de la sécurité en ligne afin de limiter la durée potentielle d’une fraude suite à une compromission.

D’un point de vue sécurité, tout le monde s’accorde à dire qu’une réduction de la durée de vie des certificats est une bonne chose. Le problème se situe du côté opérationnel avec les conséquences annoncées de cette réduction : plus d’interventions sur les certificats, donc une plus grande complexité dans le maintien d’un inventaire à jour et le besoin d’une organisation optimale avec les partenaires pour l’émission des certificats.

Faut-il tenir compte de l’annonce d’Apple ?

Safari est l’un des deux principaux navigateurs web, avec 17,7% en janvier 2020, derrière Google Chrome (58,2%) et devant Microsoft Internet Explorer et Edge (7,1%). Il parait difficile de faire fi de cette annonce qui touchera 1/5 des internautes, qui plus est si Google suit, il vaut mieux anticiper et se préparer. C’est d’ores et déjà le conseil de Nameshield.

Ce qu’il faut garder à l’esprit 

Les certificats émis avant le 1er septembre 2020 ne sont pas affectés par cette modification. Ils resteront valides pendant toute la période de deux ans et n’auront pas besoin d’être modifiés ou remplacés. Tous les certificats émis le 1er septembre ou après devront être renouvelés chaque année pour rester fiables par Safari.

Il faut donc se préparer à passer à des certificats d’une durée d’un an maximum contre deux actuellement. S’appuyer sur un partenaire et des outils efficaces est plus que jamais indispensable.

Vers la fin de la corrélation entre l’authentification et la gestion technique des certificats

Ce qui semble se dessiner au sein du CA/B Forum est le fait de permettre une durée d’authentification identique à celle que l’on connait aujourd’hui (deux ans) tout en forçant les certificats à être remplacés plusieurs fois durant cette même période.

Les principales Autorités de Certification, les organismes qui délivrent les certificats, anticipent ces changements et travaillent sur plusieurs systèmes d’automatisation du cycle de vie des certificats. Elles limiteraient ainsi le besoin de passer par une procédure de réauthentification potentiellement lourde à chaque remplacement. Les entreprises pourraient remplacer leurs certificats autant de fois qu’elles le souhaiteraient durant cette période. Cela permettrait notamment d’anticiper d’éventuelles nouvelles réductions de la durée de vie maximale des certificats.

La tendance est également à la mise en place d’outils d’automatisation pour le maintien d’un inventaire précis des certificats d’une part et la réinstallation technique de l’autre. Nameshield suit de près ces différentes évolutions et vous permettra de continuer à travailler en toute confiance.

Notre équipe se tient également à votre disposition pour anticiper ces changements et répondre à vos éventuelles questions.

Bientôt une durée maximale d’1 an pour les certificats SSL ?

Certficats SSL TLS - HTTPS

Que se passe-t-il ?

Les acteurs de l’industrie envisagent de réduire la durée de vie des certificats SSL/TLS, permettant l’affichage du HTTPS dans les navigateurs, à 13 mois, soit environ la moitié de la durée actuelle de 27 mois, afin d’améliorer la sécurité.

Google, via le CA/Browser Forum a en effet proposé cette modification, approuvée par Apple et une autorité de certification, la rendant éligible au vote. Si le vote est accepté lors des prochaines réunions du CA/B Forum, la modification des exigences entrera en vigueur en mars 2020. Tout certificat délivré après la date d’entrée en vigueur devra respecter les exigences de la période de validité abrégée.

L’objectif de cette réduction est de compliquer la tâche des cyber-attaquants en réduisant la durée d’utilisation des certificats potentiellement usurpés. Cela pourrait également obliger les entreprises à utiliser les algorithmes de chiffrement les plus récents et les plus sécurisés disponibles.

Si le vote échoue, il n’est pas à exclure que les navigateurs parrainant cette exigence l’implémentent de manière unilatérale dans leur programme racine, forçant ainsi la main aux autorités de certification. Il y a fort à parier que ce soit le chemin suivi, ce changement fait suite à l’initiative précédente de Google visant à réduire la durée de vie de trois à deux ans en 2018, époque à laquelle Google souhaitait déjà une durée réduite à 13 mois voire moins.

Qui est touché ?

Les modifications proposées par Google auraient une incidence sur tous les utilisateurs de certificats TLS de confiance publique, quelle que soit l’autorité de certification qui émet le certificat. Si le vote passe, tous les certificats de confiance émis ou réémis après mars 2020 auront une validité maximale de 13 mois. Les entreprises utilisant des certificats dont la période de validité est supérieure à 13 mois seront encouragées à revoir leurs systèmes et à évaluer l’incidence des modifications proposées sur leur déploiement et leur utilisation.

Les certificats TLS émis avant mars 2020 avec une période de validité supérieure à 13 mois resteront fonctionnels. Les certificats non-TLS public, pour la signature de code, le code privé TLS, les certificats clients, etc… ne sont pas concernés. Il ne sera pas nécessaire de révoquer un certificat existant à la suite de la mise en place de la nouvelle norme. La réduction devra être appliquée lors du renouvellement.

Qu’en pensent les acteurs du marché ?

Il s’agirait d’un changement global du secteur, qui aurait des répercussions sur toutes les autorités de certification. Celles-ci voient cette proposition d’un mauvais œil. On peut y voir avant tout un intérêt économique mais pas uniquement…

Leur argument principal est que le marché n’est pas encore prêt en termes de système d’automatisation des commandes et installations de certificats. De fait les interventions humaines seraient plus nombreuses, avec les risques associés à une mauvaise manipulation, ou tout simplement un risque plus élevé d’oubli de renouvellement d’un certificat.

Pour les autorités de certification, réduire à si court terme la durée des certificats présente surtout une augmentation significative des coûts humains liés à la gestion du portefeuille de certificats. Si elles ne sont pas fondamentalement contre cette décision, elles voudraient surtout des délais un peu plus long pour étudier notamment ce qu’en pensent les utilisateurs et les entreprises.

La position des fabricants de navigateurs ?  

Que ce soit Google ou Mozilla, fers de lance de l’adoption massive du HTTPS natif pour tous les sites web, et supporters de l’initiative Let’sEncrypt, l’important c’est le chiffrement de tout le trafic web. Une réduction de la durée des certificats réduit le risque d’usurpation des certificats sur une longue durée et favorise l’adoption massive de systèmes de gestion automatisés. Pour ces deux acteurs, un monde idéal contiendrait des certificats d’une durée maximale de 3 mois. S’ils sont à l’écoute du marché pour ne pas imposer trop rapidement leurs vues, il y a fort à parier qu’à long terme la durée de vie des certificats continuera à diminuer.

L’avis de Nameshield

Le marché poursuit son évolution vers des durées de certificats de plus en plus courtes, tout comme une diminution continuelle des niveaux d’authentification et en conséquence un besoin qui va aller croissant pour des solutions de gestion automatisées. Nous nous alignerons sur ces impératifs et conseillons à nos clients de se préparer à cette diminution qui arrivera, à n’en pas douter. Nos autorités de certification partenaires suivront également cette évolution et permettront d’offrir tous les systèmes d’inventaire permanent et d’automatisation requis.

Être entendu

Le forum CA/Browser accepte les commentaires de participants extérieurs et toutes les discussions sont publiques. Vous pouvez soumettre vos commentaires directement à la liste de diffusion du Forum : https://cabforum.org/working-groups/ (en bas de page). Nameshield est en contact avec des participants du CA/B forum et vous tiendra informés des décisions à venir.