Catégorie : SSL

[WEBINAR] Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ? – Le 30/01 à 11h

[WEBINAR] Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l'automatisation ? – Le 21/01 à 11h

Rendez-vous le 30 janvier à 11h pour assister à notre nouveau webinar « Réduction de la durée des certificats SSL/TLS à 45 jours : Comment se préparer face au challenge de l’automatisation ? » animé par Christophe GÉRARD, Directeur Produits de Nameshield et Alexandre AUFRERE, Directeur Technique d’Evertrust.

Ce webinar fait suite aux annonces de Google, qui annonçait en 2023 son intention de réduire la durée des certificats à 90 jours et d’Apple qui proposait, le 9 octobre 2024, un premier calendrier prévisionnel indiquant une durée des certificats réduite à 45 jours en 2027 et la limitation à 10 jours pour le challenge DCV. Une mise à jour d’Apple a très récemment été publiée annonçant reculer son calendrier de 6 mois, avec pour nouvel objectif, des certificats de 47 jours en mars 2028.

Ces annonces sonnent dès aujourd’hui le glas de la gestion manuelle des certificats SSL/TLS publics et lancent officiellement le besoin d’automatisation.

Nos deux experts vous présenteront au cours de ce webinar :

  • Le contexte et les impacts sur la gestion des certificats,
  • La nécessité de se préparer à l’automatisation en maîtrisant les acteurs indispensables de toute la chaîne : Autorité(s) de Certification, DNS et CLM.
  • Comment des prestataires comme Nameshield et Evertrust sont des alliés essentiels pour vous accompagner et anticiper l’ensemble des problématiques liées à ces annonces.
Je m’inscris

Pour y assister, il faudra au préalable vous inscrire sur la plateforme Webikeo (inscription gratuite) puis réserver votre place pour ce webinar. Vous pourrez ainsi participer à cette web-conférence et poser vos questions en direct.

Vous ne serez pas disponible ? Pas d’inquiétude, ce webinar sera également disponible en replay.

Apple décale de 6 mois son calendrier pour la réduction de la durée des certificats SSL/TLS

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

Le 17 octobre 2024, nous vous annoncions la décision d’Apple de réduire progressivement la durée maximale des certificats SSL/TLS publics à 45 jours d’ici 2027.

De nouveaux éléments ont été partagés depuis à ce sujet avec une nouvelle annonce d’Apple de décaler son calendrier, en le reculant de 6 mois avec pour nouvel objectif, des certificats désormais de 47 jours en mars 2028 :

  • 15-mar-2026 => durées certificats et validation DCV réduites à 200 jours
  • 15-mar-2027 => durées certificats et validation DCV réduites à 100 jours
  • 15-mar-2028 => durée certificats réduite à 47 jours
  • 15-mar-2028 => durée de validation DCV : 10 jours

Le CA/B Forum a quant à lui pris le sujet en main le 24 novembre, notamment dans le but de commencer à organiser comment gérer les commentaires publics.

Nameshield continue à suivre l’actualité et communiquera régulièrement sur le sujet.

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

Qu’est-ce que la validation étendue (EV, ou Extended Validation) et quelle est son importance ?

Cybersécurité - Certificat SSL EV - Blog Nameshield

Les certificats SSL assurent le chiffrement et l’intégrité des données échangées entre un navigateur et un serveur web. Il existe différents niveaux de certificats, Extended Validation (EV), Organizational Validation (OV) et Domain Validation (DV), qui varient en fonction du degré d’authentification. Le certificat SSL de type Extended Validation fournit le plus haut niveau d’authentification SSL. Son obtention passe par un processus de vérification d’identité complet et normalisé à l’échelle mondiale ratifié par le forum CA/Browser Forum.

Le certificat SSL EV active la sécurité HTTPS et le cadenas, maintenant gris, dans la barre d’adresse du navigateur, tout comme les certificats DV et OV. Le coût et le temps supplémentaires consacrés à la vérification rendent plus difficile l’obtention de certificats de niveau EV pour les sites de phishing. Les internautes peuvent donc utiliser ce certificat comme marque de confiance et se sentent plus en sécurité lorsqu’ils communiquent et effectuent des achats.

