Vers une nouvelle génération de protocoles plus respectueux de la confidentialité

Au cours des dix dernières années, Cloudflare a occupé une place prépondérante de l'infrastructure d'Internet, accompagnant les sites Web, les API et les services Web afin de les rendre plus sûrs et plus efficaces. Le développement d'Internet ne concerne pas uniquement sa capacité et le nombre d'utilisateurs, ce sont également la conception et la fonctionnalité qui évoluent. Cloudflare étant un acteur de l'écosystème d'Internet, il est tenu de contribuer à ce qu'Internet se développe dans le respect des utilisateurs tout en leur offrant de la valeur. Aujourd'hui, nous annonçons plusieurs nouveautés conçues pour améliorer les protocoles Internet dans ce qu'il y a de plus important pour nos clients et les utilisateurs d'Internet du monde entier : la confidentialité

Il s'agit des initiatives suivantes :

• Résoudre l'un des derniers problèmes de fuite d'informations dans HTTPS grâce à Encrypted Client Hello (ECH), auparavant appelé SNI chiffré

• Renforcer la confidentialité du service DNS en adoptant le protocole ODoH (Oblivious DNS-over-HTTPS)

• Développer un protocole plus abouti pour l'authentification par mot de passe, OPAQUE, qui rendra les violations de mot de passe plus rares.

Chacun de ces projets concerne un aspect d'Internet ayant une incidence sur nos activités en ligne et sur notre empreinte numérique. Que nous en soyons conscients ou non, il circule un grand nombre d'informations confidentielles à propos de nous et de notre vie sur Internet. C'est là que nous avons un rôle à jouer.

Depuis plus d'un an, nous œuvrons dans le cadre d'organismes de normalisation tels que l'IETF et travaillons en partenariat avec les plus grands noms de la technologie Internet (dont Mozilla, Google, Equinix, etc.) pour concevoir, déployer et tester ces nouveaux protocoles respectueux de la confidentialité à l'échelle d'Internet. Ces trois protocoles portent chacun sur un aspect crucial de nos activités en ligne et nous comptons sur eux pour améliorer de manière significative la confidentialité en ligne à mesure que les utilisateurs l'adopteront.

Au cœur des missions qu'elle s'est fixées, l'entreprise Cloudflare s'est engagée à soutenir et développer une technologie qui contribue à améliorer Internet à la faveur de nombreuses initiatives. Dans notre secteur, nous avons réalisé des progrès exceptionnels pour ce qui est de rendre Internet plus sûr et plus fiable. Cloudflare est fière d'avoir joué un rôle dans cette évolution grâce à de multiples initiatives au fil des ans.

Voici quelques points importants :

• Universal SSL™. Nous avons été l'une des chevilles ouvrières du chiffrement sur le Web. Avec le lancement d'Universal SSL en 2014 nous avons offert à nos clients le chiffrement de site Web et nous avons collaboré activement avec des autorités de certification telles que Let’s Encrypt, des navigateurs Web et des opérateurs de site Web dans le but de supprimer le contenu mixte. Avant que nous ne lancions Universal SSL™ qui nous a permis de mettre HTTPS gratuitement à disposition de tous les clients Cloudflare, seules 30 % des connexions à des sites Web étaient chiffrées. Grâce aux efforts déployés dans ce secteur, ce nombre est aujourd'hui de 80 % et cela représente une proportion encore plus importante du trafic Internet global. Parallèlement à notre contribution au chiffrement du Web, nous avons soutenu le projet de transparence des certificats par le biais de Nimbus et Merkle Town, c'est ce qui a permis d'améliorer la responsabilité de l'écosystème de certificats sur laquelle HTTPS fait reposer la confiance.

• TLS 1.3 et QUIC. Nous avons également été très activement partie prenante dans le renforcement des protocoles de sécurité existants. Citons l'exemple du protocole TLS (Transport Layer Security), qui sous-tend et sécurise HTTPS. Les ingénieurs de Cloudflare ont participé à la conception de TLS 1.3, la dernière version de la norme, et en 2016 nous prenions en charge la première version du protocole. Ce déploiement dès la version initiale a permis d'apporter des améliorations jusqu'à la version finale du protocole. TLS 1.3 est maintenant le protocole de chiffrement le plus utilisé sur le Web et il s'agit d'un élément clé de la récente norme QUIC, que nous avons été parmi les premiers à adopter.

