SVCB/HTTPS : de nouveaux enregistrements DNS

SVCB/HTTPS : de nouveaux enregistrements DNS

Deux types nouveaux

Le DNS, système de noms de domaine, est un service essentiel au fonctionnement d’Internet. Il est souvent présenté comme un annuaire permettant d’associer des noms de domaine à des adresses IP, mais c’est en réalité qu’une petite partie de ses fonctions.

Les enregistrements DNS de types A et AAAA permettent en effet de configurer des adresses IP derrière un nom de domaine. Il existe également des dizaines d’autres types d’enregistrements DNS, utiles pour divers cas d’usage.

Deux nouveaux types d’enregistrement DNS vont prochainement être introduits par une nouvelle RFC : les types SVCB et HTTPS.

Faciliter les services et réduire la latence

Type SVCB

Le type SVCB, pour SerViCe Binding, a pour objectif d’indiquer des informations utiles sur les services disponibles avec un nom de domaine. Le format de l’enregistrement SVCB est composé d’une priorité, d’une cible et d’une liste de paramètres optionnelle. Par exemple, il permet d’indiquer que pour un service défini, un nom de domaine est en fait lié à un autre nom avec une configuration spécifique.

SVCB [SvcPriority] [TargetName] ([SvcParams]…)

Les enregistrements SVCB se différencient des SRV sur plusieurs points :

  • Les enregistrements SRV sont généralement obligatoires pour qu’un service fonctionne ; ce n’est pas le cas avec les SVCB.
  • Les enregistrements SVCB peuvent indiquer plus d’informations que les SRV, comme une version de protocole à utiliser.
  • Le type SVCB est extensible, contrairement aux SRV, ce qui ouvre la porte à diverses évolutions et usages futurs.

Type HTTPS

Le type HTTPS est un type dérivé de SVCB. Contrairement au type SVCB qui est générique, le type HTTPS est spécifique au protocole HTTPS.

Généralement, pour initier une connexion HTTPS, le client doit d’abord se connecter en HTTP afin de récupérer plusieurs informations, par exemple pour savoir quelle version utiliser ; cela génère de la latence.

L’enregistrement DNS de type HTTPS permet notamment d’indiquer au client, différents paramètres afin de faciliter la connexion au serveur, et ainsi réduire la latence. Il a la même forme qu’un enregistrement SVCB :

HTTPS [SvcPriority] [TargetName] ([SvcParams]…)

Mode alias

Les enregistrements SVCB/HTTPS proposent deux modes de fonctionnement. Un mode alias et un mode service.

Le mode alias est activé lorsque la priorité est positionnée à 0. Il permet de rediriger un nom de domaine vers un autre nom, et notamment de résoudre le fameux problème du CNAME à la racine (CNAME-at-apex).

L’enregistrement CNAME permet d’indiquer qu’un sous-domaine renvoie vers un autre nom de domaine. Il est très utile pour déléguer un service : par exemple pour faire pointer le nom www.exemple.fr vers le site web hébergé chez monsite.presta.fr.

www CNAME monsite.presta.fr

Le problème avec l’enregistrement CNAME, c’est qu’il ne peut pas être défini à la racine d’un nom. Pour contourner ce problème, des solutions non-standards sont proposées comme les enregistrements ALIAS ou ANAME, mais ces types ne sont pas supportés par tous les opérateurs DNS. Le mode alias des enregistrements SVCB/HTTPS est une solution à ce problème.

SVCB 0 nameshield.net.

HTTPS 0 nameshield.net.

Mode service

Le mode service des enregistrements SVCB/HTTPS permet d’indiquer quels services sont configurés derrière un nom de domaine. Lors de la découverte de service, cela fournit au client un certain nombre de paramètres condensés dans un seul enregistrement DNS. L’objectif est de faciliter l’utilisation de services et diminuer la latence.

Par exemple, nous pouvons avoir un enregistrement HTTPS indiquant que le client peut se connecter avec le protocole HTTP/2 ou HTTP/3 (alpn) aux adresses IPv4 et IPv6 définies (ipv4hint, ipv6hint), sur le port 8061 (port).

HTTPS 1 . alpn=”h3,h2” ipv4hint=”192.168.0.1” ipv6hint=”2001:db8::1” port=8061

Déploiement en cours

Les enregistrements SVCB/HTTPS apportent plusieurs fonctionnalités afin d’améliorer les performances du Web et répondre à la problématique du CNAME à la racine. Le fait qu’ils soient génériques et évolutifs permet d’élargir le périmètre des cas d’usage.

Bien qu’ils ne soient pas encore normés par une RFC, ces nouveaux types d’enregistrement sont déjà utilisés. Certains logiciels DNS et navigateurs Web supportent ces enregistrements, et des acteurs comme Apple, Google, Cloudflare et Nameshield les implémentent déjà.

Aujourd’hui, les services fonctionnant avec des enregistrements SVCB/HTTPS doivent également pouvoir s’en passer, car leur déploiement n’est pas encore généralisé. C’est une étape qui peut prendre plusieurs mois, le temps que la majorité des opérateurs se mettent à jour.

Source de l’image : TheDigitalArtist via Pixabay

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

Certficats SSL TLS - HTTPS

Que se passe-t-il ?

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

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

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

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

Qui est touché ?

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

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

Qu’en pensent les acteurs du marché ?

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

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

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

La position des fabricants de navigateurs ?  

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

L’avis de Nameshield

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

Être entendu

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

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

Webinar Cybersécurité Nameshield - SSL HTTPS - Replay

Le navigateur Chrome représente entre 62% et 68% de parts de marché mondial. Alors, quand en 2016 Chrome a annoncé son intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter !

Depuis juillet 2018, avec l’arrivée de Chrome 68, les sites en HTTP sont considérés comme « Non Sécurisé », ceux en HTTPS sont marqués « Sécurisé » dans la barre d’adresse.

Et depuis le 25 mai 2018, le RGPD est entré en vigueur et les sites qui récoltent des données personnelles doivent disposer du HTTPS.

De plus, certains nouveaux gestionnaires de noms de domaine imposent également le HTTPS pour pouvoir utiliser le nom de domaine (.app / .dev…).

Passer au HTTPS par défaut sur l’ensemble de vos sites Web est devenu indispensable, en faisant l’acquisition de certificat(s) SSL et permet de bénéficier de différents avantages.

Au programme de ce webinar, nos experts reviennent sur :

  • Qu’est-ce qu’un certificat SSL ?
  • Quels sont les avantages et les risques liés aux certificats SSL ?
  • Quelle stratégie adopter pour vos sites web ?

Retrouvez ce webinar animé par Christophe GERARD, Security Product Manager et Lucie LOOS, Directrice Marketing Experte cybersécurité de Nameshield group, en replay sur la plateforme Webikeo :

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

Le navigateur Chrome représente en octobre 2018, selon les sources et toutes plateformes confondues, entre 62% et 68% de parts de marché mondial. Une croissance d’une régularité implacable depuis le lancement du navigateur qui en fait aujourd’hui un acteur incontournable du web. Alors, quand le 8 septembre 2016, les équipes de développement de Chrome annoncèrent leur intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter.

HTTP not secure

L’objectif de Google était d’avertir simplement, et donc visuellement, l’internaute qu’une page en HTTP n’était pas sûre, d’autant plus pour les pages avec saisies de données à caractère personnel (login, mot de passe, informations personnelles, numéro de carte de crédit) :

” We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. The goal of this proposal is to more clearly display to users that HTTP provides no data security. ”

Un peu plus de deux ans et 17 versions du navigateur plus tard, le temps d’une transition graduée pour un peu plus de douceur, et Google est arrivé à ses fins avec une adoption massive du protocole HTTPS ;  la quasi-totalité des autres navigateurs, Firefox en-tête, ayant suivi la même évolution.

Retour sur l’évolution des indicateurs de sécurité dans Chrome depuis 2 ans :

  1. HTTP not secureSeptembre 2016 – Chrome 53 : le HTTP est la norme, et en dehors de certaines erreurs de sécurité liées à un défaut de la page (notamment lié aux certificats SSL), aucun indicateur particulier concernant le manque de sécurité
  2. Janvier 2017 – Chrome 56 : pour commencer, Chrome met l’accent sur les pages contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit. Firefox s’aligne immédiatement.
  3. Octobre 2017 – Chrome 62 : Google avance vers un test grandeur nature du traitement de l’ensemble des pages HTTP considéré comme non sécurisé avec le lancement en mode « Chrome Incognito » de l’indicateur HTTP « Not secure » au lancement de la page, quel que soit son contenu
  4. Juillet 2018 – Chrome 68 : toute page chargée en HTTP, quel que soit son contenu, quel que soit le mode de navigation, est désormais considéré comme « not secure »
  5. Septembre 2018 – Chrome 69 : pour Google, HTTPS est désormais la norme. La prochaine étape, pour le moins controversée, consiste à éventuellement faire disparaître le cadenas de sécurité tant apprécié des internautes.HTTP not securePour beaucoup c’est un sérieux pas en arrière, il faudra suivre de près cette évolution et penser à mettre en place des certificats SSL Extended Validation EV, qui pour l’instant ne sont pas remis en cause par Google.Validation EV
  6. Octobre 2018 – Chrome 70 : c’est maintenant !Chrome 70Désormais, l’affichage des pages HTTP contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit, est barré d’un indicateur non sécurisé et pour la  première fois de couleur rouge. Les autres pages HTTP sont indiquées non sécurisées en gris. Les pages HTTPS classiques avec un cadenas noir et celles avec un certificat EV affichent en plus le nom de la société… vous suivez ?
    1. Date non définie – Chrome XX : la finalité de Google est la dualité sur le traitement des urls avec HTTPS ouvertement affichés en rouge pour alerter l’internaute et le HTTPS considéré comme normal, donc ne bénéficiant plus d’aucun indicateur « positif » :

Certificats SSL

  1. HTTP à la CorbeilleDate non définie – Chrome YY : toujours dans une optique d’augmentation de la sécurité et de protection des identités, Google a dans ses cartons une réflexion en cours sur la fin du système d’url tel que nous le connaissons aujourd’hui… Pour le remplacer par un système nouveau et plus simple, affaire à suivre…

D’ici là, et si cette réflexion n’a pas encore été menée au sein de votre entreprise, il est grand temps de passer l’ensemble de vos sites web et applications en HTTPS. La réflexion doit également comprendre le fait d’insérer le nom de votre entreprise dans la barre d’adresse des navigateurs, au moins sur les sites vitrine et à fort trafic.