6 ms·

Web Cryptography API posted as W3C working draft

64 points by sweis 14y ago

zrail 14y ago
This looks like it could be pretty useful. The main argument against crypto in the browser is that if you send crypto js over a non encrypted channel it's vulnerable to MITM, and if you're going over HTTPS you might as well just send it plaintext. If the browsers themselves implemented secure crypto it could be a boon to certain types of applications, for example S/MIME in webmail.
- daeken 14y ago
  I don't see this adequately defending against MITMs or XSS. You can still hook all the crypto primitives, inject new keys, or pull out existing keys from the same origin. This scares me; a lot of people are going to assume this is secure against attacks that it simply isn't there to defend against.
  - jlgreco 14y ago
    I could see this being useful/safe iff the browser refuses to allow it to be used unless everything is already using HTTPS.
    - tptacek 14y ago
      It could be useful if it was nailed to HTTPS. But it wouldn't be safe; it leaves too much to content-controlled Javascript. When you've got HTTPS working, the threat model left to solve is, "can I trust the server not to fuck me with a subtly broken cryptosystem". This API doesn't address that problem; it admits to more broken cryptosystems than sound ones.
      - jlgreco 14y ago
        Fair point. I would say locking it down to HTTPS is required, but not sufficient.
  - morroccomole 14y ago
    Indeed, browser also implement things like CSP - and we need browser to also support additional security measures that enhance the API
daeken 14y ago
While I think this could be a good thing in theory, exposing such a low level crypto interface is likely to end in pain. How many people can combine the building blocks into something secure? And MITM/XSS still give up the keys to the castle. I'd much rather see a simple high-level interface to crypto in the browser.
- emily37 14y ago
  The plan is to first nail down this low-level API, and then specify a high-level interface wrapping the low-level one that makes it much easier for most developers to get things right. http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0065.html http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug...
  - daeken 14y ago
    I don't think that's enough -- in fact, I think it's worse. The low level API inherently has a broken trust model, and using that as a stopgap is going to be worse for security than it not existing at all. If anything, the low level API should be tabled in favor of the high level.
  - tptacek 14y ago
    I see talk in those threads about how the "low-level API" is logistically the right move, but not a lot of talk about how it's right in an engineering sense. Is it possible that the cart is pulling the horse here?
rbellio 14y ago
Something else to read in my free time now :)
tptacek 14y ago
From the two quick reads I've given it, not a fan. On the plus side: building this stuff directly into the browser image may prevent people from deploying Javascript Cryptography, which is unsafe in every environment. Systems built on the Web Cryptography bindings are at least anchored to trusted implementations of algorithms already resident in the browser. On the minus side: * These interfaces may have the opposite effect. Mass-market websites must support all popular browser versions. For the foreseeable future, we won't have a market in which the majority of browsers implement something like this. Unfortunately, the web crypto API is something that is very easy to duplicated "cosmetically" in Javascript. So the net effect of this in the medium term is probably negative. That said, I also understand that we've got to rip off the band-aid sometime. * The interface is low-level. I appreciate that an API like this naturally wants to be low-level, to maximize the number of things you can build on top of it. But most of the things you could build on these particular building blocks will have subtle vulnerabilities. Not only that, but the interface doesn't appear to provide even the "envelope" abstraction that other low-level libraries present. * So much of this design is low-level that enough of the security of the system is left to content-controlled Javascript, so many (perhaps most) of the systems that rely on this library are going to have exactly the same problem as they do now. * The low-level building blocks they provide are incoherent. If you wanted to just expose all the little knobs and wires that it could take to implement pre-existing (and broken) crypto standards, then an interface which pretends that AES-CBC and AES-GCM are two different ways to do the same thing makes some sense; some systems need GCM, and some need CBC, and you don't have to give much thought to the difference. But this library doesn't even do that; for instance, it doesn't look like callers control the nonce in AES-CTR. A good way to sum this up: if this API succeeds in the market, there are going to be deployed, widely used systems that use RSA for bulk encryption. If I was elected Archduke of Browser Crypto, the first standard I would propose would be a simple authenticated AES-encrypted envelope format; something like, PBKFD2-keyed HMAC-SHA256-authenticated AES-CBC messages. Something impossible to screw up, because Javascript authors aren't asked to make design decisions.
- daeken 14y ago
  Totally agreed on every level. If you want to add security, you do it from the high level; exposing low-level building blocks is a recipe for disaster.
