en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

HTTPS partout: supprimer le contenu mixte pour améliorer le référencement

Introduction

Ces dernières années, nous avons vu le Web et l'assortiment d'industries qui le stimulent (c.-à-d. Les navigateurs, les moteurs de recherche, etc.) commencer à prendre la sécurité des utilisateurs plus au sérieux. Chrome est maintenant avertir les utilisateurs des sites Web HTTP avec plus de navigateurs prêts à suivre, tandis que la recherche Google a confirmé qu'elle augmentait le classement des moteurs de recherche HTTPS sites.

Des développements comme ceux-ci ont motivé une part importante des propriétaires de sites Web à déplacer leurs serveurs de l'ancien HTTP non sécurisé vers le HTTPS alternatif plus sécurisé. (HTTPS est considéré comme plus sécurisé car il nécessite que les serveurs soient authentifiés via des certificats SSL afin de protéger les utilisateurs contre la plupart des types d'attaques réseau.)

Cependant, la majorité des sites Web n'ont implémenté HTTPS que pour leurs composants les plus critiques, tels que les demandes de connexion ou POST, mais peuvent toujours utiliser HTTP pour d'autres fonctions «non critiques».

Cela avait du sens dans les premiers jours de HTTPS, car les connexions chiffrées sont plus coûteuses en termes de calcul car elles doivent effectuer poignées de main pour chaque nouvelle connexion. De plus, à cette époque, de nombreuses plates-formes de développement Web, bibliothèques et environnements largement utilisés n'étaient pas prêts pour HTTPS - un fait qui a causé des maux de tête interminables aux administrateurs et aux développeurs sous la forme de plantages d'applications tard dans la nuit ou d'erreurs d'exécution obscures.

Bien sûr, ce n'est plus vrai - en fait, comme cet article le soutiendra, ne pas en utilisant HTTPS pour tous Les connexions de votre site Web sont en fait mauvaises pour votre entreprise.

 

Contenu mixte

Les sites Web qui ne diffusent pas tout leur contenu via HTTPS sont appelés contenu mixte sites Internet. Un universitaire papier publié en 2015 a révélé que plus de 43% de leur échantillon des 100,000 XNUMX premiers d'Alexa servaient au moins un type de contenu mixte.

Bien que cela ne semble pas être un gros problème, le contenu mixte peut être assez dangereux pour les utilisateurs, mais il peut également avoir des effets négatifs sur les sites Web.

Les questions de sécurité

La raison la plus importante d'utiliser HTTPS pour l'ensemble de votre site Web est la sécurité. Tous les pirates ont besoin d'une seule connexion HTTP non protégée. Attaquants de l'homme au milieu (MITM) peut remplacer tout contenu HTTP sur votre page afin de voler des informations d'identification et des sessions, acquérir des données sensibles ou lancer des exploits de navigateur et installer des logiciels malveillants sur les ordinateurs de vos visiteurs.

Être compromis par votre site Web rendra naturellement vos utilisateurs méfiants et l'évitera à l'avenir, endommageant efficacement votre réputation en ligne.

Firefox et Chrome a commencé pour bloquer le contenu mixte par défaut, permettant aux utilisateurs de choisir manuellement de charger le contenu via HTTP. Néanmoins, étant donné que le contenu mixte est un risque pour la sécurité, les deux navigateurs affichent un avertissement de contenu mixte aux utilisateurs, ce qui peut également nuire à la réputation de votre site Web.

 

Avertissement relatif au contenu mixte de Firefox

Les problèmes de performance

Outre la sécurité, l’adoption sans cesse croissante de HTTP / 2 par l'industrie a apporté de nombreuses améliorations de performances et de sécurité sur le Web.

Bien que l'augmentation des performances semble contre-intuitive depuis HTTP / 2 ne fonctionne que sur des connexions HTTPS chiffrées, le protocole permet aux navigateurs d'utiliser une seule connexion chiffrée avec un serveur Web HTTPS pour toutes leurs communications.

