- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 27 Mar 2014 14:01:56 -0700
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: Richard Barnes <rlb@ipv.sx>, Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Kelsey Cairns <kelsey.cairns@inria.fr>
- Message-ID: <CACvaWvbHxs9siM8D5OnqS2mjGiMAYmMUbbE=h8KC8KcGgJt4pg@mail.gmail.com>
On Tue, Mar 25, 2014 at 5:37 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote: > Please see this https://bugzilla.mozilla.org/show_bug.cgi?id=917829 > > Chrome does not work the same way, then further discussions on mozilla > security list leaded to nothing else than the typical useless discussion > about whether https with http is more insecure than http with https while > the conclusion is obvious even if both are insecured. > Sure, and on Chrome, we're changing this behaviour to match Firefox (we found multiple compatibility issues each time we tried - I'm surprised Firefox/IE did not, but they already treat ws:// and http XHRs as active mixed content that is blocked). Although we're far away from the topic at hand. > > Could you please update us on the status on WebCrypto implementation in FF? > > Regards, > > Aymeric > > Le 25/03/2014 17:24, Richard Barnes a écrit : > > On Tue, Mar 25, 2014 at 10:49 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote: > >> This thread shows that maybe someone should then ask Mozilla to change >> its policy. >> > > Sorry, which policy? > > > > >> >> As explained in [1] Presentation "Why the main page is not using https", >> we are forced to use http to load the main page (which then loads the js >> code with https, a kind of artifice...), because we can not use ws with >> https, this is far more insecured than loading the page with https and use >> ws, so there is a "secure" mechanism on top of it, with a story of keys >> that only the users and the server know and that are never sent, currently >> this is not extraordinarly difficult to break by a MITM, and even to >> retrieve the keys, we don't really care because we will remove this, the >> target phase it a serverless P2P using WebRTC (whose insecure self-signed >> certificates use for DTLS will be secure by the Tor protocol) and the code >> is a standalone js file that can be retrieved from third parties and that >> can be checked, it's unlikely that they are all compromised. >> >> The project is using SSL/TLS over WS (and not the contrary), that's a js >> implementation, then it raises again the need of a secure SSL/TLS >> implementation in WebCrypto. >> >> In our case (like I believe in all cases) this just insures that you are >> talking with the one with whom you have established the SSL/TLS connection, >> which is enough, because we don't care if the anonymizer peer is a MITM, he >> can only know about the first hop, not what will happen next and it's >> unlikely that all the peers are MITM. >> >> This raises again too the certificates management issue for WebCrypto, >> because this goes with SSL/TLS. >> >> Not talking about ISSUE-22 which just means that our implementation can >> not be moved entirely to WebCrypto for hash. >> >> Maybe I missed some updates, I don't know the implementation status for >> Google, Mozilla and Microsoft, but maybe one point of interest for INRIA >> study could be: should I move Peersm project to WebCrypto when it's there? >> >> Of course the answer is likely to be yes, but for example why should I >> trust the WebCrypto prng in browser X? What if it depends on Windows? >> What is the process to make sure that browsers are implementing WebCrypto >> with no possibilities of leaks? >> >> The point here is not to restart the same discussions but if this can >> give some ideas to INRIA... >> >> Regards >> >> Aymeric >> >> [1] http://www.peersm.com >> >> Le 21/03/2014 20:58, Mark Watson a écrit : >> >> >> >> Sent from my iPhone >> >> On Mar 21, 2014, at 11:58 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >> >> >> >> On Fri, Mar 21, 2014 at 11:53 AM, Richard Barnes <rlb@ipv.sx> wrote: >> >>> On Fri, Mar 21, 2014 at 2:38 PM, Ryan Sleevi <sleevi@google.com>wrote: >>>> >>>> On Fri, Mar 21, 2014 at 11:34 AM, Mark Watson <watsonm@netflix.com>wrote: >>>>> >>>>> On Fri, Mar 21, 2014 at 9:51 AM, Ryan Sleevi <sleevi@google.com>wrote: >>>>> >>>>>> >>>>>> On Mar 21, 2014 9:18 AM, "Mark Watson" <watsonm@netflix.com> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Thu, Mar 20, 2014 at 1:01 PM, Ryan Sleevi <sleevi@google.com> >>>>>> wrote: >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> On Wed, Mar 19, 2014 at 7:40 AM, Kelsey Cairns < >>>>>> kelsey.cairns@inria.fr> wrote: >>>>>> >>> >>>>>> >>> Dear W3C Crypto API WG, >>>>>> >>> >>>>>> >>> Here at INRIA we're starting a security analysis on the current >>>>>> draft >>>>>> >>> of the Crypto API, co-funded by INRIA and W3C. The idea is to try >>>>>> to >>>>>> >>> get some results in before the end of the last call period. >>>>>> >> >>>>>> >> >>>>>> >> Could you define what your actual goal is with this security >>>>>> analysis? >>>>>> >> >>>>>> >> Typically, one does a security analysis of a protocol - does it >>>>>> live to the expected goals, and provide the expected assurances. WebCrypto >>>>>> itself provides many algorithmic building blocks, and (with the exception, >>>>>> arguably, of Wrap/Unwrap), doesn't really implement a protocol itself (as >>>>>> opposed something like JOSE JWS or XML DSig, which are arguably both >>>>>> formats *and* protocols) >>>>>> >> >>>>>> >>> >>>>>> >>> >>>>>> >>> Doing analysis of an API spec is a slightly unusual activity, it >>>>>> can >>>>>> >>> often lead to conclusions like "if the API is implemented this >>>>>> way.." >>>>>> >>> or "if the application program uses the API like this.." which can >>>>>> >>> seem a bit superficial, but we will aim to produce something >>>>>> concrete >>>>>> >>> output in terms of implementation advice, test cases for >>>>>> >>> implementations, etc. >>>>>> >>> >>>>>> >>> >>>>>> >>> As an example of the kind of things we find, one of the things we >>>>>> were >>>>>> >>> looking at in the spec this morning was padding oracles on key >>>>>> unwrap >>>>>> >>> operations. These are common in implementations of PKCS#11, for >>>>>> >>> example.. Following the current WebCrypto spec, if you were to >>>>>> unwrap a key using >>>>>> >>> AES-CBC or RSA PKCS1v1.5, incorrect padding would lead to >>>>>> "DataError" >>>>>> >>> or " OperationError" respectively. Meanwhile, the error if the >>>>>> >>> ciphertext is correctly padded but the key is too long or too >>>>>> short, >>>>>> >>> the error is "SyntaxError". The fact that these are different >>>>>> *could* >>>>>> >>> be enough to allow a network attacker to obtain the encrypted key >>>>>> by >>>>>> >>> chosen ciphertext attack, which would be relevant say for use >>>>>> case 2.2 >>>>>> >>> (Protected Document Exchange). >>>>>> >> >>>>>> >> >>>>>> >> Correct. This is a point of extreme tension within the working >>>>>> group - whether or not Key Wrapping / Unwrapping can provide security >>>>>> guarantees against the host code executing. This was the key of the debate >>>>>> as to whether or not to provide these primitives to begin with - or whether >>>>>> a web application can polyfill them. >>>>>> >> >>>>>> >> Individually, I remainly highly suspicious about this. As a >>>>>> security-minded individual, I can tell you there are dozens of ways to >>>>>> botch this, beyond just algorithm choice. As an editor, I can simply say >>>>>> "Please show more about how this is completely broken", so that the WG can >>>>>> take a closer look about the security guarantees it's attempting to make, >>>>>> and properly evaluate whether or not these APIs belong. I suspect that some >>>>>> members will insist they do, unfortunately, so guidance is welcome. >>>>>> >> >>>>>> >>> >>>>>> >>> >>>>>> >>> As a first step we were planning to look in more detail at the key >>>>>> >>> management subset of the API, but if there are any areas that are >>>>>> of >>>>>> >>> specific concern where you'd like us to take a closer look and you >>>>>> >>> haven't had time please let us know. All feedback welcome. >>>>>> >>> >>>>>> >>> Best, >>>>>> >>> >>>>>> >>> Graham Steel & Kelsey Cairns >>>>>> >> >>>>>> >> >>>>>> >> I think a clear point of use/misuse to examine would be be the >>>>>> issues previously discussed in ISSUE-21 ( >>>>>> https://www.w3.org/2012/webcrypto/track/issues/21 ) . The WG had, in >>>>>> the past, discussed requiring SSL/TLS for this API, as well as requiring >>>>>> more active mitigations for scripting issues via CSP ( >>>>>> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0230.html). There were and are some strong objections to this. >>>>>> >> >>>>>> >> Since part of your sponsorship includes "implementation advice", >>>>>> and conclusions like "if the application program uses the API like this", >>>>>> it would be interesting to see if INRIA can come up with any proofs of >>>>>> security where the code is delivered over unauthenticated connections (eg: >>>>>> HTTP) >>>>>> >> >>>>>> >> My continued assertion is that this is impossible - messages >>>>>> cannot be authenticated as coming from a user/UA, rather than a MITM. >>>>>> Likewise, under HTTP, a UA/user cannot authenticate messages as coming from >>>>>> the server, rather than a MITM. Encryption/Decryption results cannot be >>>>>> protected from being shared with Mallory, and that there can be no >>>>>> authenticated key exchange without an OOB means. Especially because Mallory >>>>>> can modify the JS operating environment, any proofs of correctness of a >>>>>> protocol go out the window, because the operating environment for those >>>>>> proofs is malleable. In a PKCS#11 world, this would be similar to a >>>>>> "hostile token" that has no pre-provisioned aspects. >>>>>> > >>>>>> > >>>>>> > Ryan is right, of course, that security assertions that can be made >>>>>> if the content is delivered over https cannot be made if he content is >>>>>> delivered over http. However, this does not mean there are no useful >>>>>> security assertions for the case where content is delivered over http. It >>>>>> would be good to have the nature of the assertions which can be made >>>>>> properly investigated and documented. >>>>>> > >>>>>> > Specifically, most of the assertions that can be made for the http >>>>>> case are in the "Trust on First Use" category: if an authentication key is >>>>>> agreed between client and server at time X, then the client can be sure at >>>>>> time Y that they are talking to the same entity they were talking to at >>>>>> time X (which may be A MITM, or may be the intended server, you don't >>>>>> know). Likewise the server can be sure they are talking to the same entity >>>>>> at time Y as they were at time X (which, again, may be either a MITM or may >>>>>> be the client). If you have other reasons to believe there was no MITM at >>>>>> time X, such assertions can be useful. >>>>>> > >>>>>> >>>>>> No, they really aren't. >>>>>> >>>>>> Regardless of how the key got there (and there are plenty of ways to >>>>>> screw that up), the fundamental analysis has to look at whether any of the >>>>>> assertions can be trusted if they are being processed by untrusted code: >>>>>> >>>>>> Sign: Did this message come from Alice or Mallory-injecting-script? >>>>>> >>>>>> Verify: Did this message come from Bob, or Mallory with >>>>>> Mallory-injected script saying Bob >>>>>> >>>>>> Encrypt: Is the Ciphertext sent to Bob the ciphertext that Alice >>>>>> intended, or modified by Mallory? >>>>>> >>>>>> Decrypt: Is the Plaintext processed by Alice what Bob sent in his >>>>>> Ciphertext, or is this Mallory? >>>>>> >>>>>> Wrap: Is this key the actually Alice's key, or is it a key of Mallory? >>>>>> >>>>>> Unwrap: Is the unwrapped key actually what Bob intended, or is it >>>>>> Mallorie's injected? >>>>>> >>>>>> Mallory can also force an unprovisioned state at any time, so you >>>>>> need a way to authenticate that. WebCrypto cannot provide that, such you >>>>>> must rely on side-channels - such as Named Key Discovery or TLS. >>>>>> >>>>> Yep, as I said, the nature of the assertions which *can* be made >>>>> with http content delivery are of the kind "This message came from the same >>>>> entity (Alice|Mallory) as I agreed keys with at some previous time X." >>>>> >>>>> Are you disputing this assertion itself, or whether it is useful ? >>>>> >>>>> ...Mark >>>>> >>>> >>>> I'm disputing the assertion. >>>> >>>> "I agreed keys with (Alice|Mallory) at some previous time X" - that >>>> statement is self-containable >>>> "This message came from (Alice|Mallory)" >>>> >>>> You can't assert at Time Y that the message came from the same party >>>> at Time X, if the *code* used to create that message is delivered >>>> insecurely. >>>> >>>> The point being you may have agreed upon keys with Alice, but then >>>> the message came from Mallory - because Mallory injected her code to create >>>> a custom message using Alice's credentials. >>>> >>>> Likewise, when you agree upon keys (at Time X), you can't be sure >>>> whether you're agreeing with Alice or Mallory, unless you're using a secure >>>> transport. >>>> >>>> So without a secure transport at both Time X and Time Y, you can't be >>>> sure that the party you agreed upon keys with is the same party that >>>> authored the message using those keys. Which is the point. >>>> >>> >>> One nuance that might be worth noting though: >>> >>> If you've marked the key with extractable == false, you at least know >>> that you're talking to the same *device* at time Y as at time X. (Modulo >>> things like key extraction/cloning below the JS layer, which aren't part of >>> our threat model.) >>> >>> I'm not sure how useful that property is given that there many be >>> Mallory's code running on that device, but... >>> >>> --Richard >>> >>> >> No, you don't have that guarantee - as the spec is clear to call out >> that UA's are free to store the key however they want. >> >> If we're talking only in the context of "Mallory, the remote attacker", >> then sure, you have a guarantee of the same UA, >> >> >> Which, as it happens, is one of the useful guarantees we are interested >> in for our service, even without anything else. >> >> ...Mark >> >> but not necessarily the same origin (or same application code), since >> as you note, Mallory may have postMessage'd the key to herself for later >> use, and can always send requests to the "Victim" at will later. >> >> >> >> -- >> Peersm : http://www.peersm.com >> node-Tor : https://www.github.com/Ayms/node-Tor >> GitHub : https://www.github.com/Ayms >> >> > > -- > Peersm : http://www.peersm.com > node-Tor : https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > >
Received on Thursday, 27 March 2014 21:02:25 UTC