[Bug 25972] Please require a secure origin

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

--- Comment #21 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Ehsan Akhgari [:ehsan] from comment #20)
> 
> 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.)

I don't think the comparison of microphone/getUserMedia that you make is
meaningful for a discussion of security, precisely because I can still smuggle
by postMessage the ArrayBuffer's that result from MSE (or potentially the
future Streams API). So it has the same effect.

> 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.

We'll have to disagree there. The entire point is that, without an
authenticated origin, you *cannot* have secure key storage for any meaningful
definition of secure. An attacker in a privileged position can

a) postMessage the Key object (structured clonable) to an origin of their
choosing for later use at a time of their choice, able to fully decrypt or
forge any messages
b) force the UA into a downlevel form such that it re-generates the key in an
insecure way (this is the problem with the "TOFU" model, in that it trivially
falls apart)

For an *unauthenticated* origin, everything WebCrypto provides can be met via
polyfill, which is what I mentioned in my previous message. It's precisely
because of this that it's entirely uninteresting to implement (as an
unnecessary surface of the web platform).

Note that I'm also ignoring the other implementation issues that exist in a
number of Web Crypto implementations that grant network level attackers the
ability to influence cryptographic decisions of secure origins. That's a
separate security issue on it's own, and one that TLS does not fully mitigate,
OTHER than preventing it from being _any_ attacker on the wire to being an
origin the user has explicitly navigated to.

> 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.

The goal is not perfect security, and hasn't been. Again, the question isn't
"Is it impossible to subvert these goals" (for which an extensible Web Platform
will always offer enough rope to subvert any security goals of a UA), but
whether it's "secure by default". The fact that you cannot trivially use broken
crypto in an unauthenticated origin is unquestionably "more secure" than just
allowing it, even if the end result is still achievable through careful
(insecure) machinations.

> 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.

Again, the goal is to provide meaningful guidance as part of the platform as to
what a reasonable security baseline is. Unauthenticated code performing
cryptographic operations will always be insecure to trivial inspection by any
skilled practioner.

To attempt to phrase it differently, is there any meaningful security that can
be had on unauthenticated origins? Despite Mark's claims to the contrary, we
feel the answer is resoundingly "No". This alone is the point - regardless of
whether it's possible to do something insecure via an authenticated connection,
it's impossible to do something secure via an unauthenticated connection.

> 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.)

Again, the claim is that there is no value of security for unauthenticated
transports.

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

Received on Wednesday, 22 October 2014 21:08:29 UTC