Remédier au problème du contenu mixte avec les réécritures automatiques HTTPS

Cloudflare a pour ambition de mettre fin à l'Internet non crypté. Mais la transition du Web vers HTTPS pose un problème qui s'apparente à un cercle vicieux.

Autrefois, il était difficile, coûteux et lent de configurer un site Web compatible HTTPS. Sont ensuite apparus des services comme le SSL universel qui permettait de passer de http:// à https:// en un clin d'œil. D'un seul clic, un site pouvait passer en HTTPS avec un certificat SSL gratuit et tout juste édité.

C’était aussi simple que cela.

D'un coup d'un seul, le site est disponible en HTTPS et, encore mieux, il devient plus rapide, car il peut ainsi tirer parti du dernier protocole Web HTTP/2.

Malheureusement, l’histoire ne s’arrête pas là. De nombreux sites par ailleurs sécurisés souffrent du problème du contenu mixte. Cela signifie que l'icône verte du cadenas ne s'affichera pas sur un site https:// du fait qu'il n'est en fait pas véritablement sécurisé.

Voici où se situe le problème : si un site https:// comprend un contenu provenant d'un site (même le sien) diffusé par l'intermédiaire de http://, le cadenas vert ne peut s'afficher. La raison en est que les ressources telles que les images, le JavaScript, l'audio, la vidéo, etc. qui sont sous http:// ouvrent une brèche dans la sécurité du site Web sécurisé. Pas mal de problèmes en perspective.

Les navigateurs Web connaissent ce problème depuis très, très longtemps. En 1997, Internet Explorer 3.0.2 avertissait les utilisateurs qui naviguaient sur des sites à contenu mixte avec la boîte de dialogue suivante.

Aujourd'hui, Google Chrome affiche un i encerclé sur tout https:// dont le contenu n'est pas sécurisé.

Firefox affiche un cadenas avec un symbole d'avertissement. Pour bénéficier d'un cadenas vert dans l'un ou l'autre de ces navigateurs, chaque sous-ressource (ressource chargée par une page) doit être diffusée en HTTPS.

Si vous cliquiez sur Oui en 1997, Internet Explorer ignorait les dangers du contenu mixte et chargeait les sous-ressources en HTTP en texte brut. Le fait de cliquer sur Non empêchait leur chargement (ce qui se traduisait le plus souvent par une page Web incomplète mais sécurisée).

Il est tentant, mais naïf, de penser qu'il existe une solution simple au problème du contenu mixte : « Il vous suffit de tout charger à l'aide de https:// et de réparer votre site Web ». Malheureusement, la masse de contenu chargé dans les sites Web modernes à partir de sites Web propriétaires ou tiers fait qu'il est très difficile de « simplement » effectuer ce changement.

Image CC BY 2.0 par Mike Mozart

Wired a expliqué sa transition vers https:// dans une série d’articles de blog qui montrent à quel point il peut être difficile de tout faire basculer vers le HTTPS. L’équipe a commencé en avril et y a consacré 5 mois (après s'être préparée pendant des mois juste pour passer à https:// sur son site Web principal). En mai, elle a signalé un problème :

« [...] l'un des plus grands défis posés par la migration vers HTTPS est de préparer l'ensemble de notre contenu à être diffusé via des connexions sécurisées. Si une page est chargée en HTTPS, toutes les autres ressources (comme les images et les fichiers JavaScript) doivent également être chargées en HTTPS. Nous voyons de nombreux témoignages sur ces problèmes de « contenu mixte », ou d'événements dans lesquels une ressource HTTP peu sûre est chargée sur une page sécurisée en HTTPS. Pour réussir notre déploiement, nous devons nous assurer que nous avons moins de problèmes de contenu mixte, que nous diffusons autant de contenu WIRED.com sécurisé que possible. »

En 2014, le New York Times a qualifié le contenu mixte d'obstacle majeur à la sécurisation :

« Pour migrer correctement vers HTTPS, toutes les demandes d'accès aux ressources d'une page doivent être effectuées via un canal sécurisé. C'est un défi de taille, et beaucoup d'éléments entrent en jeu. Nous devons tenir compte de ressources chargées actuellement à partir de domaines non sécurisés, du JavaScript aux publicités. »