prodigal_erik 14y ago
I'd like to see a declarative way to sign or encrypt parts of a document or form submission to protect them from tampering by the origin server. But js is under the control of the origin server, so I don't see this as a security advance over TLS, just a crutch for broken apps with no non-js mode using HTTP correctly.
- tptacek 14y ago
  Minimizing the number of trusted components that are under the control of Javascript is part of the point of the interface, but as Cody and I have pointed out (and obviously you as well), there's enough left to JS that the interface doesn't really solve that problem. One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections.
  - daeken 14y ago
    > One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections. I support the cupcake tax (we can discuss numbers later), but I think making it work only for HTTPS connections makes that seem like the biggest issue. I believe that XSS attacks, simply due to the ease of discovery and exploitation, are a much bigger issue here. Hijacking connections to a site (whether via MITM, DNS redirection, whatever) isn't easy, but XSS is downright trivial in most cases; it's definitely the biggest concern in my mind.
    - tptacek 14y ago
      I think if you don't nail Web Crypto to TLS, people will see it as an alternative to TLS, which it isn't.
      - sleevi 14y ago
        For what it's worth, while I object to your tax-and-spend approach with cupcakes, I do subscribe to your TLS-only newsletter for key-utilizing operations, and had proposed that already. Keyless operations are more of a gray area of policy rather than security. For example, should hashing require TLS? I think not, since there are non-crypto-but-still-useful applications of cryptographic hashes and random numbers (eg: name-based or PRNG-based UUIDs as described in RFC 4122). However, splitting the interface into TLS and HTTP segments is something that has its own issues. It's possible that a compromise might be the "Secure Cookie" equivalent of specifying policy (HTTPS-only) when creating or importing keys, but I hope it doesn't come to that. That said, I'm also a big proponent of requiring some sort of sane CSP settings to also narrow the scope of the API usage ( http://www.w3.org/2012/webcrypto/track/issues/21 http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.
romaniv 14y ago
I would very much rather see higher-level crypto, especially crypto that could be used declaratively, without JavaScript. (Something similar to Enigmail, but for browsers.) Heck, there isn't even a standard way to verify a hash on downloaded files.
deleted 14y ago
[deleted]
- daeken 14y ago
  That's DOMCrypt, not the WebCrypto API. Two very different approaches to the problem.
darkhorn 14y ago
By the way keygen http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_keygen http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_k...
kzahel 14y ago
Yes, we all know cryptography is incredibly easy to get wrong. That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto. I think the main benefit of this will be improved speed over existing standard javascript crypto support libraries (sjcl, jsbn).
- daeken 14y ago
  > That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto. In this case, it absolutely does. Not only will people most likely put them together incorrectly (which isn't the API's fault), but it doesn't provide any defense against cases where the browser is running code not intended by the server, e.g. MITM and XSS. As soon as the browser is running bad code, this is 99.9% equivalent to existing JS crypto (the exception being the secure RNG). The trust model here just doesn't hold up.
  - sleevi 14y ago
    While the trust issue you raise is legitimate, it's not one we're trying to solve (or at least, not yet, and I hope not soon) You may ask then, "Well, what's the point of this API if you're not going to solve it?" The answer is that solution for the trust model issues are being addressed concurrently and, unquestionably, more adequately, in other W3C working groups, the WHATWG, the IETF, and other such standards bodies. For example, the development of Content Security Policy, the hopeful formation of the Sys Apps WG, offline apps that execute in their own origin, the proposed <browser> tag, the formalization of the things as basic as the web origin concept (RFC 6454), Web Intents as a service-agnostic IPC mechanism. There are a number of efforts going on to address and enhance the overall security and utility of the platform. Our WG is providing just one small part of the overall picture. Every concern about malleability of the run-time applies equally so when you're not doing JS crypto - native or browser-mediated. Storing something in localStorage/IndexedDB? Well, now you've got an opportunity to turn transient XSS into persistent, stored XSS. Does that mean localStorage/IndexedDB are doomed to failure or fundamentally flawed for not addressing that? No. Are cookies complete and utter garbage due to all of their known issues? No (or at least, not /complete/ ;-) I recognize that there are a variety of security decisions and trade-offs being presented in this API, decisions that will have to be made by site authors. It may be that this is completely unacceptable - and I would hope, by now, that people feeling that way would be sending mail to public-webcrypto-comments@w3.org saying that. However, for the use cases that have been presented and expressed, the trade-offs have been understood and are, thus far, acceptable, which is why this WG has continued the path its on and why the participants have, so far, believed in the utility of the API. As far as algorithms go, our failure (thus far) to include DSA is hardly going to be the end of SSH (for which many still use DSA keys), just like our failure (thus far) to include ElGamal or MD5 are not going to mean the death of PGP/GPG. However, by not including them, it also means that there's no way to implement such applications, even if all other concerns were controlled for - and that would suggest our API is incomplete and a less-compelling alternative. Suggesting that failing to implement PKCS#1 v1.5 will finally mean the end of it is unrealistic. So far, our stated goal has been to produce a low-level API that has applicability for a number of situations, as captured both in the use cases of the draft and in the companion use cases wiki. The core functionality starts with "Secure key store. Secure RNG". In order to support "secure key store," it's necessary to define what you can do with these "secure" keys, hence, the specification of certain operations and algorithms. We're not (thus far) attempting to create an enveloping format - that's something that the IETF JOSE WG is doing, and that various groups and standards ranging from XML DSig to CMS to S/MIME have done or tried to do. We're not (thus far) attempting to create the one-true-perfectly-safe-full-of-cryptographic-kittens-and-puppies "box" and "unbox" - it's interesting, unquestionably useful, but getting two crypto-geeks, let alone a hundred, to agree on what that operation is composed of is a sisyphean effort. Should it be Sals20 or AES-GCM? Why not Blowfish? Monkey knife-fighting appears more civilized then some of those crypto-political discussions - and makes more progress to boot. By providing the low-level API, application developers can make an informed decision on what that "box" looks like to them, or relying on cryptographically skilled developers to produce libraries (ala KeyCzar, ala NaCl) to do that for them. Yes, it also means that uninformed developers can start smashing things together and leading to wonderfully painful crypto-explosions. However, you don't see WebGL being lamented for its lack of built-in VRML support (I hope...), and neither do I think this API should include the kitchen sink, bathtub, robe, and matching slippers in order to be useful and applicable for many web developers. Yes, screwdrivers are wonderfully useful tools, and it's fairly hard to hurt yourself with one. But sometimes you really need a hammer - or a chainsaw, or a level, or a drill - in order to do the right job. This API is merely a toolbox - dangers and all - not the One True Solution to all the Bad Crypto.
morroccomole 14y ago
For the record this is only the First Public Working Draft. A lot can and will change. We are looking for commentary to understand if we are on the right track
wglb 14y ago
So is this "Bad Crypto made Easy"?

64 points by sweis 14y ago

zrail 14y ago

This looks like it could be pretty useful. The main argument against crypto in the browser is that if you send crypto js over a non encrypted channel it's vulnerable to MITM, and if you're going over HTTPS you might as well just send it plaintext. If the browsers themselves implemented secure crypto it could be a boon to certain types of applications, for example S/MIME in webmail.

daeken 14y ago
I don't see this adequately defending against MITMs or XSS. You can still hook all the crypto primitives, inject new keys, or pull out existing keys from the same origin. This scares me; a lot of people are going to assume this is secure against attacks that it simply isn't there to defend against.
- jlgreco 14y ago
  I could see this being useful/safe iff the browser refuses to allow it to be used unless everything is already using HTTPS.
  - tptacek 14y ago
    It could be useful if it was nailed to HTTPS. But it wouldn't be safe; it leaves too much to content-controlled Javascript. When you've got HTTPS working, the threat model left to solve is, "can I trust the server not to fuck me with a subtly broken cryptosystem". This API doesn't address that problem; it admits to more broken cryptosystems than sound ones.
    - jlgreco 14y ago
      Fair point. I would say locking it down to HTTPS is required, but not sufficient.
- morroccomole 14y ago
  Indeed, browser also implement things like CSP - and we need browser to also support additional security measures that enhance the API

daeken 14y ago

While I think this could be a good thing in theory, exposing such a low level crypto interface is likely to end in pain. How many people can combine the building blocks into something secure? And MITM/XSS still give up the keys to the castle. I'd much rather see a simple high-level interface to crypto in the browser.

emily37 14y ago
The plan is to first nail down this low-level API, and then specify a high-level interface wrapping the low-level one that makes it much easier for most developers to get things right. http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0065.html http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug...
- daeken 14y ago
  I don't think that's enough -- in fact, I think it's worse. The low level API inherently has a broken trust model, and using that as a stopgap is going to be worse for security than it not existing at all. If anything, the low level API should be tabled in favor of the high level.
- tptacek 14y ago
  I see talk in those threads about how the "low-level API" is logistically the right move, but not a lot of talk about how it's right in an engineering sense. Is it possible that the cart is pulling the horse here?

rbellio 14y ago

Something else to read in my free time now :)

