Hallo,
manchmal werden Warnungen zu gemischten Inhalten in einem Forum angezeigt. Siehe jetzt Letsencrypt:
Einige Favicons - http://alohadentalgroup.com/assets/icons/favicon.ico
Gefunden in https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Ist es nicht möglich, diese Links auf HTTPS umzustellen oder diese HTTP-Links zu ignorieren?
Ein Forum mit gemischten Inhalten ist schlecht.
Diese Favicon-URL wird nicht von Discourse gehostet. Verwendest du Discourse? Wie lautet die URL der Installation?
Ist force_https aktiviert?
Wenn ja, lade deine Icons erneut hoch. Wenn nein, aktiviere es und lade sie dann erneut hoch.
Ich weiß es nicht, ich bin kein Administrator des Letsencrypt-Forums.
Aber falls es eine lokale Option gibt, werde ich im internen Regular-Forum nachfragen.
PS: Danke für die Verlegung
Die Warnung ist kein Grund zur Sorge.
Einer der Nutzer auf der Let’s Encrypt-Website hat in diesem Thema Issues running certbot command - Help - Let's Encrypt Community Support eine URL mit http hinzugefügt.
Aus diesem Grund warnt der Browser zu Recht vor gemischtem Inhalt.
Warnungen wegen gemischter Inhalte sind immer schlecht. Es ist möglich, über HTTP Cookies zu setzen, die bei der nächsten HTTPS-Verbindung verwendet werden. Daher sollte Forum-Software niemals HTTP-Verbindungen initiieren.
Besonders in einem Forum, das über „Mein Zertifikat ist falsch
Dieses Favicon ist über HTTPS nicht verfügbar. Die Warnung vor gemischten Inhalten ist nicht ideal, aber vorzuziehen gegenüber der Verwirrung der Nutzer darüber, warum ihre Links nicht funktionieren.
Ich weiß. Aber es ist möglich, dass ein Man-in-the-Middle eine solche vom Browser initiierte HTTP-Verbindung nutzt, um ein Cookie über HTTP hinzuzufügen. Später wird das Cookie vom Browser über HTTPS gesendet – und der Man-in-the-Middle kennt das Sitzungs-Cookie.
Das funktioniert. Der HTTP-Status (404, 301, 410, 500) ist irrelevant.
Das ist
kein Problem. Das Favicon ist kein vom Nutzer initiierteter Link; der Nutzer fügt lediglich den HTTP-Link zur Seite ohne HTTPS hinzu.
Einfache Lösung: Keine Vorschau, wenn das Ziel HTTP ist. Dann muss das Favicon nicht geladen werden.
Nicht bei einer Verbindung zu einer Drittanbieter-Website. Der Browser sendet seine Cookies für die Forum-Website nicht an eine andere Website, weder über HTTP noch über HTTPS.
Sie erfinden ein Problem, das es nicht gibt. Bitte demonstrieren Sie einen Ausnutzungsfall dafür auf try.discourse.org, wenn Sie wirklich der Meinung sind, dass dies ein Problem ist.
Das ist nicht das Problem. Das wäre ein Browser-Fehler.
Ein Man-in-the-Middle kann ein Cookie in die Verbindung http://alohadentalgroup.com mit der Domain alohadentalgroup.com hinzufügen, mit dem bekannten Namen eines Sitzungs-Cookies (falls vorhanden, habe ich das nicht geprüft) dieser Domain (nicht von der Forendomain).
Wenn ein Nutzer später die Anmeldung bei https://alohadentalgroup.com verwendet, um diese Domain zu verwalten, wird dieses Cookie (erstellt über HTTP) über HTTPS zurückgesendet.
Dies ist eines der kritischen (und oft unbekannten) Cookie-Features.
Das ist ein Grund, warum Prefix-Cookies erstellt werden. Bei Cookies, die mit __Secure- oder __Host- beginnen, ist HTTPS erforderlich. Dann ist dies nicht mehr möglich. Gleiches gilt für Preload (aber die meisten Seiten nutzen kein HSTS und sind nicht vorab geladen).
Siehe (2017)
oder andere Links.
PS: Meine “Überprüfen Sie Ihre Website”-Seite (siehe mein Profil) enthält einige Beispiele und eine kleine Demo. Ein über HTTP erstelltes und über HTTPS zurückgesendetes Cookie. Über HTTP ist es (mit einem modernen Browser) nicht möglich, das __Host-Cookie zu erstellen. Prefix-Cookies sind jedoch selten.