The discussion revolves around mixed content warnings on the Letsencrypt forum. JuergenAuer points out a favicon URL (http://alohadentalgroup.com/assets/icons/favicon.ico) that is causing the warning. Stephen responds that the favicon URL isn’t hosted in Discourse and suggests enabling force_https and reuploading icons.
JuergenAuer notes that he is not an administrator of the Letsencrypt forum and will ask about the issue internally. dax explains that the warning is caused by a user adding an http URL in a topic, which is triggering the browser’s mixed content warning.
JuergenAuer emphasizes that mixed content warnings are always bad, as they can be exploited by a man-in-the-middle attack. He suggests that forum software should never initiate http connections.
Stephen responds that the favicon is not available over HTTPS, but agrees that mixed content warnings are not ideal. JuergenAuer explains the potential security risk of mixed content warnings, where a man-in-the-middle can add a cookie via http and then have it sent via HTTPS.
JuergenAuer further explains the security risk, noting that a man-in-the-middle can add a cookie with a known session cookie name, which can then be sent back via HTTPS. He suggests that a simple solution would be to not load favicons from http URLs.
Hi,
sometimes a forum has mixed content warnings. See now Letsencrypt:
Some favicons - http://alohadentalgroup.com/assets/icons/favicon.ico
Found in https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Isn’t it possible to change these links to https or to ignore these http links?
A forum with mixed content is bad.
That favicon URL isn’t hosted in Discourse, are you using Discourse? What’s the URL for the installation?
Do you have force_https enabled?
If so reupload your icons. If not enable it then re-upload.
I don’t know, I’m not an administrator of the Letsencrypt forum.
But if there is a local option, I will ask in the internal Regular-forum.
PS: Thanks moving
The warning is nothing to worry about.
One of the users on Let’s Encrypt site added a URL in http, in this topic Issues running certbot command - Help - Let's Encrypt Community Support.
For this reason the browser warns (rightly) that there is mixed content.
Mixed content warnings are always bad. It’s possible to add cookies via http that are used with the next https connection. So forum software should never initiate http connections.
Especially in a forum that talks about “My certificate is wrong” or “I have content warnings” (certificate is correct, but there is mixed content - first certificate with that domain, links must be updated).
That favicon isn’t available over HTTPS. The mixed content warning isn’t ideal, but it’s preferable to user confusion over why their links don’t work.
I know. But it’s possible that a man in the middle uses such a browser initiated http connection to add a cookie vie http. Later, the cookie is sent from the browser via https - and the man in the middle knows the session cookie.
That works. The http status (404, 301, 410, 500) isn’t relevant.
That’s
not a problem. The favicon isn’t a user initiated link, the user adds only the http link to the site without https.
Simple solution: No preview if the destination is http. Then it’s not required to load the favicon.
Not on a third-party connection. The browser isn’t sending its cookies for the forum site to another site, HTTP or HTTPS.
You’re making a problem where one doesn’t exist. Please demonstrate an exploit for this on try.discourse.org if you really feel this is a problem.
That’s not the problem. That would be a browser bug.
A man in the middle can add a cookie in the http://alohadentalgroup.com connection with the domain alohadentalgroup.com, with the known name of a session cookie (if exist, didn’t checked that) of that domain (not from the forum domain).
If a user - later - uses the login of https://alohadentalgroup.com to manage that domain, that cookie (created via http) is sent back via https.
This is one critical (and often unknown) cookie feature.
That’s one reason Prefix cookies are created. Cookies starting with __Secure- or __Host-, https is required. Then this isn’t longer possible. Same with Preload (but most sites don’t use HSTS and aren’t preloaded).
See (2017)
or other links.
PS: My “check your website” (see my profile) has a page with some samples. And a small demo. A cookie created via http and sent back via https. Via http it’s not possible (with a modern browser) to create the __Host- cookie. But Prefix-Cookies are rare.