[Bug 25972] Please require a secure origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

--- Comment #20 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to Ryan Sleevi from comment #19)
> (In reply to Ehsan Akhgari [:ehsan] from comment #18)
> > > For 2, the issue is not and has never been about "promoting TLS" as an
> > > ideological point.
> > 
> > FWIW that is not what I was suggesting at all, and I don't believe you're
> > arguing for that either.
> 
> Correct, but it was indeed mentioned in the Firefox post - "As for making
> new features unavailable without TLS in order to promote the use of TLS,"

If I understand correctly, Henri was just enumerating the possible reasons to
tie this API to secure origins.  At any rate, I'm not particularly interested
in debating that aspect, especially since you're not advocating it.  :-)

> > IOW, it seems to me that restricting the exposure of this API to secure
> > origins doesn't actually accomplish what you're going for here.
> 
> No, I felt that I did address this, but since you missed it, I'll try
> restating. The goal is to be secure by default, which we believe there to be
> a >0 value. Mark's analysis is one we fundamentally disagree with, and so
> I'm not going to spend much time trying to explain why it's a poor security
> model.
> 
> Yes, it's correct that one can do a lot of things to smuggle the information
> across origin. However, that can equally be said of other web platform
> features - from geolocation to microphone access. That is, two origins,
> acting in concerted effort, can compromise or undermine many security
> boundaries that UAs interact. That doesn't mean there isn't value in
> recognizing or attempting to make such separations, however, and they
> provide value.

I think there is an important difference between microphone access from
getUserMedia and WebCrypto, in that the former gives you an object that you
cannot postMessage to another frame, whereas WebCrypto just returns raw data
that can be transferred through postMessage verbatim.  I think that for
geolocation too, merely restricting the API to secure origins won't make a huge
difference because of the exact same problem.  But I personally think that the
right solution for geolocation is to restrict it to documents loaded from a
secure origin in a top-level browsing context, and merely restricting it to
secure origin doesn't buy us much.  (But of course, there are backwards compat
concerns with geolocation, unfortunately.)

But more to the point, I think we need to also remember that most of the
features of WebCrypto (I think perhaps all except for key storage) are
implementable in pure JS.  Such JS implementations, if served through
non-secure origins, are prone to all of your concerns here similar to
WebCrypto.  However, providing WebCrypto for such origins means that the
application can at least rely on secure key storage, which is a win over the
status quo on the Web.

These two points being considered together is what makes me hesitate to agree
that this API should be restricted to secure origins.

If I'm reading your comments correctly, you don't agree that the first point
matters because you can already share information across secure and non-secure
origins.  But I really don't think the "secure by default" argument applies
here, since I think it's too easy here to bypass the security using the iframe
technique.

It's not clear to me what your position is on the second issue.

> Consider geolocation, which is granted on a per-origin basis. Nothing
> prevents there being an evil.com site, which accesses the user's location,
> and allows any arbitrary origin to iframe it and inquire as to the user's
> location. The user will never know that anotherevilsite.com or hostile.com
> also have access to the users location (by way of iframing). Yet we still
> recognize there being value in per-origin prompts.

I actually think that's a terrible model to follow here.  That to me is a big
mistake that we have made, and I'd rather not replicate the same in other Web
platform features.  For all intents and purposes, if an iframe inside a page
wants to access geolocation, we need to assume the worst and tie whatever
prompts or restrictions on access to the API/data to the user visible page,
which is the one loaded in the top-level browsing context.  iframe's don't
really map to anything meaningful as far as the user is concerned.

> > It's true that shipping something later is easier than unshipping something,
> > but there's also the interoperability concern, which I think is reason
> > enough to try to come to an agreement before shipping incompatible
> > implementations, as Boris already suggested.
> 
> Agreed. Which is why we're encouraging Firefox to adopt conversatism, so
> that secure by default can still be attainable.

I'm all for conservatism, but I'm trying to understand the trade-offs specific
to this issue.  To me, restricting WebCrypto:

1) Provides the false sense of security while ignoring the iframe issue, which
makes the security benefits negligible.
2) Takes away the opportunity for non-TLS content to have some security
provided by the WebCrypto API over their existing solution (which is
implementing the crypto in JS on the client.)

I'm actually quite worried about #2 as well.

> That said, we believe the security risks are real enough, and examples such
> as those provided by the WG members are so demonstrably and clearly
> insecure, that the value of encouraging secure by default outweighs the
> interoperability concern.

That's unfortunate to hear.  I do hope that we both are still ready to be
convinced otherwise.  I for one am quite open to change my mind here if you
help me understand why your proposal provides a better trade-off on the two
points above.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 22 October 2014 20:46:31 UTC