• Sécurisation du routage, de l'attribution de noms et de l'heure. Nous avons consacré de solides efforts à la sécurisation d'autres composants essentiels d'Internet. Notre contribution à la sécurisation du routage Internet grâce à notre boîte à outils ICPR, à notre étude de mesure et à notre outil de « Is BGP Safe Yet » a considérablement renforcé la résilience d'Internet devant les fuites susceptibles de perturber le routage. Notre service de temps (time.cloudflare.com) a permis de synchroniser les horloges des internautes avec des protocoles plus sécurisés tels que NTS et Roughtime. Nous avons également renforcé la sécurité du DNS en adoptant les protocoles DNS-over-HTTPS et DNS-over-TLS dans la version 1.1.1.1 au lancement, et l'activation du DNSSEC en un clic dans notre serveur d'inscription et notre service DNS faisant autorité.

Il est extrêmement important pour la croissance d'Internet de poursuivre l'intensification de la sécurité des systèmes de confiance en ligne. Cependant, un principe de conception encore plus fondamental est en jeu : le respect. L'infrastructure qui sous-tend Internet doit être conçue de manière à respecter ses utilisateurs.

Lorsque vous vous connectez à un site Web ou à un service spécifique régi par une politique de confidentialité, vous savez ce que le site est censé faire de vos données. Il s'agit d'une mesure explicite. Il n'existe aucun accord de ce type entre les utilisateurs et les opérateurs d'Internet. Vous pouvez avoir conclu un accord avec votre fournisseur d'accès Internet (FAI) et le site que vous visitez, mais il est très peu probable que vous sachiez ne serait-ce que le nom des réseaux que vos données traversent. La plupart des gens n'ont aucune idée de ce que représente Internet au-delà de leur écran, il est donc difficile d'imaginer que les gens accepteraient ou encore comprendraient ne serait-ce que le sens de la politique de confidentialité d'un grossiste en transit ou d'un boîtier intermédiaire d'inspection.

Sans chiffrement, les informations concernant votre navigation sur Internet sont transmises de manière implicite à d'innombrables tiers en ligne à mesure que les informations circulent parmi les réseaux. Sans routage sécurisé, le trafic des utilisateurs peut être détourné et perturbé. Sans protocole visant à préserver la confidentialité, les activités en ligne des utilisateurs ne sont pas aussi confidentielles qu'ils pourraient le penser ou le souhaiter. L'infrastructure d'Internet n'a pas été conçue conformément à leurs attentes.

Diagramme de la circulation parmi les réseaux, avec ou sans fuites.

La bonne nouvelle c'est qu'Internet n'en finit jamais d'évoluer. L'IAB (Internet Architecture Board (IAB) fait partie des groupes qui orientent cette évolution, il assure la surveillance architecturale pour l'IETF (Internet Engineering Task Force), le principal organisme de normalisation d'Internet. L'IAB a récemment publié le document RFC 8890, qui explique à quel point les utilisateurs finaux doivent être une priorité lorsqu'il s'agit de concevoir des protocoles Internet. Il y est précisé qu'en cas de conflit entre les intérêts des utilisateurs finaux et ceux des fournisseurs de services, des entreprises ou des gouvernements, les décisions de l'IETF doivent favoriser les utilisateurs finaux. Un des intérêts majeurs des utilisateurs finaux est le droit à la confidentialité et c'est dans le but de préciser combien les protocoles Internet doivent prendre en compte la confidentialité que l'IAB a publié le document RFC 6973.

Les articles publiés aujourd'hui sur le blog technique concernent les améliorations apportées à Internet dans le but de respecter la confidentialité de l'utilisateur. La confidentialité est un sujet complexe qui touche à de multiples disciplines, il est donc important d'expliquer avec précision ce que l'on entend par « améliorer la confidentialité ». Il s'agit concrètement de modifier les protocoles concernés par la manipulation d'informations confidentielles qui se retrouvent désormais exposées « en ligne », et de faire en sorte que ces informations ne soient visibles que pour un minimum d'acteurs. Ces données continuent d'exister, simplement elles ne sont plus disponibles ni visibles pour les tiers sans la mise en place d'un mécanisme chargé de les collecter à une couche plus élevée, la couche d'application. Ces modifications vont bien au-delà du chiffrement d'un site Web ; il s'agit de transformer en profondeur la conception même des systèmes qui font d'Internet ce qu'il est.

Le chiffrement et les proxys sécurisés sont deux outils qui permettent de garantir l'invisibilité des données utilisées.

La cryptographie convertit les informations dans un format que seul un nombre très limité de personnes (celles qui disposent de la clé) peuvent comprendre. Pour certains, la cryptographie est un outil qui transforme les problèmes de sécurité des données en problèmes de gestion de clés. C'est une vision assez juste de la réalité Avec la cryptographie, il est également plus facile d'envisager la confidentialité si les données ne sont visibles que pour ceux qui disposent de la clé.

Un autre outil permet de protéger l'accès aux données, il s'agit de la segmentation/isolation. En limitant physiquement les parties ayant accès aux données, vous construisez efficacement des frontières de confidentialité. Il est courant que des architectures reposent sur des proxys tenant compte d'une politique précise pour la transmission des données d'un endroit vers un autre. Ces proxys peuvent être configurés de façon à éliminer les données sensibles ou à bloquer les transferts de données entre les parties, selon ce que prévoit la politique de confidentialité.

Ces deux outils sont efficaces individuellement, mais ils le sont encore plus lorsqu'ils sont utilisés conjointement. Le routage en oignon (la technique cryptographique sur laquelle repose Tor) est un exemple de la façon dont les proxys et le chiffrement peuvent être utilisés de concert pour faire appliquer une confidentialité rigoureuse. Dans les grandes lignes, si la partie A souhaite envoyer des données à la partie B, elle peut chiffrer les données avec la clé de la partie B et chiffrer les métadonnées avec la clé d'un proxy et les envoyer au proxy.

Les plates-formes et les services qui évoluent sur Internet peuvent intégrer des mécanismes liés au consentement, tels que des politiques de confidentialité affichées dans les interfaces utilisateur. L'infrastructure d'Internet repose sur des couches de protocoles sous-jacents. Jusqu'à présent, ces couches d'Internet se trouvent au-dessous de la zone d'interaction de l'utilisateur, c'est pourquoi il est quasiment impossible de mettre en place un véritable recueil de consentement de l'utilisateur. Afin de respecter les utilisateurs et de les protéger de tout risque lié à la confidentialité, les protocoles qui assurent la cohésion d'Internet doivent être conçus avec une fonction de confidentialité activée par défaut

