Mise à jour de l'accès au réseau privé: lancement d'un essai d'abandon

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo
GitHub

régulières

  • 23 mars 2023: le calendrier a été mis à jour, et l'abandon ne se produira que dans Chrome 117.

  • 19 janvier 2023: le calendrier a été mis à jour, et l'abandon n'aura lieu que dans Chrome 114.

  • 12 août 2022: le calendrier a été mis à jour, et l'abandon n'aura lieu que dans Chrome 109.

  • 10 février 2022: publication d'un article mis à jour sur la page Accès au réseau privé: présentation des vérifications préliminaires

  • 25 août 2021: mise à jour du calendrier et lancement d'un essai d'abandon.

Chrome abandonne l'accès aux points de terminaison du réseau privé pour les sites Web non sécurisés, conformément à la spécification d'accès au réseau privé. L'objectif est de protéger les utilisateurs contre les attaques par falsification de requête intersites (CSRF) ciblant les routeurs et d'autres appareils sur des réseaux privés. Ces attaques ont touché des centaines de milliers d'utilisateurs, permettant ainsi à des pirates informatiques de les rediriger vers des serveurs malveillants.

Chrome introduit les modifications suivantes:

  • Blocage des requêtes adressées à des réseaux privés depuis des sites Web publics non sécurisés à partir de Chrome 94
  • Lancement d'un essai avant arrêt qui se terminera dans Chrome
    1. Elle permettra aux développeurs de demander un délai supplémentaire pour les origines choisies, qui ne seront pas affectées pendant l'essai d'abandon.
  • Introduction d'une règle Chrome permettant aux déploiements Chrome gérés d'ignorer définitivement l'abandon. Disponible dans Chrome 92.

Si vous avez besoin de plus de temps pour atténuer l'impact de l'abandon, inscrivez-vous pour l'essai d'abandon.

Si vous exercez un contrôle administratif sur vos utilisateurs, vous pouvez réactiver la fonctionnalité à l'aide de règles Chrome.

Pour atténuer l'impact des nouvelles restrictions, utilisez l'une des stratégies suivantes:

Chronologie

  • Novembre 2020: appel aux commentaires sur les changements à venir.
  • Mars 2021: après avoir examiné les commentaires et effectué une communication, les changements à venir sont annoncés. La spécification CORS-RFC1918 a été renommée "Accès au réseau privé".
  • Avril 2021: déploiement de la version stable de Chrome 90 dans la version stable, affichant des avertissements d'abandon.
  • Juin 2021: Chrome 92 est déployé en version bêta, interdisant les requêtes de réseau privé provenant de contextes non sécurisés. Suite aux commentaires des développeurs demandant plus de temps pour s'adapter, l'abandon est reporté à Chrome 93, accompagné d'un essai d'abandon.
  • Juillet 2021: suite aux commentaires supplémentaires des développeurs, l'abandon et l'essai associé sont reportés à Chrome 94. De plus, les sites Web privés ne sont plus concernés par l'abandon.
  • Août 2021: déploiement de la version bêta de Chrome 94. Les développeurs Web peuvent commencer à s'inscrire à l'évaluation avant arrêt.
  • Septembre 2021: déploiement de la version stable de Chrome 94. Les développeurs Web doivent s'être inscrits à l'évaluation avant arrêt et avoir déployé des jetons d'essai en production.
  • Décembre 2022: envoi de l'enquête sur la phase d'évaluation et commentaires reçus. L'essai d'abandon est étendu à Chrome 113.
  • Mars 2023: l'évaluation avant arrêt est étendue à Chrome 116 et devrait se terminer dans Chrome 117. Un autre mécanisme basé sur des autorisations est en cours de développement, ciblant la version initiale dans Chrome 114.
  • Mai 2023 (provisoire): déploiement du mécanisme basé sur les autorisations dans Chrome 114. Les sites Web peuvent l'utiliser pour mettre fin à l'évaluation avant arrêt.
  • Septembre 2023: Chrome 117 sera déployé en version stable, mettant fin à la période d'évaluation avant arrêt. Chrome bloque toutes les requêtes sur un réseau privé provenant de contextes publics non sécurisés.

Qu'est-ce que l'accès au réseau privé ?

L'accès au réseau privé (anciennement CORS-RFC1918) limite la capacité des sites Web à envoyer des requêtes à des serveurs sur des réseaux privés. Il n'autorise de telles requêtes qu'à partir de contextes sécurisés. La spécification étend également le protocole CORS (Cross-Origin Resource Sharing), de sorte que les sites Web doivent désormais demander explicitement une autorisation aux serveurs situés sur des réseaux privés avant d'être autorisés à envoyer des requêtes arbitraires.

