[whatwg] Mixed content WebSockets: use subprotocols!
ian at hixie.ch
Tue Dec 3 13:35:26 PST 2013
On Fri, 4 Oct 2013, Nicholas Wilson wrote:
> Currently, Firefox blocks "ws://" connections from HTTPS pages, while
> Chrome doesn't.
Then Chrome has a bug. Firefox is following the spec.
> Ultimately, this needs to be resolved somehow.
The idea here is simply that if you're on a secure page, you shouldn't
need to worry about whether some random component is leaking information
out in the clear.
> There are legitimate uses of mixed-content WebSocket connections - for
> example, a simple VNC or SSH client in the browser.
Why in such a situation would you want to make a connection to a
plain-text WebSocket server from an HTTPS page?
(Generally, plain-text WebSockets are only for toy applications. I
would hope that all deployed production WebSocket servers would use only
> It is very hard for a peer-to-peer application to put certificates on
> each node for TLS ("wss://"), but WebCrypto makes it easy to proper
I don't understand what you mean here.
> Mixed-content blocking is good, and we're suggesting relaxing it. Some
> specific peer-to-peer webapps though have a genuine need for ws:// from
> HTTPS pages.
Can you elaborate?
> I've implemented a few different suggestions with Firefox patches, and
> concluded the only thing that's likely to get traction is a very
> specific change to the WebSockets interface to let through known-good
> subprotocols, treating them as 'secure' rather than 'mixed'.
I would be very dubious about any hand-rolled crypto being "secure".
> Either browsers can ship with a whitelist, or extend the subprotocol
> argument in the Websocket ctor to specify that the protocol is secure.
Why wouldn't people lie just to get around making things secure?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg