[whatwg] Mixed content WebSockets: use subprotocols!

Hello,

This thread proposes a change to the HTML specification 10.3.2 "The
WebSocket interface"
(http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#the-websocket-interface).

Currently, Firefox blocks "ws://" connections from HTTPS pages, while
Chrome doesn't. Ultimately, this needs to be resolved somehow. There
are legitimate uses of mixed-content WebSocket connections - for
example, a simple VNC or SSH client in the browser. 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 crypto in
javascript over a raw WebSocket connection.

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.

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 have a document describing this:
http://nwilson.github.io/websockets-mixed-context/. The essential idea
is that WebSocket subprotocols supporting encryption shouldn't be
counted as insecure in the first place, so the whole issue of mixed
content doesn't apply. Either browsers can ship with a whitelist, or
extend the subprotocol argument in the Websocket ctor to specify that
the protocol is secure.

I'd like to ask whether any WHATWG members have any opinions on this
change, or where I can go to get review of it.

I can repost more background from the discussions on the Firefox list
if needed (https://groups.google.com/forum/#!topic/mozilla.dev.security/zPm2M-ieI20

Thanks,
Nicholas

-----
Nicholas Wilson: nicholas@nicholaswilson.me.uk

Received on Friday, 4 October 2013 17:25:50 UTC