The mixed content is, fundamentally, not secured by HTTPS. If your page is important enough to warrant HTTPS in the first place, why are you allowing user-specified content into the mix anyhow? Users are not trustworthy, in general.
Bear in mind if you implement the proxy solution that others suggest, you aren't just serving the content, you're approving it. Blind proxying is not really sensible; again, if it were, then why are you HTTPS in the first place?
You're probably talking about images. You should probably let them upload images and host them yourself, at which point you should actually examine them somehow for security guarantees, such as "yes, this really is a JPG".
If this sounds a bit utopian or a bit hardnosed, what it really comes down to is, do you need HTTPS or not? I won't necessarily guarantee there's never an in-between answer but it's an awfully narrow space. And if the answer is "yes", well, follow through then.
Good question. If you mean specifically getting around the "some objects on this page are insecure" popups, a trick I've seen work is to cut off the http protocol portion of remote URLs, forcing them to look like "//www.example.com/to/file.jpg".
That's just a link that's relative to the protocol, the same way /blah is relative to the protocol + host. If you load an https page with inlined image links like that, it'll attempt to hit those images over https as well.
This is fine if you control the source and can handle both http/https serving. It doesn't help for content inlined by users, though, it'll just result in broken images.
Comments
How would you handle the mixed content e.g. on a secure forum where some content sent by the users contains non-secure elements like images?
The mixed content is, fundamentally, not secured by HTTPS. If your page is important enough to warrant HTTPS in the first place, why are you allowing user-specified content into the mix anyhow? Users are not trustworthy, in general.
Bear in mind if you implement the proxy solution that others suggest, you aren't just serving the content, you're approving it. Blind proxying is not really sensible; again, if it were, then why are you HTTPS in the first place?
You're probably talking about images. You should probably let them upload images and host them yourself, at which point you should actually examine them somehow for security guarantees, such as "yes, this really is a JPG".
If this sounds a bit utopian or a bit hardnosed, what it really comes down to is, do you need HTTPS or not? I won't necessarily guarantee there's never an in-between answer but it's an awfully narrow space. And if the answer is "yes", well, follow through then.
I believe hotmail handles this by proxying all external resources through their own HTTPS proxies.
Good question. If you mean specifically getting around the "some objects on this page are insecure" popups, a trick I've seen work is to cut off the http protocol portion of remote URLs, forcing them to look like "//www.example.com/to/file.jpg".
That's just a link that's relative to the protocol, the same way /blah is relative to the protocol + host. If you load an https page with inlined image links like that, it'll attempt to hit those images over https as well.
This is fine if you control the source and can handle both http/https serving. It doesn't help for content inlined by users, though, it'll just result in broken images.