Chrome, Firefox et recherches Google : passage en force du HTTPS

En décembre 2014, l'équipe dédiée à la sécurité du projet Chrome publie une proposition à destination de tous les éditeurs de navigateurs web : les sites utilisant la version non sécurisée du protocole devront être explicitement indiqués comme non sécurisés par les navigateurs web.

Jusqu'à présent, l'approche était inversée : un site utilisant le HTTPS disposait d'un signal visuel positif (cadenas à côté de l'adresse le plus souvent).

En cas de problème de sécurité sur un tel site, le cadenas pouvait être barré pour indiquer un problème. L'approche serait maintenant d'indiquer explicitement un problème de sécurité sur tous les sites utilisant le HTTP classique.
Voici deux phrases qui résument à mon sens très bien les motivations de l'équipe de Chrome sur cette approche :

Nous savons que les attaques actives d'altération et de surveillance, ainsi que les attaques de surveillance passive, ne sont pas théoriques, mais sont en fait monnaie courante sur le web. […] Nous savons que les gens ne perçoivent généralement pas l'absence d'un indicateur visuel.

Autrement dit, la sécurité des communications web est à prendre au sérieux. Et un utilisateur ne remarquera jamais qu'un cadenas est absent : il faut aller plus loin. Et c'est donc ce que sera amené à faire Chrome, avec un plan de déploiement progressif prévu sur 2015.

On notera que les choses vont beaucoup plus loin, puisque certaines fonctionnalités sensibles risquent même d'être rendues indisponibles sur le protocole HTTP classique.

Très récemment, Firefox a rejoint le mouvement.

Le 13 avril dernier, l'un des responsables de la sécurité pour Mozilla, Richard Barnes lance le débat pour la mise en place d'un plan de dépréciation de la version non sécurisée du protocole.

Le plan s'appuie sur la proposition en cours du W3C autour de la notion de contexte privilégié, c'est-à-dire la nécessité de disposer d'un niveau de sécurité suffisant pour que le navigateur rende disponibles certaines fonctionnalités. Dans la première phase du plan, seules les nouvelles fonctionnalités du navigateur seront concernées. S'en suivra une deuxième étape, durant laquelle plusieurs fonctionnalités existantes seront cette fois intégrées. Elles restent à définir, mais il est d'ores et déjà annoncé que tout ce qui touche aux données de l'utilisateur devrait y trouver sa place.

On peut supposer que la géolocalisation par exemple, sur un site en simple HTTP , ne sera bientôt plus disponible.

Les navigateurs sont donc en marche accélérée sur ce sujet, mais ce n'est pas le seul aspect à prendre en compte pour considérer une migration vers HTTPS.

Depuis l'été 2014 déjà, Google prend en compte le HTTPS comme un signal positif dans son algorithme de classement. Le moteur précise que cela reste un signal faible, par rapport à l'importance accordée aux contenus, par exemple.

L'annonce précise qu'environ 1 % des recherches seraient affectées par ce changement.
Mais attention : Google rappelle également dans cette même annonce, et à plusieurs reprises, sa volonté très forte d'encourager un passage massif au HTTPS, en concluant notamment que ce signal sera probablement amené à se renforcer à travers le temps.

Si ce n'est pour la sécurité des internautes, le passage au HTTPS va prochainement devenir indispensable pour la majorité des sites web : que ce soit pour leur référencement, pour l'utilisation de certaines fonctionnalités des navigateurs, ou bien pour éviter un avertissement de sécurité préjudiciable à leur activité.

Mais HTTPS vient aussi avec certaines contraintes.

Une page web est composée de nombreuses ressources (images, feuilles de styles…), et même sur un site HTTPS, certaines d'entre elles sont parfois chargées en utilisant la version non sécurisée du protocole. On parle alors de contenus mixtes (Mixed Content).

Ce problème est fréquent, et remet en cause la sécurité des échanges.

En menant une étude sur le sujet en 2014, nous avions trouvé que 11 % des sites web y faisaient face. Pour en savoir plus, je vous invite à consulter notre article détaillé sur les contenus mixtes.

Pour résumer, il existe plusieurs niveaux différents de contenus mixtes, dont certains peuvent conduire à un blocage des ressources par les navigateurs web. Dans tous les cas, ce type de contenu provoque un avertissement de sécurité nuisible à la confiance de l'internaute.

La généralisation du HTTPS devrait restreindre l'étendue de ce problème, puisque la plupart des ressources devraient progressivement être rendues disponibles en HTTPS.

Cependant, pour en tirer profit, il sera nécessaire de mettre à jour les références à ces ressources (passer de http:// à https:// dans la définition des chemins), ce qui peut représenter un chantier d'envergure pour de nombreux sites.

Bonne nouvelle récemment, une nouvelle directive CSP (Content Security Policy) a vu le jour : upgrade-unsecure-requests. Cette nouvelle fonctionnalité est en cours d'implémentation sur Firefox et sur Chrome, on peut donc espérer pouvoir en tirer profit prochainement !

Cette directive va permettre de demander au navigateur - sur un site HTTPS - d'essayer de récupérer une ressource via HTTPS, même si son chemin est défini en HTTP. Cela permet donc de forcer toutes les ressources en HTTPS sans avoir à en modifier tous les chemins. Si la ressource n'est pas disponible en HTTPS, alors le navigateur revient à la version originale.

Un certificat coûte cher

Quelques acteurs en proposent déjà gratuitement, et ce projet devrait résoudre ce problème mi-2015 : https://letsencrypt.org/.

HTTPS est lent

Le cryptage de la communication a un coût, mais de gros progrès ont été faits de ce côté.

Citons par exemple le mécanisme HTTP Strict Transport Security (HSTS) qui, grâce à un Header Strict-Transport-Security, permet de forcer l'utilisation du HTTPS sur un domaine et donc d'éviter d'éventuelles redirections.
Vous trouverez des informations complètes sur le HTTPS et les enjeux de performance ici : [EN] https://istlsfastyet.com/.

Sur DareBoost.com, nous vous recommandons depuis plusieurs mois l'utilisation du HTTPS. Nous allons évidemment surveiller ce sujet, notamment sur les impacts SEO !

N'hésitez pas à tester votre site pour découvrir toutes nos autres recommandations !

• http://httparchive.org/trends.php?s=All&minlabel=Apr+15+2011&maxlabel=Apr+1+2015#perHttps
• https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
• https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
• https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit
• https://w3c.github.io/webappsec/specs/powerfulfeatures/
• http://googlewebmastercentral.blogspot.fr/2014/08/https-as-ranking-signal.html
• http://www.w3.org/TR/upgrade-insecure-requests/