Le 12 juin 2007, le CA/Browser Forum ratifie officiellement la première version des directives SSL Extended Validation qui entrent en vigueur immédiatement. L’approbation formelle clôture alors avec succès plus de deux ans d’efforts et fournit un cadre pour l’identité de site Web afin d’accroitre la confiance sur Internet.

La plupart des principaux navigateurs créent des indicateurs visuels pour les pages chargées via HTTPS et sécurisées par un certificat EV peu après la création de la norme : ils affichent l’identité validée, soit une combinaison du nom de l’organisation et de la juridiction, dans la barre URL. Safari pour iOS, Windows Phone, Firefox pour Android, Chrome pour Android et iOS, ajoutent également ces indicateurs.

En mai 2018, Google annonce son intention de repenser les interfaces utilisateur de Google Chrome afin de ne plus mettre l’accent sur les certificats EV. Chrome 77, sorti en 2019, supprime l’indication du certificat EV de l’omnibox. Firefox 70 fait de même et retire la distinction dans la barre d’URL : les certificats EV et DV sont affichés de la même manière, mais le statut du certificat EV peut toujours être consulté en cliquant sur l’icône cadenas, puis en vérifiant le nom de l’entité légale sous « certificat ».

Certificat SSL EV - Nameshield

Affichage d’un certificat EV dans Firefox

L’utilisation croissante des appareils mobiles et la suppression de l’indicateur visuel EV par les navigateurs a fait diminuer de manière significative l’intérêt de certaines entités à utiliser ce niveau de sécurité, mais l’EV a toujours une très grande importance dans notre quotidien.

Aujourd’hui les sites de phishing représentent malheureusement toujours une menace majeure pour les sites web et services en ligne légitimes. Ces « hameçonneurs » utilisent des certificats DV, généralement obtenus auprès d’un service SSL gratuit qui ne mène pas de contrôles de phishing adéquats, afin que leurs sites paraissent plus fiables. Ils trompent ainsi facilement les victimes peu méfiantes et les incitent à communiquer des informations financières ou personnelles.

Il a été remarqué une très forte hausse du phishing depuis Mars 2020, début du confinement et du télétravail pour beaucoup de personnes : le volume des sites de phishing a augmenté de 47 % pour le premier trimestre de 2020, et 82,7% des attaques de phishing ont utilisé des certificats SSL DV. Ce problème ne fait que s’accroitre et accentue la nécessité de vérifier les identités en ligne.

Source de l’image : TheDigitalArtist via Pixabay



Nouvelle fiche « 5 minutes pour comprendre : Les certificats SSL / TLS »

Fiche 5 minutes pour comprendre : les certificats SSL / TLS - Nameshield

Un certificat SSL ou TLS authentifie un serveur et chiffre les données échangées avec celui-ci. Les données sont ainsi échangées en confiance, entre deux acteurs dont l’identité est connue. Les données échangées ne peuvent être espionnées ni altérées par un tiers : confidentialité et intégrité.

Téléchargez cette fiche « 5 minutes pour comprendre : les certificats SSL / TLS » depuis notre page ressources.

lire la fiche

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:// ?

HTTPS:// : La Chine n’aime pas la confidentialité et bloque l’extension ESNI

HTTPS:// : la Chine n’aime pas la confidentialité et bloque l'extension ESNI
Source de l’image : HealthWyze via Pixabay

Selon un rapport conjoint d’iYouPort, de l’Université du Maryland et du Great Firewall Report, les connexions TLS utilisant l’extension préliminaire SNI chiffrée (ESNI) sont bloquées en Chine. Un nouveau pas vers la censure et une volonté de pouvoir tracker les internautes.

Qu’est-ce que le SNI (Server Name Indication) ?