Les requêtes de réseau privé sont des requêtes dont l'adresse IP du serveur cible est plus privée que celle à partir de laquelle l'initiateur de la requête a été récupéré. Par exemple, une requête provenant d'un site Web public (https://example.com) vers un site Web privé (http://router.local), ou une requête d'un site Web privé adressée à localhost.

Relation entre les réseaux publics, privés et locaux dans l'accès au réseau privé (CORS-RFC1918).
Relation entre les réseaux publics, privés et locaux dans l'accès au réseau privé (CORS-RFC1918).

Pour en savoir plus, consultez la page Commentaires sur le CORS pour les réseaux privés (RFC1918).

Qu'est-ce qu'un essai avec abandon

Les essais d'abandon (anciennement appelés "évaluations d'origine inversée") sont une forme d'évaluation permettant de faciliter l'abandon des fonctionnalités Web. Les essais d'abandon permettent à Chrome d'abandonner certaines fonctionnalités Web et d'empêcher les sites Web d'en créer de nouvelles dépendances, tout en laissant aux sites Web dépendants actuels plus de temps pour les supprimer.

Pendant un essai d'abandon, les fonctionnalités obsolètes ne sont pas disponibles par défaut pour tous les sites Web. Les développeurs qui doivent encore utiliser les fonctionnalités concernées doivent s'inscrire à l'évaluation avant arrêt et obtenir des jetons pour les origines Web spécifiées, puis modifier leur site Web pour diffuser ces jetons dans des en-têtes HTTP ou des balises Meta (sauf dans ce cas). Si un site Web diffuse des jetons valides correspondant à leur origine, Chrome autorise l'utilisation de cette fonctionnalité obsolète pendant une durée limitée.

Pour en savoir plus, consultez Premiers pas avec les phases d'évaluation de Chrome et le Guide du développeur Web sur les phases d'évaluation pour obtenir des instructions.

Ce qui change dans Chrome

Chrome 94

