Actualités
23 mars 2023: le calendrier a été mis à jour et l'abandon n'aura pas lieu avant Chrome 117.
19 janvier 2023: le calendrier a été mis à jour et l'abandon n'aura pas lieu avant Chrome 114.
12 août 2022: le calendrier a été mis à jour, et l'abandon n'aura lieu qu'à partir de Chrome 109.
10 février 2022: article mis à jour publié sur Accès au réseau privé: présentation des prévols
25 août 2021: annonce de la mise à jour du calendrier et lancement d'un test de l'abandon.
Chrome supprime l'accès aux points de terminaison du réseau privé depuis des sites Web non sécurisés dans le cadre de la spécification de l'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 des routeurs et d'autres appareils sur des réseaux privés. Ces attaques ont touché des centaines de milliers d'utilisateurs, permettant ainsi aux pirates informatiques de les rediriger vers des serveurs malveillants.
Chrome apportera les modifications suivantes:
- Blocage des requêtes vers des réseaux privés à partir de sites Web publics non sécurisés à partir de Chrome 94.
- Lancement d'une phase d'évaluation avant arrêt qui se terminera dans Chrome
- Elle permettra aux développeurs de demander un délai supplémentaire pour les origines choisies, qui ne seront pas affectées pendant la période d'évaluation avant arrêt.
- Introduction d'une règle Chrome qui permettra aux déploiements Chrome gérés de contourner l'abandon de manière définitive. Disponible dans Chrome 92.
Si vous avez besoin de plus de temps pour atténuer l'impact du registre d'abandon pour l'essai d'abandon.
Si vous disposez d'un contrôle administrateur sur vos utilisateurs, vous pouvez réactiver la fonctionnalité à l'aide des règles Chrome.
Pour atténuer l'impact des nouvelles restrictions, utilisez l'une des stratégies suivantes:
- Passez à HTTPS pour votre site Web et, si nécessaire, pour le serveur cible.
- Passez à HTTPS pour votre site Web et utilisez WebTransport.
- Inversez la relation d'intégration.
Chronologie
- Novembre 2020: demande de commentaires sur les changements à venir.
- Mars 2021: après avoir examiné les commentaires et contacté les personnes concernées, les changements à venir sont annoncés. La spécification est renommée de CORS-RFC1918 en "Accès au réseau privé".
- Avril 2021: déploiement de Chrome 90 en version stable, avec des avertissements d'abandon.
- Juin 2021: Chrome 92 est déployé en version bêta, interdisant les requêtes réseau privées à partir de contextes non sécurisés. Après avoir reçu des commentaires de développeurs demandant plus de temps pour s'adapter, l'abandon est reporté à Chrome 93, et sera accompagné d'une évaluation avant abandon.
- Juillet 2021: suite aux commentaires des développeurs, l'abandon et l'essai associé sont reportés à Chrome 94. En outre, les sites Web privés ne sont plus affectés par l'abandon.
- Août 2021: déploiement de Chrome 94 en version bêta. Les développeurs Web peuvent commencer à s'inscrire à l'essai de l'abandon.
- Septembre 2021: déploiement de Chrome 94 en version stable. Les développeurs Web doivent s'être inscrits au test de l'abandon et avoir déployé des jetons de test en production.
- Décembre 2022: envoi de l'enquête pour la phase d'évaluation et envoi de commentaires. L'évaluation avant arrêt est étendue à Chrome 113.
- Mars 2023: l'évaluation avant arrêt est étendue à Chrome 116 et devrait se terminer dans Chrome 117. Un mécanisme alternatif basé sur les autorisations est en cours de développement et cible 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 quitter l'évaluation avant arrêt.
- Septembre 2023: le déploiement de Chrome 117 en version stable met fin à l'évaluation avant arrêt. Chrome bloque toutes les requêtes réseau privées à partir de contextes publics non sécurisés.
Qu'est-ce que l'accès réseau privé ?
L'accès au réseau privé (anciennement appelé CORS-RFC1918) limite la capacité des sites Web à envoyer des requêtes aux serveurs sur des réseaux privés. Il n'autorise ces requêtes qu'à partir de contextes sécurisés. La spécification étend également le protocole de partage de ressources inter-origines (CORS) afin que les sites Web doivent désormais demander explicitement une autorisation aux serveurs sur les 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é extrait. Par exemple, une requête 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é vers localhost.
Pour en savoir plus, consultez Feedback wanted: CORS for private networks (RFC1918) (Commentaires demandés : CORS pour les réseaux privés (RFC1918)).
Qu'est-ce qu'une évaluation avant arrêt ?
Les essais d'abandon (anciennement "essais d'origine inversée") sont une forme d'essais d'origine utilisés pour faciliter l'abandon des fonctionnalités Web. Les essais de suppression permettent à Chrome de supprimer certaines fonctionnalités Web et d'empêcher les sites Web de créer de nouvelles dépendances à leur égard, tout en leur donnant plus de temps pour les migrer.
Pendant une période d'évaluation avant arrêt, les fonctionnalités obsolètes ne sont pas disponibles pour tous les sites Web par défaut. Les développeurs qui doivent toujours utiliser les fonctionnalités concernées doivent s'inscrire au test de l'abandon et obtenir des jetons pour les origines Web spécifiées, puis modifier leurs sites Web pour diffuser ces jetons dans des en-têtes HTTP ou des balises méta (sauf dans ce cas). Si un site Web diffuse des jetons valides correspondant à son origine, Chrome autorise l'utilisation de la fonctionnalité obsolète pendant une durée limitée.
Pour en savoir plus, consultez Premiers pas avec les phases d'évaluation d'origine de Chrome et le guide du développeur Web pour les phases d'évaluation d'origine.
Changements dans Chrome
Chrome 94
À partir de Chrome 94, les contextes publics non sécurisés (en gros, les sites Web qui ne sont pas diffusés via HTTPS ou à partir d'une adresse IP privée) ne sont plus autorisés à envoyer de requêtes au réseau privé. Cette modification était initialement prévue pour Chrome 92. Par conséquent, les messages d'abandon peuvent toujours mentionner l'étape précédente.
Cette obsolescence est accompagnée d'une période d'évaluation avant arrêt, 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 pour des jetons. Consultez les instructions ci-dessous pour savoir comment vous inscrire et activer le test sur votre site Web.
Vous pouvez utiliser une paire de règles Chrome pour désactiver l'abandon de manière définitive, soit complètement, soit pour des origines spécifiques. Cela permet d'éviter les pannes dans les installations Chrome gérées, par exemple celles dans les environnements d'entreprise.
Chrome 117
La période d'essai de l'abandon prend fin. Tous les sites Web doivent être migrés vers une autre fonctionnalité, ou les règles de leurs utilisateurs doivent être configurées pour continuer à activer la fonctionnalité.
Actions recommandées pour les développeurs
La première étape pour les sites Web concernés consiste probablement à gagner du temps jusqu'à ce qu'une solution appropriée puisse être déployée: en vous inscrivant à l'essai de la phase de dépréciation ou en utilisant des règles. Ensuite, la procédure recommandée varie en fonction des circonstances de chaque site Web concerné.
S'inscrire à l'essai de l'abandon
- Cliquez sur S'inscrire pour l'accès au réseau privé à partir de l'origine de test des contextes non sécurisés afin d'obtenir un jeton d'essai pour l'origine participante.
- Ajoutez l'élément
Origin-Trial: $tokenpropre à l'origine dans votre en-tête de réponse. Cet en-tête de réponse ne doit être défini que sur les réponses de navigation et de ressources principales lorsque le document généré utilise la fonctionnalité obsolète. Il est inutile (mais inoffensif) d'associer cet en-tête aux réponses de sous-ressources.
Étant donné que ce test doit être activé ou désactivé avant qu'un document ne soit autorisé à effectuer des requêtes, il ne peut pas être activé via une balise <meta>. Ces balises ne sont analysées à partir du corps de la réponse qu'après l'émission de requêtes de sous-ressources. Cela pose un problème 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 essais d'origine.
Activer les règles
Si vous disposez d'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 à partir de contextes sécurisés.
Notez que le moteur WebKit et les navigateurs qui y sont basés (en particulier Safari) s'écartent de la spécification W3C sur le contenu mixte présentée ici et interdisent ces requêtes en tant que contenu mixte. Ils n'implémentent pas non plus l'accès au réseau privé. Les sites Web peuvent donc souhaiter rediriger les clients qui utilisent ces navigateurs vers une version HTTP en texte brut du site Web, qui leur permettra toujours d'envoyer des requêtes à localhost.
Accéder aux adresses IP privées
Si votre site Web doit envoyer des requêtes à un serveur cible sur une adresse IP privée, la simple migration du site Web initiateur vers HTTPS ne fonctionne pas. Le contenu mixte empêche les contextes sécurisés d'effectuer des requêtes via HTTP en texte brut. Le site Web nouvellement sécurisé ne pourra donc toujours pas effectuer les requêtes. Il existe plusieurs façons de résoudre ce problème:
- Passez à HTTPS aux deux extrémités.
- Utilisez WebTransport pour vous connecter de manière sécurisée au serveur cible.
- Inversez la relation d'intégration.
Passer aux deux extrémités au protocole HTTPS
Cette solution nécessite un contrôle sur la résolution DNS des utilisateurs, par exemple 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 disposer d'un nom de domaine public.
Le principal problème de la diffusion de sites Web privés via HTTPS est que les autorités de certification PKI (infrastructure à clé publique) ne fournissent des certificats TLS qu'aux sites Web disposant de noms de domaine publics. Pour contourner ce problème:
- 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. - Obtenez un certificat TLS pour
intranet.example. - Dans votre réseau privé, configurez le DNS pour qu'il résolve
intranet.exampleen tant qu'adresse IP privée du serveur cible. - Configurez votre serveur privé pour qu'il utilise le certificat TLS pour
intranet.example. Cela permet à vos utilisateurs d'accéder au serveur privé surhttps://intranet.example.
Vous pouvez ensuite mettre à niveau le site Web qui lance les requêtes vers HTTPS et continuer à envoyer les requêtes comme avant.
Cette solution pérenne et réduit la confiance que vous accordez à votre réseau, en étendant 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. Le serveur cible doit exécuter 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 approuvée en utilisant WebTransport et son mécanisme d'épinglage de certificat. Cela permet d'établir des connexions sécurisées avec des appareils privés qui peuvent disposer d'un certificat auto-signé, par exemple. Les connexions WebTransport permettent le transfert de données bidirectionnel, mais pas les requêtes de récupération. Vous pouvez combiner cette approche avec un service worker pour proxyer de manière transparente les requêtes HTTP sur la connexion, du point de vue de votre application Web. Côté serveur, une couche de traduction correspondante peut convertir les messages WebTransport en requêtes HTTP.
Nous sommes conscients que cela représente un travail conséquent, mais cela devrait être beaucoup plus facile que de se baser 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 que cela est particulièrement intéressant, car les contextes non sécurisés risquent de perdre l'accès à de plus en plus de fonctionnalités de la plate-forme Web à mesure que la plate-forme encouragera l'utilisation de HTTPS de manière plus forte au fil du temps. Indépendamment de l'accès à un réseau privé, il s'agit probablement d'un investissement judicieux.
Nous prévoyons que WebTransport sur HTTP/3 sera disponible dans Chrome 96 (une phase d'évaluation de l'origine a commencé) avec des mesures d'atténuation pour protéger contre le partage de clés et d'autres pratiques de sécurité non conformes, y compris les suivantes:
- Délai d'expiration maximal court pour les certificats épinglés.
- Mécanisme spécifique au navigateur pour révoquer certaines clés qui ont été utilisées de manière abusive.
Nous n'enverrons la restriction de contexte sécurisé qu'au moins deux étapes après le déploiement complet de WebTransport. L'évaluation avant arrêt sera prolongée si nécessaire.
Embedding inverse
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 à partir 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 celles-ci sont considérées 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 localhost), bien que cela puisse changer à long terme.
En n'hébergeant qu'un squelette sur le serveur privé, vous pouvez mettre à jour l'application Web en transférant de nouvelles ressources vers le serveur public, comme vous le feriez pour une application Web publique. En revanche, l'application Web obtenue n'est pas un contexte sécurisé. Elle n'a donc pas accès à certaines des fonctionnalités les plus puissantes du Web.
Les projets pour l'avenir
Limiter les requêtes de réseau privé à des 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.
Limiter l'accès localhost à partir de sites Web privés
Les modifications apportées dans Chrome 94 ne concernent que les sites Web publics qui accèdent à des adresses IP privées ou à localhost. La spécification d'accès au réseau privé classe également les requêtes de sites Web privés vers localhost comme problématiques. Chrome les abandonnera également à terme. Cela présente cependant un ensemble de défis légèrement différent, car de nombreux sites Web privés n'ont pas de noms de domaine, ce qui complique l'utilisation des jetons d'essai d'abandon.
Requêtes préliminaires CORS
La deuxième partie de l'accès au réseau privé consiste à filtrer les requêtes de réseau privé initiées à partir de contextes sécurisés à l'aide de requêtes préliminaires CORS. L'idée est que, même si 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'octroi aboutit.
En bref, une requête CORS préliminaire est une requête HTTP OPTIONS contenant certains 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.
Limiter les récupérations de navigation
Chrome abandonne et bloquera à terme les requêtes de sous-ressources vers des réseaux privés. Cela n'affecte pas les navigations vers des réseaux privés, qui peuvent également être utilisés dans des attaques CSRF.
La spécification d'accès au réseau privé ne fait pas de distinction entre les deux types de récupérations, qui seront finalement soumises aux mêmes restrictions.
Photo de couverture de Markus Spiske sur Unsplash