Bonjour,
parfois, un forum affiche des avertissements de contenu mixte. Voir par exemple Letsencrypt :
Certains favicons - http://alohadentalgroup.com/assets/icons/favicon.ico
Repérés dans https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Serait-il possible de modifier ces liens pour utiliser HTTPS ou d’ignorer ces liens HTTP ?
Un forum avec du contenu mixte est problématique.
L’URL de ce favicon n’est pas hébergée sur Discourse. Utilisez-vous Discourse ? Quelle est l’URL de l’installation ?
Avez-vous activé l’option force_https ?
Si oui, téléchargez à nouveau vos icônes. Sinon, activez-la puis téléchargez-les à nouveau.
Je ne sais pas, je ne suis pas administrateur du forum Letsencrypt.
Mais s’il existe une option locale, je demanderai dans le forum interne Regular.
PS : Merci pour le déplacement
L’avertissement n’est pas une raison de s’inquiéter.
Un utilisateur du site Let’s Encrypt a ajouté une URL en http dans ce sujet : Issues running certbot command - Help - Let's Encrypt Community Support.
Pour cette raison, le navigateur avertit (à juste titre) qu’il y a un contenu mixte.
Les avertissements de contenu mixte sont toujours mauvais. Il est possible d’ajouter des cookies via HTTP qui sont utilisés lors de la prochaine connexion HTTPS. Ainsi, un logiciel de forum ne devrait jamais initier de connexions HTTP.
Particulièrement dans un forum qui parle de « Mon certificat est incorrect » ou « J’ai des avertissements de contenu » (le certificat est correct, mais il y a du contenu mixte — premier certificat avec ce domaine, les liens doivent être mis à jour).
Cette icône de site n’est pas disponible en HTTPS. L’avertissement de contenu mixte n’est pas idéal, mais il est préférable à la confusion des utilisateurs quant à la raison pour laquelle leurs liens ne fonctionnent pas.
Je le sais. Mais il est possible qu’un homme du milieu utilise une connexion HTTP initiée par le navigateur pour ajouter un cookie via HTTP. Plus tard, le cookie est envoyé par le navigateur via HTTPS, et l’homme du milieu connaît le cookie de session.
Cela fonctionne. Le statut HTTP (404, 301, 410, 500) n’est pas pertinent.
Ce n’est pas
un problème. Le favicon n’est pas un lien initié par l’utilisateur ; l’utilisateur ajoute uniquement le lien HTTP vers le site sans HTTPS.
Solution simple : Pas d’aperçu si la destination est en HTTP. Ainsi, il n’est pas nécessaire de charger le favicon.
Pas sur une connexion tierce. Le navigateur n’envoie pas ses cookies du site du forum vers un autre site, que ce soit en HTTP ou en HTTPS.
Vous créez un problème qui n’existe pas. Veuillez démontrer une exploitation de ce type sur try.discourse.org si vous pensez vraiment que c’est un problème.
Ce n’est pas le problème. Ce serait un bug du navigateur.
Un homme du milieu peut ajouter un cookie dans la connexion http://alohadentalgroup.com avec le domaine alohadentalgroup.com, en utilisant le nom connu d’un cookie de session (s’il existe, je n’ai pas vérifié cela) de ce domaine (et non du domaine du forum).
Si un utilisateur utilise ultérieurement la connexion de https://alohadentalgroup.com pour gérer ce domaine, ce cookie (créé via HTTP) est renvoyé via HTTPS.
C’est une fonctionnalité critique (et souvent méconnue) des cookies.
C’est l’une des raisons pour lesquelles les préfixes de cookies sont créés. Pour les cookies commençant par __Secure- ou __Host-, HTTPS est requis. Ainsi, cela ne devient plus possible. Il en va de même pour Preload (mais la plupart des sites n’utilisent pas HSTS et ne sont pas préchargés).
Voir (2017)
ou d’autres liens.
PS : Mon outil « vérifiez votre site web » (voir mon profil) contient une page avec quelques exemples et une petite démo. Un cookie créé via HTTP et renvoyé via HTTPS. Via HTTP, il n’est pas possible (avec un navigateur moderne) de créer un cookie __Host-. Mais les cookies avec préfixe sont rares.