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

On Tue, Jun 10, 2014 at 8:47 PM, Zack Weinberg <zackw@cmu.edu> wrote:

> I see this as *the* objection to the "suggestion above".  This is
>  exactly the sort of choice that users should not be saddled with.
> (Read <https://www.cs.auckland.ac.nz/~pgut001/pubs/psychology.pdf>.
> Then read it again.  Then let it sink in for a while and read it
> again.)
>

I do agree that my proposed solution is a poor one. It has the advantage of
being a poor solution _only_ for those developers who have a desire to
opt-into the badness (and I'd argue that, in the context of logging into
Pebble's web application and being instructed to evaluate the self-signed
cert that was presented, users would be less likely to be confused than
usual: this, of course, is only a weak endorsement).

The nice thing from my perspective is that users who don't fall into the
category of developers who need to access local devices from a public
website would retain all their status-quo protections, and we wouldn't be
exposing additional attack surface in the browser that could potentially
weaken the protections we offer to every other website on the net.

I'm not the person to speak about implementation difficulty in any of
> the browsers, but - strictly from a usable-security standpoint - I
> think that if we're going to go here at all [and there is a
> demonstrated need] we have to find some way to automate the handshake.
> Which means turning that self-signed certificate into a certificate
> tied to some kind of trust anchor, even if it's not a normal TLS-PKI
> trust anchor.
>

I'm not convinced that allowing a website's JS to "poke a certificate into
the browser" or "[suspending] normal PKI rules" is a better solution. Both
of those scare me. Basically, the suggestion as I understand it is that the
user agent would connect to `example.com`, and `example.com` would then
tell the user agent what certificate to accept for some arbitrary subdomain
of `example.com` _and_ in some way map that subdomain to an internal IP.
Both of those seem dangerous, even leaving aside the case in which
subdomains may be owned by different parties (`*.github.io`, for example).

(I realized while writing that bit that I don't actually understand how
Pebble's app opens a WebSocket connection in the first place. How do you
know what IP address to connect to?)

An unsatisfying answer is that I'm totally the wrong guy to evaluate
changes to PKI. Moreover, I think changes to the way that a browser
authenticates a host are probably outside the remit of the mixed content
spec. As far as this spec is concerned, subresources in a TLS-protected
document should be TLS-protected; changing the definition of TLS-protection
in order to encompass new certificate distribution mechanisms would
automatically make the mixed content checker do The Right Thing.

Basically, you're proposing changes to what the browser should do on the
transport-layer and how certificates should be minted and distributed. I
hesitate to send anyone to the CA/B forum <https://cabforum.org/>, but I
think that's where this discussion might need to happen.

Note also that, because of the pharming attack, we really need mutual
> authorization here.
>

I do agree. That's one of the reasons I find it difficult to allow
arbitrary access to pieces of an internal network without the user actively
doing something in order to enable that ordinarily dangerous connection.

Manually installing a certificate that Pebble provides seems like the right
solution for the TLS side of the problem. That was rejected as being too
much work for the developer. Personally, I'd prefer that we reevaluate that
objection.

Something CORS-like seems like the right solution to the private-IP side of
the problem, but I'm quite open to other proposals.

The two of those together would provide mutual authorization: the user
expects connections to a device matching the cert they installed into their
trust store, and the device expects to service connections from the outside
world. If Pebble provided a client cert as well, the device could even
authenticate the user. *shrug* That seems like a reasonable outcome, even
if it does involve some modest effort on the developer's part.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)