tptacek 14y ago

From the two quick reads I've given it, not a fan. On the plus side: building this stuff directly into the browser image may prevent people from deploying Javascript Cryptography, which is unsafe in every environment. Systems built on the Web Cryptography bindings are at least anchored to trusted implementations of algorithms already resident in the browser. On the minus side: * These interfaces may have the opposite effect. Mass-market websites must support all popular browser versions. For the foreseeable future, we won't have a market in which the majority of browsers implement something like this. Unfortunately, the web crypto API is something that is very easy to duplicated "cosmetically" in Javascript. So the net effect of this in the medium term is probably negative. That said, I also understand that we've got to rip off the band-aid sometime. * The interface is low-level. I appreciate that an API like this naturally wants to be low-level, to maximize the number of things you can build on top of it. But most of the things you could build on these particular building blocks will have subtle vulnerabilities. Not only that, but the interface doesn't appear to provide even the "envelope" abstraction that other low-level libraries present. * So much of this design is low-level that enough of the security of the system is left to content-controlled Javascript, so many (perhaps most) of the systems that rely on this library are going to have exactly the same problem as they do now. * The low-level building blocks they provide are incoherent. If you wanted to just expose all the little knobs and wires that it could take to implement pre-existing (and broken) crypto standards, then an interface which pretends that AES-CBC and AES-GCM are two different ways to do the same thing makes some sense; some systems need GCM, and some need CBC, and you don't have to give much thought to the difference. But this library doesn't even do that; for instance, it doesn't look like callers control the nonce in AES-CTR. A good way to sum this up: if this API succeeds in the market, there are going to be deployed, widely used systems that use RSA for bulk encryption. If I was elected Archduke of Browser Crypto, the first standard I would propose would be a simple authenticated AES-encrypted envelope format; something like, PBKFD2-keyed HMAC-SHA256-authenticated AES-CBC messages. Something impossible to screw up, because Javascript authors aren't asked to make design decisions.

