How to access an insecure websocket from a secure website?

Question

TL;DR: A website is served over HTTPS and needs to access a WebSockets server over an unencrypted channel (ws:// url). The browser doesn't like this.

Encrypting the websocket is possible, but inconvenient - there is no trusted authority which could sign the certificate and thus it will be needed to manually install it for every client. I'd like to leave that as the last resort.

The website must be served over HTTPS and cannot be downgraded to HTTP.

Is there any other way to bypass this restriction? I tried Content-Security-Policy, but it didn't work.

Selfexplanatory

If there is, it's a security bug and will need to be fixed. – Bethanie

@JamesKPolk - You think so? CORS was invented to explicitly bypass the Same Origin Policy when really needed to in legitimate scenarios. Why not something similar for bypassing the "Same Security Level" (or whatever it is called)? – Selfexplanatory

Well, I think the difficulty is in user interface design. How should the browser indicate to the user that they are no longer secure? The mixed content warning? – Bethanie

@JamesKPolk - I think it should be kind of the responsibility of the developer to ensure security and then tell the browser "yes, even though it isn't loaded through an encrypted channel, it's still secure". Again, same thing as CORS - the developer explicitly and with extra effort tells the browser that "yes, this is OK after all". And then no extra UI is needed. – Selfexplanatory

CORS maintains the security by allowing crossing sites under a controlled, permitted regime. Using a non-SSL websocket from an SSL-secured page breaks the security, period. The developer cannot say it's ok because it's not -- there's nothing the developer can do to prevent the attacks that are opened up. Does it actually block the websocket or does it give the mixed-content warning? – Bethanie

@JamesKPolk - Well, as a developer, I'd like it to happen silently, of course. So that my users don't need to worry or even know about it. As for attacks - in this case I'm 99% sure that it's safe. It's only inside our network, behind NAT, and even if a hacker did somehow hijack the channel, there is nothing he could do to cause any damage - at worst a few people would be confused why the data on screen is obviously wrong. So, yeah, I'd like to tell the browser "this is OK, I take full responsibility for it, don't say anything and allow it". – Selfexplanatory

Answer 1

Vix,

The scenario you're describing is one of the scenarios that were considered to be a security issue when the restrictions against opening non-secure Websocket connections were put in place.

A user visiting a secure website (HTTPS) assumes all data is secure. The browser will not allow non-secure communication within this context (unless it has a security fault). This should include asset requests and any other requests invoked within the secure context (expect "mixed content" messages to slowly fade into history, as restrictions tighten up).

It's even worst on some browsers. For example, Safari will refuse to open a secure Websocket connection to an unsigned server even if the webpage was loaded with temporary approval for the certificate.

Is there any other way to bypass this restriction?

I'm sorry to report that the short answer to your question is "no".

Tuggle

Well OK then. Thanks for the info. I'll try to see how I can make the certificate thing work (any way for a website to emit a prompt for permanently installing/trusting a self-signed certificate?) – Selfexplanatory