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 ajoute le support du mécanisme de sécurité HSTS au domaine google.com
Afin de renforcer la protection des utilisateurs

Le , par Stéphane le calme

41PARTAGES

11  0 
Vendredi dernier, l’équipe de sécurité de Google a annoncé avoir achevé l’implémentation du support du protocole HSTS pour tous les produits de l’entreprise qui s’exécutent sur le domaine google.com.

« Pendant des années, nous avons travaillé à augmenter l’utilisation du chiffrement entre nos utilisateurs et Google. Aujourd’hui la vaste majorité de ces connexions sont chiffrées, et nous continuons dans ce sens.

Pour améliorer la protection des utilisateurs, nous avons pris des mesures qui vont renforcer la façon dont nous utilisons le chiffrement pour les données en transit en implémentant un HTTP Strict Transport Security - HSTS - sur le domaine google.com. HSTS empêche que les gens naviguent accidentellement sur des URL HTTP en convertissant automatiquement des URL HTTP en des URL sécurisées HTTPS », a annoncé Google.

HSTS est un mécanisme de sécurité web qui est supporté par la majorité (tous ?) des navigateurs et serveurs web récents à l'instar de Google Chrome et Chromium (depuis la version 4.0.211.0), Firefox (depuis la version 4.0), Opera (depuis la version 12) ou Internet Explorer (à la version 11). Cette technologie permet au webmaster de protéger son service ainsi que ses utilisateurs contre les downgrades HTTPS (une attaque qui oblige le protocole de communication à abandonner son mode opératoire comme le chiffrement des communications pour préférer un mode ancien, de moins bonne qualité, pour ses opérations qui était toujours présent pour des problèmes de rétrocompatibilité), les attaques de type homme du milieu, le hijacking de cookie pour les connexions HTTPS.

Lorsque la politique HSTS est active pour un site web, l'agent utilisateur compatible opère comme suit :
  • il remplace automatiquement tous les liens non sécurisés (HTTP) par des liens sécurisés (HTTPS) avant l'accès au serveur ;
  • si la sécurité de la connexion ne peut être assurée (par exemple, le certificat TLS est autosigné), celui-ci affiche un message d'erreur et interdit à l'utilisateur l'accès au site à cause de cette erreur.

La tâche n’a pas été une partie de plaisir pour les ingénieurs. Ils indiquent que « d’ordinaire, implémenter HSTS est un processus relativement basique. Cependant, à cause de la complexité particulière de Google, nous avons eu besoin d’un peu plus de temps pour une préparation qui n’aurait pas été nécessaire pour la plupart des autres domaines. Par exemple, nous avons dû résoudre le problème de contenu mixte, des mauvais HREF, des redirections vers HTTP, et d’autres problèmes comme mettre à jour des services hérités qui pouvait poser des problèmes aux utilisateurs tandis qu’ils essayaient d’accéder à notre domaine principal ». D’ailleurs, l’année passée, durant ce processus ils ont accidentellement fait planter le Santa Tracker (un outil qui permet de suivre la tournée du Père Noël sur Google Maps) mais ont pu corriger leur erreur avant que l’outil ne soit ouvert au public.

Le HSTS permet à un serveur web de déclarer à un agent utilisateur (dans le cas d'espèce un navigateur web) compatible, qu'il doit interagir avec lui en utilisant une connexion sécurisée (dans le cas d'espèce le HTTPS). La politique est donc communiquée à l'agent utilisateur par le serveur via la réponse HTTP, dans le champ d'en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l'agent utilisateur doit accéder au serveur uniquement de façon sécurisée dans « max-age ».

Aussi, si HSTS est déjà activé sur google.com, l’équipe indique qu’il y a encore beaucoup à faire sur leur to-do liste de déploiement : « dans l’immédiat, nous nous sommes focalisés à accroître la durée pendant laquelle un en-tête est actif (max-age). Nous avons d’abord établi max-age à une journée, une courte durée permettant d’atténuer le risque de problème potentiel avec ce déploiement. Cependant, en augmentant la valeur de max-age, nous réduisons la probabilité qu’une requête initiale adressée à www.google.com se fasse en HTTP. Durant les mois à venir, nous allons faire évoluer la valeur de max-age pour qu’elle atteigne au minimum un an ».

Une étude menée par Netcraft en mars dernier a indiqué que 95 % des serveurs se servant du protocole HTTPS ne parviennent pas à mettre en place le HSTS ou alors présentent des erreurs de configuration.

Source : blog Google (support du HSTS), blog Google (Sant Tracker), étude de Netcraft

Voir aussi :

Google donne des précisions sur le déploiement HTTPS sur ses produits et services et fait une liste des pays qui s'en servent le plus

DROWN, la vulnérabilité dans le protocole SSLv2 affecte près d'un serveur HTTPS sur trois

Google met à la disposition des développeurs un panneau de sécurité sur Chrome pour faciliter le déploiement du HTTPS

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