La réutilisation de la même connexion supprime la surcharge imposée par la création répétée de nouvelles (c'est-à-dire que la poignée de main recommence). Cela signifie que le passage de connexions HTTPS chiffrées à HTTP non chiffré sur un site à contenu mixte est en fait plus lent et plus exigeant en ressources que la visite d'un site complètement protégé à l'aide d'une seule connexion HTTPS.

HTTP / 2 implémente également le 0-RTT mode de reprise de session, permettant aux navigateurs de reprendre une session suspendue avec un site Web HTTPS qu'ils ont visité auparavant, en utilisant une seule demande (au lieu d'une poignée de main complète). Cela rend la reprise HTTP / 2 au moins aussi rapide qu'une connexion HTTP non chiffrée, tout en offrant tous les avantages du HTTPS. La diffusion de contenu mixte signifie que votre site Web ne peut pas tirer pleinement parti de cela ou de l'une des autres fonctionnalités intéressantes de HTTP / 2.

Dans ces deux cas, HTTP / 2 améliore la vitesse de connexion de votre visiteur à votre site - et la vitesse compte. DE CAS ont montré au fil des ans que la réactivité et la vitesse de chargement des pages sont des exigences essentielles de conception d'interface utilisateur. Plus le temps de réponse d'un site Web est lent, moins il est probable que les utilisateurs restent engagés, et l'engagement des utilisateurs affecte directement l'expérience utilisateur de votre site Web (et par conséquent vos taux de conversion).

Le contenu mixte peut également affecter les performances au niveau des technologies Web sous-jacentes utilisées dans votre site Web. Navigateurs maintenant limiter les fonctionnalités javascript tels que les employés de service et les notifications push dans des contextes sécurisés uniquement, car ils pourraient autrement être utilisés abusivement par des pirates à des fins malveillantes. Cela signifie à nouveau que votre site Web ne peut tirer parti d'aucune de ces technologies lorsqu'il sert un contenu mixte.

Problèmes de référencement

L'optimisation des moteurs de recherche (SEO) est le pain et le beurre des commerçants en ligne. Le référencement fait référence à la pratique consistant à améliorer le classement d'un site Web dans un page de résultats du moteur de recherche (SERP), qui affecte directement le volume de trafic du site.

Google a confirmé que son algorithme de classement des résultats de recherche donne un petit coup de pouce au classement des sites Web servis via HTTPS. Étant donné que l'augmentation est en temps réel et par URL, la diffusion d'un site Web dans son intégralité via HTTPS entraînera une augmentation du référencement pour l'ensemble du site Web (au lieu des seules URL servies via HTTPS). Certes, cette augmentation du signal de classement est assez légère par rapport à d'autres telles que le contenu de qualité ou le trafic utilisateur, elle récompense toujours votre investissement dans la suppression du contenu mixte.

Google a également récemment annoncé que la vitesse de chargement des pages et les performances générales du site Web sont prises en compte (fortement) lors du choix du classement. Cela signifie que les optimisations des performances de HTTP / 2 et la suppression du contenu mixte peuvent fonctionner ensemble pour augmenter la visibilité de votre site Web sur le Web.

Enfin, si vous souhaitez tirer pleinement parti du SSL dans le référencement de votre site Web, vous pouvez envisager Certificats EV de SSL.com, qui offrent les meilleures garanties à vos visiteurs via des indicateurs de sécurité (comme cette barre verte dans le navigateur) pour les garder en sécurité et engagés avec votre contenu - et des visites plus longues équivalent à un classement plus élevé.

Avertissements concernant le contenu mixte du navigateur

Les visiteurs des sites protégés par SSL attendent (et méritent) une protection transparente. Lorsqu'un site ne protège pas entièrement tout le contenu, un navigateur affiche un avertissement «contenu mixte». Lorsque vos clients voient cet avertissement, ils peuvent réagir de deux manières. Si ils ne le font pas prendre la sécurité au sérieux, ils l'ignoreront, cliqueront et présumeront que tout ira bien (très mauvais). Si ils do prendre la sécurité au sérieux, ils y prêteront attention, sortiront de votre site et supposeront que accompagner ne prenez pas la sécurité au sérieux (encore pire).