La transition d'un site Web majoritairement non chiffré vers un site Web chiffré a fait beaucoup pour la confidentialité de l'utilisateur final. Par exemple, le « coffeeshop stalker » n'est plus un problème pour la plupart des sites. Pour la majorité des sites auxquels ils accèdent en ligne, les utilisateurs n'affichent plus chacun des aspects de leur navigation sur le Web (qu'il s'agisse des requêtes de recherche, de la version du navigateur utilisé, de l'authentification, des cookies, etc.) de manière visible pour quiconque se trouve sur le chemin. Si un site est correctement configuré pour l'utilisation de HTTPS, les utilisateurs ont la garantie que leurs données sont à l'abri des indiscrets et ne parviennent qu'au lecteur souhaité, car leurs connexions sont à la fois chiffrées et authentifiées.

Toutefois, le HTTPS ne protège que le contenu des requêtes sur le Web. Même si vous vous contentez de naviguer sur des sites HTTPS, cela ne signifie pas que votre parcours de navigation est confidentiel. En effet, il est un élément essentiel de l'échange que HTTPS ne parvient pas à chiffrer : les métadonnées. Lorsque vous passez un appel téléphonique, les métadonnées correspondent au numéro de téléphone, et non au contenu de l'appel. Les métadonnées sont les données relatives aux données.

Pour illustrer la différence et souligner en quoi c'est important, voici un diagramme de ce qui se passe lorsque vous consultez un site Web tel qu'un tableau avec des images. Supposons que vous accédiez à une page spécifique de ce tableau (https://.com/room101/) dans laquelle sont intégrées des images hébergées sur <sitegênant>.com.

L'espace à l'intérieur de la ligne pointillée représente la partie d'Internet dont vos données ont besoin pour transiter. Il s'agit de votre réseau local ou de celui du café, de votre fournisseur d'accès à Internet, d'un fournisseur de transit Internet et la partie réseau du fournisseur de cloud qui héberge le serveur peut également apparaître. Souvent, les utilisateurs n'ont aucun lien avec ces entités, ni de contrat qui empêcherait ces parties de faire quoi que ce soit avec les données utilisateur. Et même si ces entités ne regardent pas les données, un observateur bien placé qui intercepterait le trafic Internet est en mesure de voir tout ce qui est envoyé sans être chiffré. L'idéal serait que ces entités ne puissent tout simplement pas les voir. Dans cet exemple, n'importe quel observateur peut voir que l'utilisateur a consulté .com, c'est prévu ainsi. Cependant, bien que le contenu de la page soit chiffré, il est toujours possible de savoir quelle page en particulier vous avez consultée dans la mesure où l'adresse <sitegênant>.com est également visible.

En règle générale, si des données sont disponibles sur Internet, elles risquent d'être utilisées par certaines des parties qui les croiseront. Il est également exact que ces parties ont besoin de certaines métadonnées pour faciliter le transport de ces données. Cet équilibre est présenté dans le document RFC 8558, il y est expliqué comment la conception de ces protocoles doit garantir un équilibre scrupuleux entre l'excès de métadonnées (dangereux pour la confidentialité) et l'insuffisance de métadonnées (potentiellement néfaste pour le fonctionnement).

Dans une situation idéale, les protocoles Internet appliqueraient le principe du moindre privilège. Ils fourniraient la quantité minimale d'informations nécessaires aux acteurs du transport de données pour jouer leur rôle, à savoir acheminer les données au bon endroit tout en gardant le reste confidentiel par défaut. Les protocoles actuels, notamment TLS 1.3 et QUIC, illustrent une avancée importante vers cet idéal, mais ils ne sont pas à la hauteur en ce qui concerne la confidentialité des métadonnées.

Les annonces effectuées aujourd'hui concernent deux niveaux de protection des métadonnées : la première implique de limiter la quantité de métadonnées mises à disposition des observateurs tiers (tels que les FAI), et la seconde implique de limiter la quantité de métadonnées que les utilisateurs communiquent eux-mêmes aux fournisseurs de services.

Les noms d'hôtes sont un exemple de métadonnées qui doivent être protégées des observateurs tiers, c'est l'objectif de DoH et d'ECH. Cependant, il n'est pas logique de cacher le nom d'hôte du site que vous consultez. Il n'est pas non plus logique de le masquer dans un service d'annuaire comme DNS. Un serveur DNS doit connaître le nom d'hôte que vous résolvez pour le résoudre pour vous!

Il se produit un problème de confidentialité lorsqu'un fournisseur de services connaît à la fois les sites que vous visitez et votre identité. Les sites Web individuels ne disposent pas de cette combinaison d'informations à risque (sauf dans le cas de cookies tiers, qui bientôt n'existeront plus dans les navigateurs), mais les fournisseurs DNS si. Heureusement, un résolveur DNS n'a pas besoin de connaître *à la fois* le nom d'hôte du service que vous allez utiliser et l'adresse IP d'où vous émettez la demande. Le fait de séparer les deux éléments,  ce qui est l'objectif d'ODoH, est une bonne chose pour la confidentialité.

Les routes doivent être bien pavées, bien éclairées, présenter une signalisation précise et être reliées de façon optimale. Elles n'ont pas vocation à arrêter une voiture en fonction de qui s'y trouve. Et c'est heureux ! Comme c'est le cas pour toute infrastructure de transport, il incombe à l'infrastructure d'Internet la responsabilité de conduire les données là où elles doivent aller, mais pas d'en examiner le contenu ni d'émettre un avis à leur sujet. Mais Internet est fait d'ordinateurs et de logiciels, et les logiciels ont tendance à être écrits pour prendre des décisions basées sur les données dont ils disposent.

Les protocoles destinés à préserver la confidentialité tentent de juguler la tentation que pourraient avoir les fournisseurs d'infrastructures et autres intervenants de jeter un coup d'œil à l'intérieur et de prendre des décisions sur la base de données personnelles. Dans le cas d'un protocole ne préservant pas la confidentialité, c'est le cas de HTTP, les données et les métadonnées telles que les mots de passe, les adresses IP et les noms d'hôte sont conservées comme des éléments explicites des données envoyées à travers le réseau. Le fait qu'elles soient considérées comme explicites implique que n'importe quel observateur peut les recueillir et s'en servir. Un protocole tel que HTTPS résout ce problème en rendant certaines des données (telles que les mots de passe et le contenu du site) invisibles sur le réseau lui-même à l'aide du chiffrement.

Les trois protocoles que nous examinons aujourd'hui sont un prolongement de ce concept.

• ECH prend la plupart des métadonnées non chiffrées dans TLS (y compris le nom d'hôte) et les chiffre avec une clé qui a été récupérée au préalable.

• ODoH (une nouvelle variante de DoH fruit d'une collaboration des ingénieurs d'Apple et Cloudflare) utilise des proxys et un chiffrement en oignon pour rendre la source d'une requête DNS invisible au résolveur DNS. L'adresse IP personnelle de l'utilisateur est ainsi protégée lors de la résolution des noms d'hôte.

• OPAQUE utilise une nouvelle technique cryptographique pour rendre les mots de passe masqués même pour le serveur. En s'appuyant sur une construction appelée fonction pseudo-aléatoire inconsciente (comme on peut l'observer dans Privacy Pass), le serveur ne prend pas connaissance du mot de passe, seul lui importe que l'utilisateur connaisse ou non le mot de passe.

En garantissant que l'infrastructure Internet agit plutôt comme une infrastructure concrète, la confidentialité de l'utilisateur est plus facilement protégée. Internet est plus confidentiel si les données confidentielles ne peuvent être collectées que lorsque l'utilisateur a la possibilité d'y consentir.

Aussi enthousiastes soyons-nous à l'idée de réfléchir à de nouvelles façons de rendre Internet plus respectueux de la confidentialité, ce n'est pas en travaillant dans le vide que nous ferons progresser l'innovation à l'échelle mondiale. Chacun de ces projets est le fruit de la collaboration d'un ensemble de personnes provenant d'organisations telles que l'IETF et l'IRTF. Il est primordial que les protocoles naissent d'un processus de consensus impliquant toutes les parties qui forment l'ensemble interconnecté de systèmes sur lequel repose Internet. Des concepteurs de navigateurs aux cryptographes, en passant par les opérateurs DNS et les administrateurs de sites Web, il s'agit d'un véritable travail d'équipe à l'échelle mondiale.

Nous sommes également conscients de ce que tout changement technique radical apporté à l'internet aura inévitablement des répercussions au-delà de la communauté technique. L'adoption de ces nouveaux protocoles peut avoir des implications juridiques et politiques. Nous sommes actifs auprès des gouvernements et des groupes de la société civile pour leur faire comprendre l'incidence de ces changements potentiels.

Nous sommes impatients de dévoiler notre travail aujourd'hui et espérons que d'autres seront intéressés et se joindront à nous pour la mise au point de ces protocoles. Les projets que nous annonçons aujourd'hui ont été pensés par un ensemble d'experts du milieu universitaire, de l'industrie et de passionnés et ont été conçus par des ingénieurs de Cloudflare Research (y compris des stagiaires, dont nous soulignerons le travail) avec le soutien de tout le monde chez Cloudflare.

Si vous ce type de travail vous intéresse, nous recrutons!