Auteur/autrice : Christophe Gérard

CPO - Nameshield Group

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.

L’importance du reverse DNS

DNS inversé - Reverse DNS
Source de l’image : Jonbonsilver via Pixabay

Le DNS inversé (ou reverse DNS) est souvent méconnu des gestionnaires de noms de domaine, en particulier quand les noms sont hébergés par de grandes sociétés d’hébergement. Le DNS inversé permet de faire une résolution depuis une adresse IP vers un FQDN. C’est l’exact opposé de l’utilisation classique du DNS qui fait correspondre des noms de domaine avec des adresses IP. Le reverse DNS permet de répondre à la question : j’ai une adresse IP, quel est le FQDN qui s’y rapporte ?

Le reverse DNS fonctionne via la création d’une zone DNS reverse dans laquelle des enregistrements DNS PTR (pour Pointer Record) vont être configurés.

  • DNS classique : Record A : on connaît le nom d’un site et on souhaite récupérer son adresse IP…
  • DNS inversé PTR : on connaît une adresse IP et on souhaite récupérer le nom du site.  

Le système de résolution se construit de manière similaire à la résolution classique. Pour opérer la résolution DNS, l’adresse IP à interroger est configurée dans la zone reverse avec le suffixe .arpa et pointe vers la destination requise. Le principe est le même pour les adresses IP v4 et v6 selon la construction suivante :

Ex: IPv4 : 11.80.92.81.in-addr.arpa. IN PTR capp.perf1.com.

Ex: IPv6 : 0.0.0.0.0.0.0.0.0.1.0.1.0.0.0.0.0.8.c.0.0.1.0.a.2.ip6.arpa. 4080 IN PTR capp.perf1.com.

Cette construction permet d’opérer une résolution DNS classique sur un nom de domaine avec une extension «.arpa».

Pourquoi est-ce si important ?

Le DNS inversé est principalement utilisé pour le suivi de la provenance d’un visiteur du site Web, de l’origine d’un message électronique, etc. Il n’est généralement pas aussi critique que le DNS classique, les visiteurs atteindront le site Web même sans la présence de DNS inversé pour l’IP du serveur Web ou l’IP du visiteur.

Cependant, le DNS inversé est important pour une application particulière : la messagerie.

De nombreux serveurs de messagerie sur Internet sont en effet configurés pour rejeter les e-mails entrants provenant de toute adresse IP qui n’a pas de DNS inversé. Pour celui qui gère son propre serveur de messagerie, le DNS inversé doit exister pour l’adresse IP à partir de laquelle le courrier électronique sortant est envoyé.

Peu importe l’adresse vers laquelle pointe l’enregistrement DNS inversé de l’adresse IP, un enregistrement reverse est attendu. Dans le cas d’hébergement de plusieurs domaines sur un même serveur de messagerie, il suffit de configurer le DNS inversé pour pointer vers le nom de domaine considéré comme principal (Les serveurs de messagerie vérifiant le DNS inversé reconnaissent qu’il est normal d’héberger de nombreux domaines sur une seule adresse IP et qu’il serait impossible de répertorier tous ces domaines dans le DNS inversé pour l’IP).

Nous vous recommandons de vérifier la possibilité de paramétrer un DNS inversé auprès de votre solution d’hébergement DNS.

Bien choisir son TLD en fonction des performances DNS

Analyse comparative des domaines de premier niveau, les fameux Top Level Domains (.com, .fr…)

Le nerf de la guerre des sites web à forte visibilité est le temps de téléchargement. Facteur de référencement naturel admis par Google, ce temps de téléchargement peut être impacté significativement lors de la résolution DNS. S’il convient de s’appuyer sur une infrastructure DNS de premier ordre, le choix de l’extension associée à un nom de domaine a son importance. En effet, les registres ne sont pas tous aussi performants les uns que les autres en matière de DNS, pour ne pas dire que certains affichent des performances décevantes. L’offre en matière de TLD (près de 1400) a largement augmenté depuis le programme des nouvelles extensions de l’ICANN. Analyse à suivre.

Petit retour sur le temps de résolution DNS et son impact sur le temps de chargement

