[whatwg] Mixed content WebSockets: use subprotocols!

[Nicholas Wilson]

Bjoern,

Thanks for replying. I hope this isn't too long a response.

On 4 October 2013 18:55, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>Some specific peer-to-peer webapps though have a genuine need for
>>ws:// from HTTPS pages
>
> Such as? If it's so easy to do "proper crypto" in client-side scripts,
> why does the browser have to secure the HTTP transport? If it doesn't,
> you can use 'http' and access 'ws' over it.

I'm not sure it's easy, but it is possible to do client-side crypto.
The W3C WebCrypto spec is split into several parts, and includes an
information document listing use cases, so doing encryption
client-side is intended to be doable these days.

The document I linked to
(http://nwilson.github.io/websockets-mixed-context/) I think explains
this already.

The key thing is that the browser has to use HTTPS to use ensure the
JavaScript (and HTML) haven't been tampered with. Any webapp delivered
over HTTP is completely owned - a MITM just has to insert a short
<script> block at the end of the HTML body to completely subvert the
JS environment, or install a key event handler that sends all the
user's input to a server in Elbonia.

It's not acceptable, ever, to put a password box on a page that's
served over HTTP, if you think the user is going to type a high-value
password there (Mega Corp CEO's credentials will be targeted!). You
can't ask users to interact with an app delivered over an insecure
channel because it could do anything!

The browser's job is to fetch webapps securely and ensure integrity of
the code being executed (ie that it really does come from the domain
the user entered). The webapp's job is then to execute securely,
taking care where and how it sends the user's data they entered.

> Browsers would have to indicate to the user in either case that the
> "page" as a whole is insecure. The authors of the "proper crypto" so-
> lution might think they've done a good job securing the 'ws' channel,
> but the odds are against them and the browser cannot verify anything.

The page as a whole is secure, that's the goal. Our prototype webapp
works in Chrome (which doesn't block mixed-content WebSockets) and
we'd be very interested if you could detail a specific threat here.
Hundreds of companies and open-source products use encrypted protocols
to protect data in transit, and it's certainly not the case that SSH
(say) is less secure intrinsically than TLS. For the record, the
crypto we use in RealVNC products has been externally inspected. TLS
isn't the only "proper" protocol, and browsers aren't the only vendors
of security software who can be trusted.

> (It would be interesting to know how the peer-to-peer application can
> verify that the peer on the other hand is who they claim to be; we can
> then replace the CA infrastructure by this new method...)

It depends who you trust! The CA model works (just) for handing out
crytographic identities to domain names, but that's quite limiting.
One of our products (http://deskhopapp.com/) connects you peer-to-peer
with your facebook friends. We verify that a connection comes from
your friend by checking their signature matches the one they sent
through our brokering service (over HTTPS). This model is robust
(subject to customers trusting us not to tamper with the signatures,
but that's a very different threat from a normal MITM). Another of our
products uses a similar mechanism for corporate customers (out-of-band
exchange of signatures over HTTPS guarantees that the endpoint's
identity matches their corporate username, just a different namespace
to the facebook ids case). Traditional VNC and SSH products have used
the Key Continuity Model, where you check against stored signatures,
and for the first connection present a memorable representation of the
key for manual checking - OpenSSH uses the visual squiggles, we use
catchphrases ("Daniel ivory percent. Shake Olivia subway.")

We're not trying to replace the CA infrastructure, but it's hard to
get it to cover all use cases (identities in p2p applications that are
hard/impossible to force into the domain name namespace). For
ChromeOS, Firefox OS, and desktop browser, we're moving towards giving
webapps enough power to do all the task traditional applications can
handle.

Best wishes,
Nicholas
---
Nicholas Wilson: nicholas at nicholaswilson.me.uk