Présentation des paramètres TLS par nom d'hôte – une sécurité adaptée à vos besoins

L'un des objectifs de Cloudflare est de fournir à nos clients les commandes indispensables pour déployer une approche de la sécurité qui corresponde à leurs besoins. Dans le domaine des protocoles SSL/TLS, nous proposons deux contrôles essentiels : la définition de la version minimale de TLS et la restriction de la liste des suites de chiffrement prises en charge. Auparavant, ces paramètres étaient appliqués à l'ensemble d'un domaine, avec un effet de type « tout ou rien ». Si l'uniformisation des paramètres sur l'ensemble d'un domaine est idéale pour certains utilisateurs, elle n'offre pas toujours la granularité nécessaire lorsque différents sous-domaines comportent différents besoins.

C'est pourquoi nous sommes heureux d'annoncer qu'à partir d'aujourd'hui, les clients pourront configurer leurs paramètres TLS par nom d'hôte.

Dans un monde idéal, chaque domaine pourrait être mis à jour afin d'utiliser les protocoles les plus sûrs et les plus modernes, sans entraîner d'inconvénients ;malheureusement, toutefois, ce n'est pas le cas. Pour être efficaces, les nouveaux protocoles et normes doivent être adoptés. La norme TLS 1.3 a été normalisée par l'IETF en avril 2018 ;son adoption permettait l'élimination des algorithmes cryptographiques vulnérables pris en charge par TLS 1.2 et offrait une amélioration des performances, puisqu'elle ne nécessitait qu'un aller-retour unique, au lieu de deux. Pour qu'un utilisateur puisse tirer parti du protocole TLS 1.3, son navigateur ou son appareil doit prendre en charge la nouvelle version de TLS. Pour les navigateurs et les appareils modernes, cette exigence ne constitue pas un problème : ces systèmes d'exploitation sont conçus pour se mettre à jour de manière dynamique, afin de prendre en charge les nouveaux protocoles. Les clients et appareils « historiques », cependant, n'ont évidemment pas été conçus dans la même optique. Avant 2015, le développement de nouveaux protocoles et normes s'étalait sur des décennies, plutôt que sur des mois ou des années ; les clients offraient donc la prise en charge d'une norme unique, c'est-à-dire celle qui était utilisée à l'époque.

Si nous examinons les données de Cloudflare Radar, nous pouvons constater qu'environ 62,9 % du trafic utilise TLS 1.3. C'est un chiffre considérable, pour un protocole normalisé il y a cinq ans seulement ; cependant, cela signifie également qu'une grande partie de l'Internet continue d'utiliser TLS 1.2, voire une version antérieure.

Le même compromis s'applique aux algorithmes de chiffrement. ECDSA a été normalisé en 2005, environ 20 ans après RSA ;il offre un niveau de sécurité supérieur à RSA, et utilise des longueurs de clés plus courtes, améliorant ainsi les performances associées à chaque requête. Pour utiliser ECDSA, un propriétaire de domaine doit obtenir et servir un certificat ECDSA, et le client qui se connecte au domaine doit prendre en charge les suites de chiffrement utilisant la cryptographie sur les courbes elliptiques (ECC). Bien que la plupart des autorités de certification publiquement reconnues prennent désormais en charge les certificats basés sur ECDSA, en raison de la lenteur de l'adoption de cet algorithme, de nombreux systèmes anciens prennent uniquement en charge l'algorithme RSA. Par conséquent, faire le choix de proposer uniquement la prise en charge d'algorithmes basés sur ECC dans les applications comporte le risque d'empêcher l'accès à celles-ci par les utilisateurs de clients et d'appareils plus anciens.

Lorsqu'il s'agit de sécurité et d'accessibilité, il est important de permettre aux entreprises de parvenir à un point d'équilibre.

Pour préserver leur image de marque, la plupart des entreprises déploient toutes leurs ressources sous un domaine unique. Il est courant que le domaine racine (par exemple, exemple.com) soit utilisé comme site web de marketing, afin de fournir des informations sur l'entreprise, sa mission et les produits et services qu'elle propose. Ensuite, sous le même domaine, les entreprises peuvent publier leur blog (par exemple, blog.exemple.com), leur portail de gestion (par exemple,portail.exemple.com), et leur passerelle API (par exemple, api.exemple.com).

Le site web de marketing et le blog sont similaires, en ce sens qu'il s'agit de sites statiques, qui ne collectent pas d'informations sur les utilisateurs qui y accèdent.En revanche, le portail de gestion et la passerelle API collectent et présentent des données sensibles, qui doivent être protégées.

Lorsque vous réfléchissez aux paramètres que vous souhaitez mettre en œuvre, vous devez tenir compte de la nature des données échangées, ainsi que de la base d'utilisateurs. Le site web de marketing et le blog doivent être accessibles à tous les utilisateurs. Vous pouvez les configurer de manière à assurer la prise en charge des protocoles modernes pour les clients compatibles ; en revanche, vous n'avez pas nécessairement d'intérêt à restreindre l'accès des utilisateurs qui consultent ces pages depuis des appareils anciens.

La configuration du portail de gestion et de la passerelle API doit assurer la meilleure protection possible des données échangées. Cette exigence nécessite de renoncer à la prise en charge de normes moins sûres, comportant des vulnérabilités connues, et d'imposer l'utilisation de nouveaux protocoles sécurisés.

Pour mettre en œuvre cette configuration, vous devez pouvoir configurer individuellement les paramètres de chaque sous-domaine de votre domaine.

Les clients qui utilisent le service Advanced Certificate Manager de Cloudflare peuvent configurer les paramètres TLS pour des noms d'hôtes individuels au sein d'un domaine. Les clients peuvent utiliser ce service pour activer HTTP/2 ou pour configurer la version minimale du protocole TLS, ainsi que les suites de chiffrement prises en charge pour un nom d'hôte particulier. Tous les paramètres appliqués à un nom d'hôte particulier remplacent les paramètres au niveau de la zone. Cette nouvelle fonctionnalité permet également de configurer différents paramètres pour un nom d'hôte et l'enregistrement générique correspondant, vous permettant ainsi de configurer exemple.com avec un paramètre et *.exemple.com avec un autre.

Supposons que vous souhaitiez que la version minimale par défaut de TLS utilisée pour votre domaine soit TLS 1.2, mais que vous souhaitiez définir la version minimale de TLS sur TLS 1.3 pour votre tableau de bord et les sous-domaines associés à votre API. Depuis le tableau de bord de Cloudflare, vous pouvez définir la version minimale de TLS de la zone sur 1.2, comme indiqué ci-dessous. Ensuite, pour définir la version minimale de TLS pour le tableau de bord et les sous-domaines associés à votre API sur TLS 1.3, configurez un appel au point de terminaison d'API des paramètres TLS par nom d'hôte avec le nom d'hôte et la configuration spécifiques.

Ce service est disponible dès aujourd'hui via le point de terminaison d'API ! Et si vous souhaitez en savoir plus sur l'utilisation des paramètres TLS par nom d'hôte, veuillez consulter notre documentation pour développeurs.