ARiNeXt
06 04 12 81 75 info@arinext.com

Passage en force du HTTPS

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

Pour rappel, le HTTPS (HTTP Secure) est, comme son nom l’indique, la version sécurisée du protocole HTTP. Le HTTPS vise à garantir la confidentialité et la sécurité des échanges : la communication étant chiffrée le protocole protège des écoutes clandestines, mais aussi d’une altération des données. Depuis quelques années, son utilisation se démocratise (en avril 2015, 7 fois plus de requêtes qu’en 2011 se font via HTTPS).

Mais d’ici la fin de l’année, on devrait connaître une intensification massive de cette tendance.

padlock

Je vous propose de découvrir pourquoi à travers cet article, mais aussi d’aborder quelques enjeux de mise en oeuvre ou de performance.

Chrome : Le HTTP sera explicitement indiqué comme non sécurisé.

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).
chrome-https-padlock
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 2 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.

Firefox planifie la dépréciation de HTTP non sécurisé

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 disponible 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 tout un lot de 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.
powerful-features-require-https

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.

Recherches Google : HTTPS pour un meilleur référencement

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, l’utilisation de certaines fonctionnalités des navigateurs, ou bien éviter un avertissement de sécurité préjudiciable à leur activité.

Mais HTTPS vient aussi avec certaines contraintes.

Le Mixed Content, une faille qui touche 11% des sites en HTTPS

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.

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.

mixed-content

La généralisation du HTTPS devrait restreindre l’étendue de ce problème, puisque la plupart des ressources devrait 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 pourvoir 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.