La résolution d’un domaine tel que nameshield.net suit plusieurs étapes avant de pouvoir contacter le serveur de contenu. Le résolveur DNS contacte les serveurs DNS racines (.), puis les serveurs DNS du registre de l’extension concernée (.net) afin d’obtenir la liste des serveurs DNS responsables du domaine, et enfin ces serveurs DNS pour obtenir la réponse demandée. La réponse obtenue est certes mise en cache par le DNS résolveur (généralement géré par le FAI), mais ce ne sera pas toujours le cas en fonction de la popularité de votre domaine.

Cela signifie que si le DNS du domaine de premier niveau (.net) est lent, il peut en fait retarder la résolution DNS pour le domaine lui-même et, dans le pire des cas très improbable, même provoquer une panne. Vous ne pouvez pas y faire grand-chose à part bien choisir le fameux TLD.

Hiérachie DNS - Choisir son TLD en fonction des performances DNS - Nameshield

Analyse comparative

Bunny CDN, un acteur slovène de la livraison de contenu a mené la surprenante analyse suivante. S’appuyant sur leur réseau mondial, ils ont surveillé les performances DNS dans le monde entier à partir de plus de 50 sites et réseaux.

Pour chaque domaine de premier niveau, leur système a choisi un serveur de noms aléatoire publié pour chacun des domaines de premier niveau et a interrogé un nom de domaine également aléatoire. Les résultats ont été groupés par région et les données enregistrées toutes les 10 secondes.

Résultats

Ils ont testé 42 des domaines de premier niveau les plus populaires, puis agrégé les résultats en une moyenne médiane mondiale et une agrégation à 85 centiles (les 15% de réponses les plus lentes n’ont pas été prises en compte). Ces tests ont été effectués uniquement à partir de leur réseau, une étude plus complète mériterait certainement d’être menée, mais ils offrent un bon aperçu général.

TLD - DNS resolution time - Choisir son TLD en fonction des performances DNS
Source : BunnyCDN

Des résultats ont été assez surprenants

Les domaines les plus étonnants concernent les .info et .org qui ont montré des performances vraiment médiocres, en particulier dans la plage de 85 centiles, et ce malgré leur ancienneté et les millions de domaines enregistrés. Il semble que 4 des 6 serveurs de noms fonctionnent extrêmement mal, ce qui explique les mauvais résultats.

Le .net et le .com ont été très légèrement plus lents qu’attendu en Europe et en Amérique du Nord, mais offrent par ailleurs des performances excellentes et stables dans toutes les régions, visibles dans la médiane mondiale. Le .net et le .com ont des réseaux beaucoup plus grands, mais restent un choix très intéressant pour obtenir les performances maximales absolues.

Moins attendue, la performance des TLD .co, .biz et .in, bien en avance sur les autres.

Certains nouveaux domaines (.online, .top, .blog…) attirants sur le plan marketing et en forte croissance, montrent des performances décevantes…

… à l’inverse de très bonnes surprises pour .live, .email, .news, gérés par Donuts Inc ou encore .club et .buzz gérés par Neustar Inc, avec cependant une très forte baisse des performances dans des régions en dehors de l’Europe et de l’Amérique du Nord, ce qui aggrave encore le problème.

42 TLD parmi les plus populaires des 1400+ disponibles ont été testés. Sans tirer de conclusion définitive, nous pouvons supposer que beaucoup pourraient ne pas fonctionner beaucoup mieux.

Conclusion

Faut-il révolutionner la gestion de votre portefeuille de noms de domaine et le choix des TLD pour vos sites les plus visibles ? Faut-il tout passer en .biz ou en .co immédiatement pour augmenter les performances ?

Certainement pas. Tout d’abord, les réponses DNS sont fortement mises en cache, en particulier pour les sites Web très populaires, les résolveurs peuvent ne pas avoir besoin de toucher beaucoup de serveurs de noms de niveau supérieur. Ensuite, le choix d’un nom de domaine répond avant tout à des impératifs marketing (marque, zone géographique, disponibilité du nom) souvent bien plus impactants que les 50 millisecondes supplémentaires de temps de chargement pour le chargement de la première page.

Cependant, si vous essayez de comprimer absolument tous les derniers bits de performances et d’assurer une grande fiabilité dans un système où chaque dernière milliseconde compte, alors vous voudrez peut-être réfléchir à deux fois avant de choisir votre domaine. Les différences ne sont pas énormes, mais si vous visez à atteindre ce temps de chargement d’une seconde, les choses s’accumulent, dans certains cas, jusqu’à 200 ms.

Bien choisir son TLD en fonction des performances DNS certes, mais probablement pas de quoi s’en inquiéter trop.

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.