À partir de Chrome 94, les contextes publics non sécurisés (en général, les sites Web qui ne sont pas distribués via HTTPS ou à partir d'une adresse IP privée) sont interdits d'envoyer des requêtes au réseau privé. Cela était prévu pour Chrome 92. Par conséquent, les messages d'abandon peuvent encore mentionner l'étape précédente.

Cet abandon s'accompagne d'un essai d'abandon, qui permet aux développeurs Web dont les sites Web utilisent la fonctionnalité obsolète de continuer à l'utiliser jusqu'à Chrome 116 en s'inscrivant à des jetons. Consultez les instructions ci-dessous pour savoir comment vous inscrire et activer l'essai sur votre site Web.

Vous pouvez utiliser deux règles Chrome pour désactiver l'obsolescence entièrement ou pour des origines spécifiques, indéfiniment. Cela permet d'éviter les dysfonctionnements lors des installations Chrome gérées, par exemple dans un environnement d'entreprise.

Chrome 117

La période d'évaluation avant arrêt prend fin. Vous devez migrer tous les sites Web hors de la fonctionnalité obsolète ou configurer les règles de leurs utilisateurs pour continuer à activer la fonctionnalité.

Pour les sites Web concernés, il est probable que la première étape prenne un certain temps avant de pouvoir déployer un correctif approprié: soit en vous inscrivant à l'évaluation avant arrêt, soit en utilisant des règles. Ensuite, le plan d'action recommandé varie en fonction des circonstances de chaque site Web concerné.

S'inscrire à l'évaluation avant arrêt

  1. Cliquez sur Enregistrer pour la phase d'évaluation de l'accès au réseau privé depuis des contextes non sécurisés afin d'obtenir un jeton d'essai pour l'origine participante.
  2. Ajoutez le Origin-Trial: $token spécifique à l'origine dans l'en-tête de réponse. Cet en-tête de réponse ne doit être défini que sur les réponses de la ressource principale et de navigation lorsque le document résultant utilise la fonctionnalité obsolète. Il est inutile (bien que inoffensif) d'associer cet en-tête aux réponses de sous-ressources.

Étant donné que cet essai doit être activé ou désactivé avant qu'un document ne soit autorisé à envoyer des requêtes, il ne peut pas être activé via une balise <meta>. Ces tags ne sont analysés à partir du corps de la réponse qu'après l'émission des requêtes de sous-ressources. Cela représente un défi pour les sites Web qui ne contrôlent pas les en-têtes de réponse, tels que les sites Web statiques github.io diffusés par un tiers.

Pour en savoir plus, consultez le Guide du développeur Web sur les phases d'évaluation.

Activer les règles

Si vous exercez un contrôle administratif sur vos utilisateurs, vous pouvez réactiver la fonctionnalité obsolète à l'aide de l'une des règles suivantes:

Pour en savoir plus sur la gestion des règles pour vos utilisateurs, consultez cet article du Centre d'aide.

Accéder à localhost

Si votre site Web doit envoyer des requêtes à localhost, il vous suffit de passer à HTTPS.

Les requêtes ciblant http://localhost (ou http://127.*.*.*, http://[::1]) ne sont pas bloquées par le contenu mixte, même lorsqu'elles sont émises depuis des contextes sécurisés.

Notez que le moteur WebKit et les navigateurs basés sur celui-ci (notamment Safari) diffèrent de la spécification W3C relative au contenu mixte décrite ici et interdisent ces requêtes en tant que contenu mixte. De plus, ils ne mettent pas en œuvre l'accès au réseau privé. Les sites Web peuvent donc vouloir rediriger les clients utilisant ces navigateurs vers une version HTTP en texte brut du site Web, qui serait toujours autorisée par ces navigateurs à envoyer des requêtes à localhost.

Accéder à des adresses IP privées

Si votre site Web doit envoyer des requêtes à un serveur cible sur une adresse IP privée, la mise à niveau du site Web d'initiation vers HTTPS ne fonctionne pas. Le contenu mixte empêche les contextes sécurisés d'envoyer des requêtes via HTTP en texte brut. Par conséquent, le site Web nouvellement sécurisé se trouvera toujours dans l'incapacité d'envoyer les requêtes. Il existe plusieurs façons de résoudre ce problème:

  • Mise à niveau des deux extrémités vers HTTPS.
  • Utilisez WebTransport pour vous connecter en toute sécurité au serveur cible.
  • Inversez la relation d'intégration.

Mettre à niveau les deux extrémités en HTTPS

Cette solution nécessite de contrôler la résolution DNS des utilisateurs, comme dans les contextes intranet, ou si les utilisateurs obtiennent les adresses de leurs serveurs de noms à partir d'un serveur DHCP sous votre contrôle. Vous devez également posséder un nom de domaine public.

Le principal problème de diffusion de sites Web privés via HTTPS est que les autorités de certification d'infrastructure à clé publique (CA PKI) ne fournissent des certificats TLS qu'aux sites Web avec des noms de domaine publics. Pour contourner ce problème:

  1. Enregistrez un nom de domaine public (par exemple, intranet.example) et publiez des enregistrements DNS pointant ce nom de domaine vers un serveur public de votre choix.
  2. Obtenez un certificat TLS pour intranet.example.
  3. Dans votre réseau privé, configurez le DNS pour résoudre intranet.example sur l'adresse IP privée du serveur cible.
  4. Configurez votre serveur privé afin qu'il utilise le certificat TLS pour intranet.example. Cela permet à vos utilisateurs d'accéder au serveur privé à l'adresse https://intranet.example.

Vous pouvez ensuite mettre à niveau le site Web qui lance les requêtes vers HTTPS et continuer à les effectuer comme auparavant.

Cette solution est évolutive et réduit la confiance que vous accordez à votre réseau, en élargissant l'utilisation du chiffrement de bout en bout au sein de votre réseau privé.

WebTransport

Cette solution ne nécessite aucun contrôle sur la résolution DNS de vos utilisateurs. Il nécessite que le serveur cible exécute un serveur WebTransport minimal (serveur HTTP/3 avec quelques modifications).

Vous pouvez contourner l'absence de certificat TLS valide signé par une autorité de certification de confiance en utilisant WebTransport et son mécanisme d'épinglage de certificats. Cela permet d'établir des connexions sécurisées à des appareils privés pouvant disposer d'un certificat autosigné, par exemple. Les connexions WebTransport permettent un transfert de données bidirectionnel, mais pas les requêtes de récupération. Vous pouvez combiner cette approche avec un service worker pour relayer par proxy les requêtes HTTP de manière transparente sur la connexion, du point de vue de votre application Web. Du côté du serveur, une couche de traduction correspondante peut convertir les messages WebTransport en requêtes HTTP.

Nous sommes conscients que cela représente une charge de travail considérable, mais cela devrait être beaucoup plus facile que de s'appuyer sur WebRTC. Nous espérons également qu'une partie de l'investissement nécessaire sera implémentée en tant que bibliothèques réutilisables. Nous pensons également qu'il est particulièrement utile de tenir compte du fait que les contextes non sécurisés sont susceptibles de perdre l'accès à de plus en plus de fonctionnalités de la plate-forme Web à mesure que celle-ci s'efforce de renforcer l'utilisation du protocole HTTPS au fil du temps. Quel que soit l'accès au réseau privé, il s'agirait probablement d'un investissement judicieux.

WebTransport via HTTP/3 devrait être disponible dans Chrome 96 (une phase d'évaluation a commencé) avec des mesures d'atténuation pour vous protéger contre le partage de clés et d'autres pratiques de sécurité de niveau inférieur, telles que:

  • Délai d'expiration maximal court pour les certificats épinglés.
  • Mécanisme spécifique à un navigateur permettant de révoquer certaines clés ayant fait l'objet d'une utilisation abusive

Nous n'enverrons la restriction de contexte sécurisé qu'au moins deux étapes importantes après le déploiement complet de WebTransport. L'essai d'abandon sera prolongé si nécessaire.

Inverser l'intégration

Cette solution ne nécessite aucun contrôle administratif sur le réseau et peut être utilisée lorsque le serveur cible n'est pas assez puissant pour exécuter HTTPS.

Au lieu d'extraire des sous-ressources privées d'une application Web publique, un squelette de l'application peut être diffusé à partir du serveur privé, qui extrait ensuite toutes ses sous-ressources (telles que des scripts ou des images) à partir d'un serveur public, tel qu'un CDN. L'application Web obtenue peut ensuite envoyer des requêtes au serveur privé, car ceux-ci sont considérés comme ayant la même origine. Il peut même envoyer des requêtes à d'autres serveurs avec des adresses IP privées (mais pas d'hôte local), bien que cela puisse changer à long terme.

En hébergeant uniquement un squelette sur le serveur privé, vous pouvez mettre à jour l'application Web en envoyant de nouvelles ressources au serveur public, comme vous le feriez pour une application Web publique. En revanche, l'application Web résultante n'est pas un contexte sécurisé et n'a donc pas accès à certaines des fonctionnalités les plus puissantes du Web.

Des plans pour l'avenir

Restreindre les requêtes de réseau privé aux contextes sécurisés n'est que la première étape du lancement de l'accès au réseau privé. Chrome s'efforce d'implémenter le reste de la spécification dans les mois à venir. Nous vous communiquerons prochainement plus d'informations à ce sujet.

Restriction de l'accès à l'hôte local depuis les sites Web privés

Les modifications apportées à Chrome 94 n'affectent que les sites Web publics accédant à des adresses IP privées ou à localhost. La spécification d'accès au réseau privé classe également les requêtes provenant de sites Web privés vers localhost comme problématiques. Chrome finira par les abandonner également. Cela présente toutefois un ensemble de défis légèrement différent, car de nombreux sites Web privés ne possèdent pas de nom de domaine, ce qui complique l'utilisation des jetons d'essai d'abandon.

Requêtes CORS préliminaires

La deuxième partie de l'accès au réseau privé consiste à restreindre les requêtes de réseau privé initiées à partir de contextes sécurisés à l'aide de requêtes CORS préliminaires. L'idée est que même lorsque la requête a été lancée à partir d'un contexte sécurisé, le serveur cible est invité à fournir une autorisation explicite à l'initiateur. La requête n'est envoyée que si l'attribution aboutit.

En résumé, une requête CORS préliminaire est une requête HTTP OPTIONS comportant des en-têtes Access-Control-Request-* indiquant la nature de la requête suivante. Le serveur peut ensuite décider d'accorder ou non un accès précis en répondant 200 OK avec des en-têtes Access-Control-Allow-*.

Pour en savoir plus, consultez la spécification.

Restreindre les récupérations via la navigation

Chrome devient obsolète et bloque à terme les requêtes de sous-ressources envoyées aux réseaux privés. Cela n'affecte pas les navigations vers des réseaux privés, qui peuvent également être utilisées dans les attaques CSRF.

La spécification d'accès au réseau privé ne fait pas de distinction entre les deux types d'extraction, qui seront à terme soumis aux mêmes restrictions.

Photo de couverture par Markus Spiske sur Unsplash