Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

On 6 Jun 2014, at 01:34, Mike West <mkwst@google.com> wrote:
> Hi Katharine, thanks for your feedback!
> 
> On Fri, Jun 6, 2014 at 7:13 AM, Katharine Berry <katharine@getpebble.com> wrote:
> The key part here is that CloudPebble must be able to contact the
> watch; hence, it must be able to communicate with the websocket server
> on the phone.
> 
> I don't understand this point: why do you need to be able to access the watch/phone from a public website? This sounds very much like it would be better suited to an application that's installed to the local machine, perhaps as part of the SDK you're already requiring? If you spawn a web server at 127.0.0.1:8080, then connecting to private IP addresses from a page hosted there wouldn't be a problem.

Apologies; I was probably unclear – the web-based solution is a complete *alternative* to actually installing the SDK. The key feature of the environment is that the user does not have to install anything locally whatsoever when using the web-based solution. We’ve generally found that people appreciate this – the alternative is installing and running a collection of python scripts (with native dependencies) and a gcc cross-compiler. If we had them host the app locally that just adds more dependencies to the problem.

> Alternatively, you could use some of the platform features certain browsers offer. Chrome apps and extensions(?) have access to Bluetooth and USB APIs, for instance, which sound like they would suit your use-case well. I assume Firefox offers similar capabilities.

We do actually have to pass through the phone – while it is indeed a *mostly* transparent proxy, we permit developers to run a JavaScript component in a sandbox inside our phone apps, and in order to do that there is a single command that the phone actually handles itself to pull out that component. More generally, we can’t do USB (the device has no USB port), and bluetooth pairing with computers tends towards painful – especially since it requires repeatedly switching paired host for testing. Again, we are trying to offer a seamless experience as much as possible.

> I have bad news for you: Chrome considers this a bug, and we've fixed it. https://codereview.chromium.org/222153002/ landed about a month ago, meaning that mixed WebSockets will be blocked as of (I think) version 36. There's been a deprecation warning on the console since at least Chrome 34. Opera will likely follow suit, and (if they ask) we'd encourage Safari to do the same.

We are acutely aware of this – as I said, we have a couple of workarounds of varying sanity:

One is already implemented and live (this fixed both Chrome Canary and current Firefox; I haven’t yet checked IE), but the fact that it works at all feels like a browser flaw in itself.
An alternative, absurd hack we have is to actually enable TLS in the websocket servers, use a wildcard cert pointing to a domain that will resolve to arbitrary IPs, and provide the private key to the mobile apps as necessary. This solution has a bunch of obvious issues.
Finally, we can just turn off TLS on the main site, which would have the unfortunate side effect of potentially exposing users’ login sessions, source code, etc. that were previously safe.

In general, this restriction does not feel like it is actually *enhancing* security; instead, it pressures us to eliminate it. Regardless of how we cope with it, it doesn’t help with the public/private discussion that is the core of this thread.

> Firstly, to the best of my knowledge we cannot reasonably provide
> a valid certificate from our websocket servers, as explained above.
> 
> This should be resolvable. If the user already trusts Pebble to installing applications on their computers, asking them to trust a Pebble-signed certificate isn't a huge step.

As above, we are trying to keep this installation-free (though they presumably do already have our hardware on their wrist and our app on their phone). In my experience, getting users to correctly install a certificate, regardless of whether they understand the implications, is tricky.

> The problem, as I'm sure you understand, is that it's very difficult to differentiate "good" public->private connections from "bad" ones. My suspicion is that the former group is vastly outweighed by the latter.

Of course.

> Zack's suggestion to have some sort of CORS-like preflight request makes sense to me. There's some discussion of exactly that sort of capability in the Network Service Discovery API spec (https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-preliminary-cors-check), but I don't believe any user agents yet implement that capability.
>  
> It was also, as far as I'm
> aware, legitimate functionality to have used up to this point.
> 
> The RFCs have been around forever; Chrome has done a bad job following them. :/

I was specifically referring to the public->private connections; I’m aware that the the TLS->non-TLS connections have been banned forever. If something has actually called public->private websockets out as being illegal I haven’t run across them previously – have they? If not, I think it would be ideal to avoid breaking something that was historically legal and has (at least what we believe to be) legitimate use without providing any recourse.
 
– Katharine