Et le W3C a reconnu qu'il s'agissait d'un problème colossal en déclarant : « Le contrôle de contenu mixte peut donner du fil à retordre aux administrateurs chargés de faire migrer des quantités importantes de contenu existant vers HTTPS. Plus particulièrement, l'examen des anciens contenus et la réécriture manuelle des URL de ressources est une tâche considérable. » Il a cité en exemple les énormes archives de la BBC.

Mais les sites de médias ne sont pas les seuls à faire face à un problème avec le contenu mixte. Beaucoup d'utilisateurs de SGC trouvent difficile ou impossible de mettre à jour tous les liens que leur SGC génère, car ils peuvent être enfouis dans des fichiers de configuration, du code source ou des bases de données. De plus, les sites qui ont besoin de traiter du contenu généré par les utilisateurs sont également confrontés à un problème avec les URL http://.

Le contenu mixte se décline en deux variantes : actif et passif. Les navigateurs Web modernes abordent les dangers de ces différents types de contenus mixtes comme suit : les contenus mixtes actifs (les plus dangereux) sont automatiquement et complètement bloqués, tandis que les contenus mixtes passifs sont autorisés mais sont signalés par un message.

Image CC BY 2.0 par Ben Tilley

Le contenu actif est tout ce qui peut modifier le DOM (la page Web elle-même). Les ressources intégrées par le biais des balises <script>, <link>, <iframe> ou <object>, les valeurs CSS qui utilisent l' url et tout ce qui est demandé à l'aide de XMLHTTPRequest sont en mesure de modifier une page, lire les cookies et accéder aux identifiants des utilisateurs.

Tout le reste constitue le contenu passif : les images, les sons, les vidéos qui sont incorporés dans la page, mais qui ne peuvent pas eux-mêmes y accéder.

Le contenu actif est une menace réelle, car, si un attaquant parvient à intercepter la demande d'une URI http://, il peut remplacer le contenu par le sien. Il ne s'agit pas de préoccupations théoriques. En 2015, Github a été attaqué par un système appelé le Grand canon qui interceptait les demandes de fichiers JavaScript communs via HTTP et les remplaçait par un script d'attaque JavaScript. Le Grand Canon a armé des ordinateurs d'utilisateurs innocents en interceptant des transmissions TCP et en exploitant la vulnérabilité inhérente au contenu actif chargé à partir d'URL http://.

Le contenu passif constitue un autre type de menace : puisque les demandes de contenu passif sont envoyées sans cryptage, un espion peut surveiller les demandes et en extraire des informations. Par exemple, un espion bien positionné pourrait surveiller les cookies, les pages Web visitées et éventuellement les informations d'authentification.

Le module complémentaire Firesheep pour Firefox permet de surveiller un réseau local (par exemple, dans un café) pour y déceler les requêtes envoyées via HTTP, et de voler automatiquement les cookies permettant à un utilisateur de pirater une identité en un seul clic.

De nos jours, les navigateurs modernes bloquent le contenu actif qui est chargé de façon non sécurisée, mais autorisent le contenu passif. Néanmoins, la migration complète vers https:// est le seul moyen de remédier à tous les problèmes de sécurité liés aux contenus mixtes.

Il y a longtemps que nous voulions contribuer à résoudre le problème du contenu mixte, car notre objectif est que le Web devienne complètement crypté. Et, comme les autres services Cloudflare, nous souhaitions faire en sorte que tout cela se fasse en un clic.

Image CC par 2.0 par Anthony Easton

Nous avons envisagé diverses approches :

Insérer automatiquement la directive CSP « upgrade-insecure-requests »

La directive upgrade-insecure-requests peut être ajoutée dans un en-tête de politique de protection du contenu comme suit :

Content-Security-Policy: upgrade-insecure-requests

