HTTP / HTTPS - Content of doom

  • My project is coming along very nicely, but I'm hitting a bump that I don't typically need to address.

    1. I want my entire site to use HTTPS - I've set it up so that this works. Sweet.
    2. I want to embed a twitch broadcast that is served over HTTP (an embedded flash player that is served from an HTTP link. There is no HTTPS equivalent that I can find)

    Which brings us to the dreaded 'Mixed Content' issue. Is there a way to embed HTTP content (Directly, using an iframe, using a real frame, using magic) on the same page as HTTPS without prompting the mixed client warning?

    I am 100% fine with sandboxing the HTTP content from the HTTPS content (it's a streamed video, they can fullscreen it or not)

    I'd prefer not to force HTTP on this page, since the chat does require you to be logged in to chat. (Ignoring the fact that twitch forces you to use HTTP logins so your credentials are spewed all over the web anyway...)

    Is there a solution? Or am I SOL?

  • Ohhhhhh, seems like someone else figured out a way around it:

    	<object type="application/x-shockwave-flash" height="323" width="520" data="" bgcolor="#000000">
    		<param name="allowFullScreen" value="true" />
    		<param name="allowScriptAccess" value="always" />
    		<param name="allowNetworking" value="all" />
    		<param name="movie" value="" />
    		<param name="flashvars" value=";channel=riotgames&amp;auto_play=true&amp;start_volume=25" />
    	<iframe frameborder="0" scrolling="no" src="" height="400" width="520"></iframe>

  • Discourse touched me in a no-no place

    A quick check of @codinghorror's magic answer machine indicates “doomed!” but maybe you can embed the chat as an HTTPS iframe inside a trivial HTTP container that doesn't need securing?

  • The mixed content warning is designed to tell the user of the web browser that not all of their communication is private. You want to create a page where not all of their content is private. Anything you do that meets your goal will also, by definition, be a bug in that browser feature. That would put you squarely in the world of constantly finding new browser exploits as the holes are patched. Also, any time you find yourself on the same side of an issue that malware authors are on, you're on the wrong side.

  • I survived the hour long Uno hand

    My thoughts exactly. +1 passes QA

  • @Jaime said:

    Also, any time you find yourself on the same side of an issue that malware authors are on, you're on the wrong side.

    QFE. This cannot be emphasized enough.

  • :belt_onion:

    Good reason for the mixed-content popup too. If your site includes non-secured communications, a man-in-the-middle attack (like on a public wifi connection) can inject javascript into the non-secured portion that could possibly read the data out of the SSL part once the page is rendered on user's browser, and then it can transmit that information back to bad guy.

    While it is generally an annoying non-issue at home on a secured wifi where you don't have to worry about the MITM, you should take heed of the mixed content warning if you are on an open public hotspot.

  • Reminds me of the time I had to get CORS working. Ended up finding out that one of the major reasons it wasn't working is that linux chrome doesn't do CORS at all if the resource isn't on port 80.

  • You could probably proxy the http traffic through your site or host that embedded plugin.
    Don't know if it is worth it though.

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.