Lorsqu’un internaute consulte un site web en HTTPS://, cela signifie que le site est sécurisé par un certificat SSL/TLS. La consultation du site web commence par l’établissement de la connexion sécurisée, le « handshake ». Cette poignée de main se déroule en plusieurs étapes et vise à vérifier le certificat et établir le niveau de chiffrement de la connexion. Le premier message d’un handshake TLS est appelé « client hello ». Avec ce message, le client demande à voir le certificat TLS du serveur web. Le serveur doit joindre le certificat à sa réponse.

Présenter le bon certificat ne pose aucun problème dans le cas d’hébergements dédiés : une adresse IP, un seul certificat, contenant éventuellement plusieurs SAN (Subject Alternative Name) appartenant à la même organisation. Le problème intervient lors d’hébergements mutualisés où l’hébergeur dispose de la même adresse IP mais souhaite installer plusieurs certificats différents sous peine de devoir être le propriétaire du certificat en ajoutant des SAN pour tous ses clients. Pratique peu recommandée.

Le SNI répond à cette demande spécifique des hébergeurs et leurs hébergements mutualisés. Avec le protocole SNI, le client indique le nom de l’hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Cela permet au serveur de présenter plusieurs certificats pour la même adresse IP (mais des noms d’hôte différents). Le SNI pourrait être comparé au numéro d’appartement d’une adresse postale : un immeuble comprend plusieurs appartements, et chaque appartement doit donc être identifié par un numéro différent. De même, si le serveur est indiqué par l’adresse IP, les appareils clients doivent intégrer le SNI dans leur premier message adressé au serveur pour indiquer quel site web (quel appartement) ils essaient d’atteindre.

Qu’est-ce que l’ESNI (Encrypted Server Name Indication) ?

L’établissement d’une connexion TLS chiffrée commence à la fin du handshake. Problème, le SNI n’est donc pas chiffré, car le message « client hello » est envoyé au début du handshake TLS. Un pirate peut reconstituer le parcours d’un internaute en lisant la partie SNI du handshake, même s’il n’est pas en mesure de déchiffrer les communications ultérieures. Le principal intérêt pour le pirate étant de pouvoir flouer l’internaute en créant un site de phishing. Par ailleurs, les géants du web aiment la confidentialité, et souhaitent préserver la confidentialité des données de navigation des utilisateurs. L’ESNI est donc né.

L’ESNI (Encrypted server name indication) chiffre la partie Server Name Indication (SNI) dans le handshake TLS. L’extension ESNI est accessible via la dernière version du protocole TLS, 1.3, de plus en plus largement adopté aujourd’hui. Le principe est de récupérer une clé de chiffrement via le DNS (qui lui-même peut être sécurisé via DNS via HTTPS). Encore à l’état de draft, certains gros hébergeurs l’implémentent déjà.

Et la Chine dans tout ça ?

Dans leur rapport, l’iYouPort, l’Université du Maryland et le Great Firewall Report, détaillent comment la Chine voit d’un très mauvais œil le chiffrement du handshake. Cela empêche effectivement l’outil de surveillance Great Firewall du gouvernement chinois de voir ce que font les internautes en ligne. La Chine a donc décidé de purement et simplement bloquer les connexions HTTPS établies via la dernière version du protocole TLS (la 1.3) associées à ESNI. De plus, les adresses IP impliquées dans la connexion sont bloquées temporairement pendant deux à trois minutes.

Des méthodes de contournement existent… mais jusqu’à quand ?

Les trois organisations semblent avoir trouvé des méthodes de contournement à appliquer côté client (dans les applications et les logiciels) ou côté serveur pour contourner le blocage actuel mis en place par le Great Firewall. « Malheureusement, ces stratégies spécifiques ne constituent peut-être pas une solution à long terme : à mesure que le jeu du chat et de la souris progresse, le Great Firewall continuera probablement à améliorer ses capacités de censure », écrivent les trois organisations dans leur rapport.