daeken 14y ago
Totally agreed on every level. If you want to add security, you do it from the high level; exposing low-level building blocks is a recipe for disaster.

prodigal_erik 14y ago

I'd like to see a declarative way to sign or encrypt parts of a document or form submission to protect them from tampering by the origin server. But js is under the control of the origin server, so I don't see this as a security advance over TLS, just a crutch for broken apps with no non-js mode using HTTP correctly.

tptacek 14y ago
Minimizing the number of trusted components that are under the control of Javascript is part of the point of the interface, but as Cody and I have pointed out (and obviously you as well), there's enough left to JS that the interface doesn't really solve that problem. One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections.
- daeken 14y ago
  > One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections. I support the cupcake tax (we can discuss numbers later), but I think making it work only for HTTPS connections makes that seem like the biggest issue. I believe that XSS attacks, simply due to the ease of discovery and exploitation, are a much bigger issue here. Hijacking connections to a site (whether via MITM, DNS redirection, whatever) isn't easy, but XSS is downright trivial in most cases; it's definitely the biggest concern in my mind.
  - tptacek 14y ago
    I think if you don't nail Web Crypto to TLS, people will see it as an alternative to TLS, which it isn't.
    - sleevi 14y ago
      For what it's worth, while I object to your tax-and-spend approach with cupcakes, I do subscribe to your TLS-only newsletter for key-utilizing operations, and had proposed that already. Keyless operations are more of a gray area of policy rather than security. For example, should hashing require TLS? I think not, since there are non-crypto-but-still-useful applications of cryptographic hashes and random numbers (eg: name-based or PRNG-based UUIDs as described in RFC 4122). However, splitting the interface into TLS and HTTP segments is something that has its own issues. It's possible that a compromise might be the "Secure Cookie" equivalent of specifying policy (HTTPS-only) when creating or importing keys, but I hope it doesn't come to that. That said, I'm also a big proponent of requiring some sort of sane CSP settings to also narrow the scope of the API usage ( http://www.w3.org/2012/webcrypto/track/issues/21 http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.

romaniv 14y ago

I would very much rather see higher-level crypto, especially crypto that could be used declaratively, without JavaScript. (Something similar to Enigmail, but for browsers.) Heck, there isn't even a standard way to verify a hash on downloaded files.

deleted 14y ago

[deleted]

daeken 14y ago
That's DOMCrypt, not the WebCrypto API. Two very different approaches to the problem.

darkhorn 14y ago

By the way keygen http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_keygen http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_k...

kzahel 14y ago

Yes, we all know cryptography is incredibly easy to get wrong. That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto. I think the main benefit of this will be improved speed over existing standard javascript crypto support libraries (sjcl, jsbn).

daeken 14y ago
> That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto. In this case, it absolutely does. Not only will people most likely put them together incorrectly (which isn't the API's fault), but it doesn't provide any defense against cases where the browser is running code not intended by the server, e.g. MITM and XSS. As soon as the browser is running bad code, this is 99.9% equivalent to existing JS crypto (the exception being the secure RNG). The trust model here just doesn't hold up.
- sleevi 14y ago
  While the trust issue you raise is legitimate, it's not one we're trying to solve (or at least, not yet, and I hope not soon) You may ask then, "Well, what's the point of this API if you're not going to solve it?" The answer is that solution for the trust model issues are being addressed concurrently and, unquestionably, more adequately, in other W3C working groups, the WHATWG, the IETF, and other such standards bodies. For example, the development of Content Security Policy, the hopeful formation of the Sys Apps WG, offline apps that execute in their own origin, the proposed <browser> tag, the formalization of the things as basic as the web origin concept (RFC 6454), Web Intents as a service-agnostic IPC mechanism. There are a number of efforts going on to address and enhance the overall security and utility of the platform. Our WG is providing just one small part of the overall picture. Every concern about malleability of the run-time applies equally so when you're not doing JS crypto - native or browser-mediated. Storing something in localStorage/IndexedDB? Well, now you've got an opportunity to turn transient XSS into persistent, stored XSS. Does that mean localStorage/IndexedDB are doomed to failure or fundamentally flawed for not addressing that? No. Are cookies complete and utter garbage due to all of their known issues? No (or at least, not /complete/ ;-) I recognize that there are a variety of security decisions and trade-offs being presented in this API, decisions that will have to be made by site authors. It may be that this is completely unacceptable - and I would hope, by now, that people feeling that way would be sending mail to public-webcrypto-comments@w3.org saying that. However, for the use cases that have been presented and expressed, the trade-offs have been understood and are, thus far, acceptable, which is why this WG has continued the path its on and why the participants have, so far, believed in the utility of the API. As far as algorithms go, our failure (thus far) to include DSA is hardly going to be the end of SSH (for which many still use DSA keys), just like our failure (thus far) to include ElGamal or MD5 are not going to mean the death of PGP/GPG. However, by not including them, it also means that there's no way to implement such applications, even if all other concerns were controlled for - and that would suggest our API is incomplete and a less-compelling alternative. Suggesting that failing to implement PKCS#1 v1.5 will finally mean the end of it is unrealistic. So far, our stated goal has been to produce a low-level API that has applicability for a number of situations, as captured both in the use cases of the draft and in the companion use cases wiki. The core functionality starts with "Secure key store. Secure RNG". In order to support "secure key store," it's necessary to define what you can do with these "secure" keys, hence, the specification of certain operations and algorithms. We're not (thus far) attempting to create an enveloping format - that's something that the IETF JOSE WG is doing, and that various groups and standards ranging from XML DSig to CMS to S/MIME have done or tried to do. We're not (thus far) attempting to create the one-true-perfectly-safe-full-of-cryptographic-kittens-and-puppies "box" and "unbox" - it's interesting, unquestionably useful, but getting two crypto-geeks, let alone a hundred, to agree on what that operation is composed of is a sisyphean effort. Should it be Sals20 or AES-GCM? Why not Blowfish? Monkey knife-fighting appears more civilized then some of those crypto-political discussions - and makes more progress to boot. By providing the low-level API, application developers can make an informed decision on what that "box" looks like to them, or relying on cryptographically skilled developers to produce libraries (ala KeyCzar, ala NaCl) to do that for them. Yes, it also means that uninformed developers can start smashing things together and leading to wonderfully painful crypto-explosions. However, you don't see WebGL being lamented for its lack of built-in VRML support (I hope...), and neither do I think this API should include the kitchen sink, bathtub, robe, and matching slippers in order to be useful and applicable for many web developers. Yes, screwdrivers are wonderfully useful tools, and it's fairly hard to hurt yourself with one. But sometimes you really need a hammer - or a chainsaw, or a level, or a drill - in order to do the right job. This API is merely a toolbox - dangers and all - not the One True Solution to all the Bad Crypto.

morroccomole 14y ago

For the record this is only the First Public Working Draft. A lot can and will change. We are looking for commentary to understand if we are on the right track

wglb 14y ago

So is this "Bad Crypto made Easy"?