qui demande au navigateur de migrer automatiquement toute requête HTTP vers HTTPS. Cette opération peut être utile si le propriétaire du site Web sait que chaque sous-ressource est disponible via HTTPS. Le site Web n'aura pas besoin de changer les URI http:// intégrées au site Web en https://, le navigateur s'en chargera automatiquement.

Malheureusement, upgrade-insecure-requests présente un gros inconvénient. Puisque le navigateur migre aveuglément chaque URL vers https://, que l'URL qui en résulte soit ou non fonctionnelle, il est possible de se retrouver avec des pages incomplètes.

Modifier tous les liens pour utiliser https://

Comme certains navigateurs utilisés par les visiteurs des sites Web Cloudflare ne sont pas compatibles avec upgrade-insecure-requests, nous avons songé à faire migrer les URI http:// vers https:// lorsque les pages passent par notre service. Étant donné que nous sommes en mesure d'analyser et de modifier les pages Web en temps réel, nous aurions pu créer un service « upgrade-insecure-requests » dont le fonctionnement ne dépend pas du navigateur.

Malheureusement, cela ne règle pas le problème des liens cassés lorsqu'une URL http:// migre vers https:// mais que la ressource ne peut être chargée avec HTTPS.

Modifier les liens renvoyant à d'autres sites Cloudflare

Puisque Cloudflare met gratuitement Universal SSL à la disposition de ses 4 millions de clients et que nous couvrons un grand pourcentage du trafic Web, nous avons envisagé de simplement faire migrer de http:// à https:// les URI pour lesquelles nous sommes certains que le stratagème fonctionnera (car elles utilisent nos services).

Cela résout une partie du problème, mais ne résout pas le problème général de la migration du HTTP vers le HTTPS.

Créer un système qui réécrit les URL compatibles HTTPS connues

Finalement, nous avons décidé de faire quelque chose d'intelligent : migrer une URL de http:// à https:// si nous savons que la ressource peut être diffusée en HTTPS. Pour déterminer les liens pouvant être mis à niveau, nous nous sommes tournés vers l'excellente extension HTTPS Everywhere de l'EFF et la liste de préchargement HSTS de Google Chrome, afin d’avoir une meilleure connaissance des sites Cloudflare avec SSL activé.

Nous sommes très reconnaissants à l'EFF d'avoir gracieusement accepté de nous aider dans ce projet.

Le jeu de règles de HTTPS Everywhere va bien au-delà de la simple conversion de http:// à https:// : il contient des règles (et des exclusions) qui lui permettent (et nous permettent) de cibler des URL très spécifiques. Par exemple, voici une règle HTTP Everywhere pour gstatic.com :

<rule from="^http://(csi|encrypted-tbn\d|fonts|g0|[\w-]+\.metric|ssl|t\d)\.
gstatic\.com/" to="https://$1.gstatic.com/"/>

Elle utilise une expression standard pour identifier les sous-domaines spécifiques de gstatic.com qui peuvent être actualisés en toute sécurité pour utiliser HTTPS. Vous pouvez consulter l'ensemble des règles ici.

Étant donné que nous avons besoin de faire migrer un grand nombre d'URI intégrées dans des pages Web (environ 5 millions par seconde, selon nos estimations), nous avons comparé les analyseurs HTML existants (dont le nôtre) et décidé d'en écrire un nouveau pour ce type de tâche de réécriture. Nous vous en dirons plus sur sa conception, ses tests et ses performances dans un prochain article.

Les réécritures HTTPS automatiques sont désormais disponibles dans le tableau de bord de tous les clients Cloudflare. De nos jours, cette fonctionnalité est désactivée par défaut et peut être activée en un clic :

Nous surveillerons les performances et l'efficacité de cette fonctionnalité, et l'activerons par défaut pour les clients Free et Pro dans le courant de l'année. Nous prévoyons également d'utiliser les fonctions de création de rapports de la politique de sécurité du contenu pour donner automatiquement aux clients un aperçu des URI qui doivent encore être modifiées afin que leur transition vers https:// soit aussi simple que possible : comme Wired a pu le constater, il est parfois très difficile de déterminer quelles URI doivent être modifiées.

N'hésitez pas à nous faire part de vos commentaires sur ce service.