Being the rabble-rouser that I am, I'm here today to speak my mind about what I feel is the currently underinclusive definition of "mixed content", which currently only refers to references included via http addresses instead of https addresses. I've found on multitudes of occasions that websites suffer the same effects when including references via https addresses. How, you might ask? The hosts of those https addresses have invalid certificates and thus the referenced content is excluded due to being insecurely loaded.
2 Likes
So... it's not just "apples and oranges" that are being "mixed" ...
There are "apples and bad apples" too!
2 Likes
Speaking as someone who was unable to secure my websites during my last break and will be checking my websites for "mixed content" in August prior to getting some certs, what would be the solution for folks like me? Move the unsecured content to their domain and change the permalinks? What if you don't have the permissions/rights to do so?
2 Likes
I'm similarly confused about what exactly you're proposing here, @griffin. Are you suggesting that browsers need to do more to block bad-cert content? Are you just trying to put into the common vernacular a better definition for the term "mixed content" that you then want more people to adopt? I'm all for good-secure-connections-everywhere, as I'm sure you'd guess, I just don't understand what you're exactly going for here.
2 Likes
@tlrenkensebastian, @petercooperjr
Here's a prime example to start understanding the primary issue:
You can put something like "view-source:" (in Chrome-compatible browsers) in front of the address in your address bar before the https to see the HTML source code being served.
1 Like
"Mixed content" is supposed to only be a matter of how your website includes/references the content (by incorrectly using http addresses in your HTML source code to specify content rather than https). That's great since the responsibility lies solely in your wheelhouse. However, even if you use https addresses in your HTML source code to specify content, if the webservers serving the content do not have valid certificates installed for the host/domain names where the content lies, your visitors' browsers will refuse to display said insecure content, resulting in your having a hobbled/broken webpage. That's not in your wheelhouse, but still causes your webpage to suffer the same effects (minus the warning about insecure content in many web browsers).
1 Like
Browsers are blocking the content. The problem is that services like missingpadlock.com don't recognize this type of insecure content as "mixed content" because of the incredibly-narrow definition of "mixed content" currently being used.
Mixed Content, to clarify the intended browser's policy on pages loaded over HTTPS and linking content over plaintext HTTP
1 Like
Imagine this if you will...
Even on this very webpage you are viewing right now, I can put an https reference to an image file on a webserver that is serving an invalid certificate. If that image were to actually be shown by your browser, it would create an opportunity for a man-in-the-middle (MITM) attack on you by a malicious actor being able to replace the image you actually receive with something terrible.
1 Like
To make matters worse, some (few) browsers will consider a certificate for domain.com to be valid for www.domain.com even if the certificate doesn't actually cover www.domain.com. Absurd, but it has happened.
1 Like
I see. So you're mainly just advocating for better tools for web developers? We might be able to get a lot of mileage out of just telling people to look at their browser's built-in error console, though a lot of web sites have a lot of problems that clearly nobody's ever looked at.
3 Likes
In this case I think it's just a baby step in definition and subsequent implementation that could prevent a lot of the confusion being seen. It would place much greater burden on "mixed content" inspection tools though to validate ssl certificates served for contained content.
Unfortunately, the underlying problem itself is volatile since SSL certificate validity can vary by the second.
2 Likes
@griffin you can find such references at https://badssl.com/ for various kinds of badness.
One example is (if you see this red lock image, your browser is doing what you argued against).
3 Likes
The forum thwarted my example: it initially embedded the broken image but then it replaced it with a Discourse broken-image icon. Try https://sethschoen.com/embed.html instead (no forum software will rewrite the broken image embed!).
3 Likes
Perhaps "expand the definition" needs an upgrade...
Why use the same definition to describe very different situations?
[I think we would all be better served by adding a new definition for this particular situation.]
["Mixed Content" does not equal "Improperly Secured Embedded Content"]
5 Likes
I'm with RG here. For a person like me who wants to do things correctly, knowing that it's not entirely my fault for having missed a change in http to https while preparing my site for a cert is a good outcome. Additionally, learning that it's due to someone else who doesn't have a cert is a good way to demonstrate how important it is for everyone to think about certs and how they work.
2 Likes
As long as the result is a label with supporting tools that helps people know why their websites aren't secure and aids in making them secure, I'm good with a new label. 
I do feel like the two troubles are kith and kin, so I wouldn't want to create a rift between them with vastly differing labels. Two peas, one pod, so to speak.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.