5 ms·

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

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.
    - briansmith 14y ago
      IIRC, that is exactly Netflix's interest in the API. Google for the "Netflix use case."
      - tptacek 14y ago
        I understand that now, after talking to David Dahl on twitter. That's extremely dispiriting. I wish you guys would think twice before caving on this issue, because while Netflix can benefit marginally from something like this, the Internet will be harmed to a much greater extent. There are a lot of site operators out there who are enthralled by mythologies about how expensive TLS needs to be and how easy it is to replace TLS. For what it's worth, at Dahl's suggestion (and because I was off work sick yesterday), I read every thread on the mailing list archive and saw the design issues that were batted around on this. I now think the overall goal of this effort is unfortunate and the effort is star-crossed. I have more respect for Eric Rescorla than anyone else I can think of working in standards, but interoperability with existing crypto is a terrible, terrible goal for a web crypto API. I'm not saying "no good can come of it", just that I can't think of any good that is likely to come of it and I can think of a lot of bad stuff.
- briansmith 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 am very interested in this idea, not only regarding this API, but also regarding camera/microphone APIs, where a MITM could cause all kinds of severe privacy issues. I know the idea has been discussed specifically in the context of WebRTC (can an active attacker inject JS into a page to turn on your camera & microphone and the feeds back to them?), but it seems like it may have already been shot down there.

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.
  - briansmith 14y ago
    IIRC, that is exactly Netflix's interest in the API. Google for the "Netflix use case."
    - tptacek 14y ago
      I understand that now, after talking to David Dahl on twitter. That's extremely dispiriting. I wish you guys would think twice before caving on this issue, because while Netflix can benefit marginally from something like this, the Internet will be harmed to a much greater extent. There are a lot of site operators out there who are enthralled by mythologies about how expensive TLS needs to be and how easy it is to replace TLS. For what it's worth, at Dahl's suggestion (and because I was off work sick yesterday), I read every thread on the mailing list archive and saw the design issues that were batted around on this. I now think the overall goal of this effort is unfortunate and the effort is star-crossed. I have more respect for Eric Rescorla than anyone else I can think of working in standards, but interoperability with existing crypto is a terrible, terrible goal for a web crypto API. I'm not saying "no good can come of it", just that I can't think of any good that is likely to come of it and I can think of a lot of bad stuff.
briansmith 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 am very interested in this idea, not only regarding this API, but also regarding camera/microphone APIs, where a MITM could cause all kinds of severe privacy issues. I know the idea has been discussed specifically in the context of WebRTC (can an active attacker inject JS into a page to turn on your camera & microphone and the feeds back to them?), but it seems like it may have already been shot down there.