IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google Chrome va ajouter la prise en charge de la fonctionnalité Signed HTTP Exchanges
Pour gérer les documents Web signés

Le , par Stéphane le calme

539PARTAGES

12  0 
L'équipe Google Chrome travaille à déployer une fonctionnalité SXG (Signed HTTP Exchanges) à partir d’une future version de Chrome.

Citation Envoyé par Google
Signed HTTP Exchange (ou "SXG" est un sous-ensemble de la technologie émergente appelée Web Packages, qui permet aux éditeurs de rendre leur contenu portable en toute sécurité, c’est-à-dire qu’il peut être redistribué par des tiers, tout en préservant l’intégrité et l’attribution du contenu. Le contenu portable présente de nombreux avantages, notamment une livraison plus rapide du contenu, le partage de contenu entre utilisateurs et des expériences hors ligne simplifiées.
Alors, comment fonctionnent les échanges HTTP signés ?

Google rappelle que cette technologie permet à un éditeur de signer un seul échange HTTP (c'est-à-dire une paire requête / réponse), de la manière dont l'échange signé peut être servi à partir de n'importe quel serveur de mise en cache. Lorsque le navigateur charge cet échange signé, il peut afficher en toute sécurité l'URL de l'éditeur dans la barre d'adresse, car la signature de l'échange est une preuve suffisante que le contenu provient à l'origine de l'éditeur.

En clair, les SXG fournissent un moyen de prouver l’authenticité d’une ressource dans les cas où la couche de transport n’est pas suffisante.


Selon un document de travail de l'IETF (Internet Engineering Task Force), publié dans le cadre des efforts continus de l'équipe Chrome, il est expliqué que les échanges HTTP signés peuvent être utilisés pour prouver l’authenticité d’une ressource de plusieurs manières :
  • Lorsqu'elle est signée par un certificat qui est approuvé pour une origine, un échange peut être considéré comme faisant autorité pour cette origine, même s'il a été transféré sur une connexion qui ne fait pas autorité
  • Une ressource de niveau supérieur peut utiliser une clé publique pour identifier un éditeur attendu pour des sous-ressources particulières, il s’agit là d’un système appelé intégrité de sous-source (SRI - Subresource Integrity). La signature d’un échange fournit la preuve correspondante de l’auteur.
  • Une signature peut garantir l'échange d'une certaine manière, par exemple, lorsqu'elle apparaît dans un journal de transparence.


Les avantages à l’utilisation de SXG

Comme indiqué sur la page dédiée aux développeurs pour les produits de Google, l’entreprise cite les utilisations possibles de SXG, notamment :

  • Préextraction préservant la confidentialité: Bien que la préextraction de ressources (par exemple, par rel rel = prefetch) pour une navigation ultérieure puisse rendre la navigation plus rapide, elle comporte également des inconvénients en matière de confidentialité. Par exemple, la préextraction de ressources pour les navigations d’origine croisée révélera au site de destination que l’utilisateur est potentiellement intéressé par un élément d’information, même si l’utilisateur n’a finalement pas visité le site. D'autre part, SXG permet de préextraire des ressources d'origine croisée à partir d'un cache rapide sans jamais atteindre le site de destination, ne communiquant ainsi l'intérêt de l'utilisateur que si et quand la navigation a lieu. Google pense que cela peut être utile pour les sites dont le but est d’envoyer leurs utilisateurs sur d’autres sites. Google prévoit notamment de l'utiliser sur les pages de résultats de recherche Google pour améliorer les URL AMP et accélérer les clics sur les résultats de recherche.
  • Avantage d’un CDN sans céder le contrôle de la clé privée de votre certificat: un contenu soudainement devenu populaire (par exemple, s’il est publié en une sur un forum spécialisé) surcharge souvent le site sur lequel le contenu est diffusé. Si le site est relativement petit, il a tendance à ralentir ou même devenir temporairement indisponible. Cette situation peut être évitée si le contenu est partagé à l'aide de serveurs de cache rapides et puissants, et que SXG rend cela possible sans partager vos clés TLS.


Selon un billet publié sur le blog dédié au projet AMP, les échanges signés:

Citation Envoyé par projet AMP
Garantissent, à l'aide de signatures cryptographiques, que le contenu correspond exactement à ce que l'éditeur avait l'intention de montrer à l'utilisateur ;
Autorisent le navigateur à traiter un document comme appartenant à l’origine de l’éditeur. Cela permet à un éditeur d'utiliser des cookies de première partie pour personnaliser le contenu, exécuter des opérateurs de service et mesurer des analyses.

À l'heure actuelle, Cloudflare et DigiCert ont déjà ajouté la prise en charge des échanges HTTP signés à leurs plateformes, alors que Protocol Labs en est à la phase de tests.

Selon Protocol Labs

Citation Envoyé par Protocol Labs
Google défend le travail sur "Web Packaging" pour résoudre MITM (ou encore "problème d'attribution erronée” - misattribution problem) du projet AMP. Les échanges HTTP signés (SXG) découplent l'origine du contenu de celui qui le distribue. Le contenu peut être publié sur le Web, sans recourir à un serveur, une connexion ou un service d'hébergement spécifique, ce qui est extrêmement pertinent pour IPFS, car il est idéal pour la distribution de paquets immuables.
En outre, l'implémentation de Cloudfare « permettra aux caches AMP de servir du contenu sous son URL d'origine, nous avons implémenté des échanges signés HTTP, qui étendent l'authenticité et l'intégrité au contenu mis en cache et servi pour le compte d'un éditeur ».

Déjà supporté par Opera, considéré comme nuisible par Mozilla

La page Intention de déploiement indique que la fonctionnalité SXG sera disponible sur les six plateformes que sont Windows, Mac, Linux, Chrome OS, Android et Android WebView.

En outre, comme indiqué dans l'entrée SXG du tableau de bord de la plateforme Chrome, la version d'essai de cette fonctionnalité est déjà en cours d'exécution sur les plateformes Chrome 71 pour les ordinateurs de bureau et Android.

Il convient de noter que SXG est déjà pris en charge par le navigateur Web Opera, toujours en cours d’évaluation par l’équipe Microsoft Edge, alors que Mozilla Firefox la considère comme dangereuse et l’équipe Safari a déjà exprimé son scepticisme.


Source : Google, projet AMP, Protocol Labs, IETF, page Intent to ship, Mozilla, Microsoft Edge, Cloudfare, DigiCert

Voir aussi :

OS desktop : Linux a plus de 3 % de parts de marché selon StatCounter et Net Applications, si l'on inclut Chrome OS parmi les distributions Linux
Le navigateur Google Chrome va bientôt intégrer le mode sombre sous Windows 10, à la demande des utilisateurs
Chrome 72 est disponible en version bêta et apporte les champs de classe publique, ainsi qu'une API de requête d'activation utilisateur
Chrome se prépare à mettre fin au hijacking du bouton Retour, le navigateur va bientôt ignorer les redirections louches

Une erreur dans cette actualité ? Signalez-nous-la !