De plus, tous les navigateurs modernes bloqueront les types de contenu mixte les plus malveillants et, ce faisant, pourraient endommager votre site.

La meilleure solution, bien sûr, est de s'assurer que ces avertissements et / ou blocages ne se produiront pas en premier lieu en configurant correctement votre site pour ne servir que du contenu sécurisé.

Pourquoi est-ce que je vois cet avertissement?

Un avertissement de contenu mixte signifie que les éléments sécurisés et non sécurisés sont servis sur une page qui doit être entièrement cryptée. Toute page utilisant une adresse HTTPS doit avoir tout le contenu provenant d'une source sécurisée. Toute page qui renvoie à une ressource HTTP est considérée comme non sécurisée et est signalée par votre navigateur comme un risque pour la sécurité.

Les avertissements à contenu mixte se divisent en deux catégories: contenu passif mixte et contenu actif mixte.

Contenu passif mixte

Le contenu passif fait référence aux éléments qui peuvent être remplacés ou modifiés mais ne peuvent pas changer d'autres parties de la page - par exemple, un graphique ou une photographie. La cause la plus fréquente de tous les avertissements de contenu mixte est lorsqu'un site (théoriquement) sécurisé est configuré pour extraire des images d'une source non sécurisée.

Les requêtes HTTP passives sont servies via ces balises:<audio>(src attribut)
<img> (src attribut)
<video> (src attribut)
<object> sous-ressources (lorsqu'un <object> effectue des requêtes HTTP)

Contenu actif mixte

Le contenu actif peut modifier la page Web elle-même. Une attaque de type "man-in-the-middle" pourrait permettre d'intercepter et / ou de réécrire une demande de contenu HTTP sur n'importe quelle page HTTPS. Cela rend le contenu actif malveillant très dangereux - les informations d'identification de l'utilisateur et les données sensibles peuvent être volées, ou des logiciels malveillants installés sur le système de l'utilisateur. Par exemple, un peu de JavaScript sur une page de création de compte conçue pour aider les utilisateurs à générer un mot de passe aléatoire pourrait être remplacé par du code fournissant un mot de passe aléatoire mais pré-généré à la place, ou pour fournir un mot de passe autrement sécurisé secrètement à un tiers. .

Le contenu mixte actif peut être exploité pour compromettre les données privées sensibles, mais même les pages Web accessibles au public qui semblent anodines peuvent toujours rediriger les visiteurs vers des sites dangereux, fournir du contenu indésirable ou voler des cookies pour exploitation.

Les requêtes HTTP actives sont servies via:<script> (src attribut)
<link> (href attribut) (cela inclut les feuilles de style CSS)
XMLHttpRequest demandes d'objet
<iframe> (src attributs)
Tous les cas en CSS où une valeur d'URL est utilisée (@font-face, cursor, background-image, Etc)
<object> (data attribut)

Tous les navigateurs modernes bloqueront le contenu mixte actif par défaut (ce qui peut casser un site mal configuré)

Pourquoi et comment corriger les avertissements de contenu mixte

La sécurisation de votre site Web permet à vos visiteurs de vous faire confiance, ce qui est d'une importance vitale. Cependant, éliminer tout le contenu non sécurisé de votre site a un avantage encore plus grand d'éliminer les faux avertissements positifs - si votre site correctement configuré est compromis, tout élément non sécurisé qu'un attaquant insère déclenchera l'avertissement de contenu mixte, vous donnant un fil de déclenchement supplémentaire à détecter. et résoudre ces problèmes.

Encore une fois, la meilleure façon d'éviter les problèmes de contenu mixte est de servir tout le contenu via HTTPS au lieu de HTTP.

Pour votre propre domaine, diffusez tout le contenu en HTTPS et corrigez vos liens. Souvent, la version HTTPS du contenu existe déjà et cela nécessite simplement d'ajouter un «s» aux liens - http:// à https://.

Pour les autres domaines, utilisez la version HTTPS du site si disponible. Si HTTPS n'est pas disponible, vous pouvez essayer de contacter le domaine et de lui demander s'il peut rendre le contenu disponible via HTTPS.

Alternativement, l'utilisation des «URL relatives» permet au navigateur de choisir automatiquement HTTP ou HTTPS, en fonction du protocole utilisé par l'utilisateur. Par exemple, au lieu de créer un lien vers une image en utilisant un lien avec le «chemin absolu» de:

Le site peut utiliser un chemin relatif:

Cela permet au navigateur d'ajouter automatiquement http: or https: au début de l'URL selon les besoins. (Notez que le site lié à devra proposer la ressource sur HTTP et HTTPS pour que les URL relatives fonctionnent.)

Suivez ces liens pour obtenir des informations plus spécifiques au navigateur sur les avertissements à contenu mixte:
Chrome
Firefox
Internet Explorer
D'excellents outils pour aider à traquer les liens non-SSL dans votre code source sont les outils de développement intégrés au Firefox et Chrome navigateurs. Des informations sur le fait de forcer un serveur Apache à gérer uniquement HTTPS peuvent être trouve ici.

Le premier problème de requête

Nous espérons que jusqu'à présent, cet article a présenté quelques bons arguments contre le contenu mixte, même si vous décidez de migrer entièrement votre site Web vers HTTPS, vous pouvez encore apporter quelques améliorations.

Lorsque les utilisateurs tapent l'URL de votre site Web dans un navigateur, ils ne tapent généralement jamais complètement le nom du protocole (c.-à-d. https://). Naturellement, le navigateur ne sait pas sous quel protocole votre site Web est servi et utilise par défaut HTTP.

Si votre site Web est configuré correctement, il redirigera (via les réponses HTTP 301/302) le navigateur vers son instance HTTPS; bien que cela signifie que les navigateurs doivent effectuer deux demandes au lieu d'une seule demande HTTPS lors de leur première visite sur votre site Web.

Cela peut être problématique car les utilisateurs peuvent percevoir le décalage, obtenant une mauvaise première impression du site. En tant que tels, ils seront moins susceptibles de rester, ce qui peut finalement entraîner une diminution du trafic des visiteurs.

De plus, les pirates peuvent intercepter cette première requête HTTP pour la lire ou la modifier avant d'atteindre le serveur. Une occurrence courante pour ce type de cas consiste à effectuer une attaque réseau appelée Décapage SSL ce qui permet à l'attaquant de remplacer une connexion HTTPS par une connexion HTTP non protégée.

HTTP Strict Transport Security à la rescousse

HTTP Strict Transport Security or HSTS est une tentative de résoudre ce problème. Mis en œuvre par l'Internet Engineering Task Force (IETF) dans la RFC 6797, HSTS est un en-tête HTTPS que les serveurs Web peuvent inclure dans leurs réponses. Cet en-tête indique aux navigateurs conformes de toujours utiliser HTTPS lors de la visite d'un site Web. HSTS s'applique à toutes les demandes, y compris les images, les feuilles de style CSS et toute autre ressource Web.

Comme vous pouvez l'imaginer, le navigateur doit d'abord lire l'en-tête HSTS afin de l'honorer, ce qui signifie que HSTS s'appuie sur le fait que les attaquants ne peuvent pas intercepter cette première requête HTTP. En conséquence, HSTS en lui-même n'est pas une solution complète mais plutôt une simple solution de contournement au stripping SSL.

Préchargement HSTS

Heureusement, le projet Chromium a trouvé une solution qu'ils ont nommée Préchargement HSTS, qui consiste à maintenir une liste publique des sites Web qui ont demandé la fonctionnalité de préchargement HSTS. Lors de la visite d'un site Web, les navigateurs Chromium consulteront la liste et si le site s'y trouve, ils communiqueront avec lui via HTTPS (y compris cette première demande) indépendamment de l'historique précédent ou de la saisie de l'utilisateur.

Par conséquent, le préchargement peut améliorer les performances et la sécurité de votre site Web en supprimant la demande HTTP initiale. De plus, cela peut améliorer indirectement le classement SERP de votre site et l'expérience utilisateur.

Tous les principaux navigateurs (Google Chrome, IE / Edge de Microsoft, Safari d'Apple, Firefox de Mozilla et Opera) consultent également la liste de préchargement HSTS de Chromium, ce qui signifie que rejoindre cette liste fournira des avantages de préchargement à vos visiteurs, quel que soit le navigateur qu'ils utilisent.

Cependant, nous serions négligents si nous ne mentionnions pas qu'il existe des préoccupations concernant l'évolutivité de la solution de liste de préchargement HSTS - Elle ne peut pas inclure tous les sites Web sur Internet en raison de la taille pratique et des limitations de complexité de calcul, et par conséquent l'entrée peut devenir de plus en plus difficile. à mesure que le temps passe et que le préchargement du HSTS devient plus largement adopté.

Comment puis-je m'inscrire?

Si vous souhaitez rejoindre la liste de préchargement HSTS, n'oubliez pas que votre site Web doit suivre certaines règles. Le projet Chromium a publié la liste des exigences de soumission pour les sites Web qui souhaitent rejoindre le site Web de leur projet. Les exigences sont incluses textuellement dans la liste suivante, mais vous pouvez trouver plus de détails dans HSTS RFC 6797.

Pour être accepté dans la liste de préchargement HSTS, votre site Web doit:

  1. Servir un certificat valide.
  2. Redirigez de HTTP vers HTTPS sur le même hôte, si vous écoutez sur le port 80.
  3. Servir tous les sous-domaines via HTTPS. En particulier, vous devez prendre en charge HTTPS pour www sous-domaine s'il existe un enregistrement DNS pour ce sous-domaine.
  4. Servir un en-tête HSTS conforme à la RFC 6797 sur le domaine de base pour les requêtes HTTPS:
    • Le max-age doit être d'au moins 31536000 secondes (1 an).
    • Le includeSubDomains doit être spécifiée.
    • Le preload doit être spécifiée.
  5. Si vous diffusez une redirection supplémentaire à partir de votre site HTTPS, cette redirection doit aussi avoir un en-tête HSTS conforme (tout comme la page vers laquelle il redirige).

Voici un exemple d'en-tête HSTS valide.

Strict-Transport-Security: max-age = 63072000; includeSubDomains; précharger

Vous pouvez tester l'éligibilité de votre site Web en visitant le site Web de la liste de préchargement et en entrant votre domaine dans la zone de saisie. L'application Web indique les problèmes (le cas échéant) que vous devez résoudre.

Outil d'éligibilité de préchargement HSTS

Malheureusement, la complexité des sites Web modernes ne permet pas de proposer une configuration de serveur unique pour le préchargement HSTS à inclure dans cet article. Il peut y avoir des problèmes d'exécution avec des composants tiers ou d'autres composants personnalisés qui doivent être résolus individuellement.

Bien que le projet Chromium ait inclus des recommandations de déploiement dans le site Web de préchargement, nous sommes toujours heureux d'aider nos clients à améliorer leur sécurité des communications. Envoyez-nous un e-mail à support@ssl.com et un expert se fera un plaisir de discuter de la meilleure voie à suivre pour vos besoins en matière de sécurité.

Conclusion

HTTPS est en train de devenir le protocole de communication Web par défaut, et s'y engager pleinement ne peut avoir que des effets positifs pour les propriétaires de sites et les visiteurs. Nous vous recommandons de supprimer tout contenu mixte de vos sites Web pour éviter les problèmes inutiles (et les utilisateurs mécontents).

Comme toujours, merci d'avoir choisi SSL.com, où nous pensons qu'un Internet plus sûr est un meilleur Internet.

Mise à jour (7 octobre 2019):  Le 3 octobre 2019, le blog Chromium annoncé que Chrome sera blocage tous les contenus mixtes, y compris les images, l'audio et la vidéo, dans une série d'étapes commençant par Chrome 79 (décembre 2019) et se poursuivant via Chrome 81 au début de 2020. Cette décision de Google signifie qu'il est plus important que jamais d'éliminer le contenu mixte de votre site web.

SSL.com Signature du code Les certificats sont un moyen économique de protéger votre code contre les altérations et les compromis non autorisés, et sont disponibles pour aussi peu que 64.50 $ par année.

COMMANDEZ

Abonnez-vous à la newsletter SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com