Votre trafic web, vos emails et de nombreuses applications clés de l’entreprise dépendent de certains de vos noms de domaine. Ce sont vos noms de domaine stratégiques. La moindre indisponibilité prive d’accès vos clients et utilisateurs avec des conséquences dramatiques : image de marque, perte de données, de clients ou de chiffre d’affaires.
Ces noms de domaine attisent malheureusement les convoitises et leur surface d’attaque est importante. Ils sont exposés d’une part à des risques administratifs, tels que les tentatives d’usurpation d’accès, et d’autre part à des risques techniques, tels que les attaques DDoS visant l’infrastructure DNS, le DNS Cache poisoning ou le DNS spoofing.
Il est indispensable de garantir leur intégrité et leur disponibilité, les surveiller, les analyser et être alerté en cas d’attaque.
Pour répondre à ces impératifs, Nameshield a créé le Bastion DNS : service unique de protection, de surveillance et d’alerte. Facile à mettre en place, complet et économique, c’est LA solution de référence du marché pour protéger vos noms de domaine stratégiques.
En avril 2020, Nameshield publiait un article sur le choix d’un TLD en mettant en lumière la notion de performance des DNS comme critère supplémentaire aux impératifs marketing classiques tels que la marque, la disponibilité, l’homonymie, la langue… Le choix du nom de domaine qui sera porteur de la communication de l’entreprise et soutiendra sa présence sur Internet, est primordial.
Depuis 2020, le COVID est passé par là, augmentant de manière significative notre dépendance aux réseaux et accroissant fortement les activités en ligne. Bien sûr cette dépendance attise les convoitises et la cybercriminalité a suivi la tendance avec une hausse significative du nombre et des types d’attaques, notamment sur les noms de domaine.
Le métier de Nameshield est de gérer les noms de domaine de ses clients et notamment de garantir la disponibilité des noms de domaine stratégiques en fournissant l’ensemble des éléments de sécurité nécessaires. Ces noms de domaine sont particulièrement exposés, leur surface d’attaque est importante et les protéger demande une expertise particulière car ils doivent rester disponibles en permanence et sont la porte d’entrée vers tous les services clés de l’entreprise.
Deux éléments indispensables : Registry lock et DNSSEC
Parmi ces éléments, deux sont indispensables : le Registry lock pour se prémunir de toute tentative de compromission des accès (DNS Hijacking) et DNSSEC pour se prémunir des attaques de type Man in the middle (DNS Spoofing, DNS Cache Poisoning ou Side channel Attack DNS).
Le premier cité est la première recommandation de l’ANSSI en matière de résilience du DNS ; le second est l’objet de nombreuses communications de la part de l’ICANN pour augmenter la sécurité des noms de domaine et fait également partie des préconisations de l’ANSSI.
Ces deux options de sécurité ne devraient pas en être et nous ne saurions que recommander leur activation.
Des TLD sans registry lock et d’autres TLD défaillants sur DNSSEC
Et c’est bien ici que nous souhaitons attirer votre attention et compléter notre article de 2020 sur le choix du TLD à mettre derrière votre marque pour votre nom de domaine principal.
Choisissez un TLD qui propose ces options de sécurité… et qui sait les gérer !
Le site IANIX.com publie une liste des incidents majeurs liés à DNSSEC impactant de nombreux noms de domaine en même temps. La présence de nombreux registres, et pas des moindres, est à souligner car les noms de domaine en sont directement dépendants :
.se — Sweden (February 2022)
.au — Australia (March 2022)
.mx — Mexico (April 2023)
.nz — New Zealand (May 2023)
.ve — Venezuela (July 2023)
De nombreux sites ont communiqué sur les trois incidents récents au Mexique, Nouvelle Zélande et Venezuela. Indépendamment des causes de la rupture de chaine de confiance DNSSEC dans ces registres, ce qui pose question c’est la durée de ces interruptions, de plusieurs heures à plusieurs jours, et l’impossibilité pour les noms de domaine victimes de pouvoir intervenir.
Tous les TLD ne proposent pas DNSSEC, la gestion est complexe et les conséquences immédiatement dramatiques. De même, tous les TLD ne proposent pas la mise en place du Registry lock, essentiellement pour des raisons de complexités administratives et de coûts induits.
Ces deux options de sécurité n’en deviennent pas moins indispensables. Tout d’abord pour la protection face aux attaques mentionnées plus haut, mais aussi par l’avènement des sociétés d’assurance en risque cyber, qui s’appuient sur des sociétés d’audit afin de définir les montants de garanties ou les prix de leurs primes. Parmi les éléments de sécurité regardés de plus en plus près : le nom de domaine stratégique et ses options de sécurité DNSSEC et Registy lock.
Conclusion : choisir son TLD en prenant en compte ces options
La conclusion de notre article de 2020 conseillait, dans la mesure des possibilités marketing et business, de prendre en compte les impératifs de performance des TLD… la conclusion d’aujourd’hui pourrait être exactement la même, en y ajoutant les besoins de Registry lock et DNSSEC. Le choix n’est pas forcément aisé, l’impératif de sécurité est parfois loin des impératifs business. Pour autant, dans la mesure du possible, pensez-y…
BIMI (Brand Indicators for Message Identification) permet d’authentifier vos emails et de renforcer la confiance de vos clients en affichant votre logo dans leur boîte de réception. VMC (Verified Mark Certificate) est un certificat associé à BIMI, garantissant l’authenticité du logo affiché.
Qu’est-ce que BIMI?
BIMI est une initiative de l’industrie visant à normaliser l’utilisation et l’affichage des logos des marques dans les clients de messagerie. En plaçant le logo d’une marque ou d’une entreprise à côté d’un e-mail, celui-ci est plus facilement identifiable par les clients et les utilisateurs, installe un sentiment de légitimité et de confiance, impacte significativement les taux d’ouverture et augmente la protection des consommateurs contre les e-mails frauduleux.
Techniquement parlant, BIMI est une technologie de sécurité émergente qui fonctionne en complément des protocoles DKIM, SPF et DMARC pour protéger votre nom de domaine contre l’utilisation par des acteurs malveillants pour envoyer des e-mails frauduleux.
Avant BIMI, les étapes pour faire apparaître votre logo à côté d’un e-mail étaient spécifiques à chaque service de messagerie auquel votre message était envoyé. Parfois, le processus était entièrement manuel ou s’appuyait sur d’autres applications pour agréger les informations de votre marque et les partager sur les plateformes participantes.
Le groupe AuthIndicators, qui comprend des fournisseurs de services de messagerie tels que Google, Verizon Media, IONOS by 1&1 et Fastmail, travaille à la mise en œuvre de BIMI dans les clients de messagerie les plus courants. De nombreux acteurs ont déjà adopté BIMI, d’autres sont en cours, les positions de Microsoft et d’Apple sont attendues pour faire définitivement adopter ce standard.
Pourquoi BIMI est important ?
Pour compléter l’arsenal de protection d’une marque sur Internet, plus particulièrement contre les tentatives de détournement via des e-mails frauduleux de type spoofing dont le but est de tromper l’utilisateur et de l’amener vers des sites de phishing.
.
306 Milliards d’e-mails ont circulé en 2020 dans le monde, avec une proportion toujours croissante de mails frauduleux détournant des marques.
Pour augmenter la désidérabilité des e-mails, notamment dans les campagnes marketing. L’implémentation de BIMI et plus largement des protocoles et certificats de sécurité sur le nom de domaine associé à une marque est indispensable aujourd’hui et a un impact majeur sur la réputation en ligne.
Parce que c’est en train de devenir un standard du marché, simple à mettre en place contrairement au nombre de solutions de lutte contre les e-mails frauduleux existantes, souvent difficiles à tester et à mettre en œuvre.
Comment BIMI fonctionne ?
BIMI utilise un processus en plusieurs étapes pour valider les e-mails en s’assurant qu’ils sont réellement associés au nom de domaine de l’expéditeur. Les expéditeurs doivent ajouter un enregistrement DNS de type TXT dédié à BIMI.
Pour que BIMI fonctionne, les noms de domaine doivent également disposer de plusieurs autres protections contre la fraude, notamment :
SPF (Sender Policy Framework) : authentifie les e-mails en identifiant les serveurs de messagerie autorisés à envoyer à partir de noms de domaine spécifiques ;
DKIM (DomainKeys Identified Mail) : ajoute une signature numérique à chaque e-mail pour vérifier qu’il a été envoyé depuis un nom de domaine autorisé ;
DMARC (Domain-Based Message Authentication, Reporting, and Conformance) : confirme les enregistrements SPF et DKIM et spécifie comment les e-mails non conformes doivent être traités.
Lorsque des e-mails sont envoyés en utilisant BIMI, le serveur de messagerie de réception effectuera d’abord l’authentification DMARC/DKIM standard et la validation SPF. Si l’e-mail passe ces vérifications, le serveur de messagerie vérifiera s’il a un enregistrement BIMI valide et affichera le logo de la marque.
Comment BIMI interagit-il avec DMARC, DKIM et SPF ?
La première étape vers l’utilisation de BIMI pour afficher un logo consiste à mettre en œuvre DMARC. Ceci est stocké en tant qu’enregistrement DNS de type TXT sur le nom de domaine. Pour que DMARC fonctionne avec BIMI, la politique de rejet dans cet enregistrement doit être p=quarantine ou p=reject pour tous les e-mails envoyés depuis votre domaine.
BIMI nécessite DMARC… et DMARC nécessite que votre nom de domaine ait des enregistrements DKIM pour fonctionner. Si DMARC ne nécessite que SPF ou DKIM pour fonctionner, il est cependant préférable d’inclure des enregistrements SPF pour plus de sécurité lors de l’utilisation de BIMI. Ces 2 outils de sécurité sont également stockés sous forme d’enregistrements DNS TXT dans la zone du nom de domaine.
VMC, le dernier maillon de la chaîne
Un Verified Mark Certificate (ou « certificat de marque vérifié ») est un certificat numérique qui authentifie la propriété d’un logo, et qui vient compléter l’utilisation de BIMI dans les clients de messagerie tels que Gmail.
Le certificat VMC garantit l’authenticité du logo affiché, nécessairement propriété du titulaire du nom de domaine envoyant l’e-mail. C’est le dernier maillon de la chaîne pour garantir l’authenticité du mail reçu.
Lorsque vous envoyez un e-mail à un contact, le serveur de messagerie destinataire qui gère sa boîte de réception prendra l’URL de la balise qui indique où le logo doit être affiché. Il vérifiera ensuite le certificat VMC pour s’assurer que le bon logo est utilisé. Une fois le logo vérifié par le VMC, BIMI l’affichera à côté de l’e-mail dans la boîte de réception.
Pour obtenir un certificat VMC, l’implémentation de DMARC sur le nom de domaine est un prérequis. S’ensuit alors un processus d’authentification renforcé auprès d’une Autorité de Certification qui validera l’identité de l’Organisation, l’enregistrement du logo auprès d’un organisme certifié et délivrera le certificat à la suite d’un one to one devant un notaire.
Selon les pays, les offices d’enregistrement des logos peuvent varier ainsi que les règles d’acceptation pour émettre le certificat. Les notions à garder en tête, les marques déposées autorisées peuvent être :
Marques de dessins : composées uniquement d’un dessin ;
Marques verbales : contiennent des mots, des lettres et/ou des chiffres, sans police, taille, couleur ou style particulier ;
Marques combinées : inclure une combinaison de mots avec un dessin, des lettres stylisées ou des chiffres.
Bien que ce ne soit pas une exigence pour la mise en œuvre de BIMI sur votre nom de domaine pour le moment, VMC devrait faire partie de la norme à l’avenir.
Entrust Datacard et DigiCert sont les 2 premières sociétés à délivrer des certificats VMC pour la norme BIMI. Nameshield est partenaire des deux sociétés et vous accompagne pour l’obtention de certificats VMC. Vous pouvez contacter directement notre service certificats pour toute question sur le sujet.
BIMI + VMC = Garantie d’authenticité
BIMI, VMC… et Nameshield
Nameshield accompagne désormais ses clients sur tous les aspects de la mise en place des protocoles DMARC, SPF, DKIM, mais aussi BIMI et l’obtention des certificats VMC associés. Le nom de domaine est au cœur de la mise en place de ces différents protocoles. Notre métier historique de registrar et de gestionnaire de zones DNS nous permet aujourd’hui d’accompagner nos clients sur ces sujets majeurs de la lutte contre la fraude en ligne et d’augmentation de la désidérabilité des e-mails.
Le nom de domaine vitemadose.fr a été racheté par des anti vaccins. N’y allez pas. Diffusez le plus largement possible la bonne adresse http://vitemadose.covidtracker.fr et rien d’autre ! »
C’est par ce tweet que Guillaume Rozier, fondateur de Vite Ma Dose et CovidTracker, alerte sur le détournement de trafic dont il estime que son application phare est victime au profit du CRIIGEN.
Nameshield ne souhaite pas analyser le contenu de cette affaire, de l’eau a déjà coulé sous les ponts entre le 3 avril, date de l’enregistrement des noms de domaine vitemadose.fr et vitemadose.com, le 22 avril, date de lancement de vitemadose.covidtracker.fr, et aujourd’hui où le CRIIGEN a mis son communiqué de presse AFP directement sur le site pour clarifier les choses.
Notre propos est d’alerter, ou rappeler, à nos clients et lecteurs de l’importance du nom de domaine dans la communication de type évènementiel, le lancement d’un nouveau projet, la création d’une nouvelle marque ou un changement de dénomination sociale.
En 2000 Vivendi versait 24 millions de Francs pour protéger Vizzavi.com
« 24 MILLIONS de francs pour un nom ! C’est en effet la somme que vient de verser le groupe Vivendi aux trois responsables du cybercafé parisien Vis-à-Vis… »
C’était en juillet 2000, Vivendi lançait en grande pompe son tout nouveau portail, mais en ayant oublié de vérifier la disponibilité du nom de domaine. On peut encore trouver sur la toile des articles en rapport avec cette affaire (ici article du Parisien). C’était il y a plus de 20 ans ! De nombreux cas similaires illustrent depuis la petite histoire des noms de domaine jusqu’à vitemadose.fr.
Guillaume Rozier n’est certainement pas un spécialiste des noms de domaine, qui plus est nous vivons dans un monde d’applications aujourd’hui, et il n’avait certainement pas en tête le risque de détournement de ce qu’il estime à n’en pas douter être une juste cause, mais le résultat est là, à devoir établir une communication post incident pour essayer de réparer les pots cassés.
Nous le dirons, conseillerons, répèterons jamais assez, anticipez l’importance du nom de domaine dans la communication. Faites systématiquement un point sur le nom à utiliser. Est-ce que vous le détenez ? Est-ce que vous le contrôlez ? Quelle extension utiliser ? Quelle(s) extension(s) secondaire(s) protéger (.com/.fr… nouvelles extensions) ? Quelle(s) variation(s) enregistrer (vite-ma-dose.fr) ?
A défaut, faites-vous conseiller pour éviter de réagir dans l’urgence. Des professionnels tels que les équipes de Nameshield sont également là pour vous aider à définir la bonne stratégie de nommage, de défense et de surveillance pour bien protéger votre territoire numérique.
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 *.
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.
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.
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.
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.
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.
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.
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.
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 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.
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é
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.
Nameshield utilise des cookies
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience🍪.
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience. Plus d'informations dans notre politique de cookies 🍪.
Ces cookies sont essentiels au bon fonctionnement du site web. Ils assurent les fonctionnalités de base et les fonctions de sécurité du site web, de manière anonyme.
Cookie
Durée
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-functional
1 year
The cookie is set by the GDPR Cookie Consent plugin to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
Ces cookies aident à réaliser certaines fonctionnalités comme le partage du contenu du site web sur les plateformes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités de tiers.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Ces cookies sont utilisés pour comprendre comment vous arrivez sur notre Site et pour mesurer le nombre de visiteurs.
Cookie
Durée
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
Ces cookies sont utilisés pour vous proposer des offres et services personnalisés, plus adaptés à vos centres d’intérêts.
Cookie
Durée
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
