4 ms·

Request signing can be easily implemented in JavaScript for API requests with WebCrypto but it's not clear to me in what threat model it would be beneficial bec

Request signing can be easily implemented in JavaScript for API requests with WebCrypto but it's not clear to me in what threat model it would be beneficial because even if they keys are not exportable users don't generally see what actions did they authorize and as such they don't know what did they exactly sign.

colmmacc 9y ago
The main threats are protocol and network level. For example, request-smuggling and hi-jacking attacks can take the form of bugs in proxies and servers that allow requests to be smuggled because they don't escape newlines in headers and so on. With signing, these requests don't validate. It takes a much smaller TCB, and no connection state, to AAA a signed request, but with mutual-auth you need a state machine and the TCBs for X509/ASN.1 validation tend to be huge. That's not what you want in a security critical control. Honestly, enabling normal TLS mutual-auth likely degrades security in most cases, as it opens the server to whatever attacks the X509 processing is vulnerable to. ALTS mitigates this somewhat by using Protobufs, but that's still a very very big TCB. Compare that to say the TCB for validating HMAC or ed25519. Then there's the basic stuff I already pointed out, like sessions lasting longer than their credentials are valid for. The layering violation invites these kind of issues.
- Shoothe 9y ago
  Hmm... But you'll still use TLS for transport so adding mutual auth doesn't really increase the attack surface that much. (it still requires ugly ASN.1 and X.509). Or maybe you suggest using signed requests without TLS (plain HTTP)?
  - colmmacc 9y ago
    A TLS server without mutual auth doesn't need to do any online X509 processing, and only a tiny amount of ASN.1 (parsing the DH share, which is easy). It just serves certs, without parsing them. Mutual auth increases the TCB by a lot, the Kolmogorov complexity increases by several orders of magnitude.
    - Shoothe 9y ago
      Good point. Although I think the design was chosen because of the complexity of infrastructure behind your TLS server. Adding more things for the client to do so that you don't need to trust any intermediaries inside AWS data centers. (I'm not complaining, just an observation from my POV). (For the record in BeyondCorp all backend components are mutually authenticated but they still use sessions and U2F tokens so there are no trusted points).

colmmacc 9y ago

The main threats are protocol and network level. For example, request-smuggling and hi-jacking attacks can take the form of bugs in proxies and servers that allow requests to be smuggled because they don't escape newlines in headers and so on. With signing, these requests don't validate. It takes a much smaller TCB, and no connection state, to AAA a signed request, but with mutual-auth you need a state machine and the TCBs for X509/ASN.1 validation tend to be huge. That's not what you want in a security critical control. Honestly, enabling normal TLS mutual-auth likely degrades security in most cases, as it opens the server to whatever attacks the X509 processing is vulnerable to. ALTS mitigates this somewhat by using Protobufs, but that's still a very very big TCB. Compare that to say the TCB for validating HMAC or ed25519. Then there's the basic stuff I already pointed out, like sessions lasting longer than their credentials are valid for. The layering violation invites these kind of issues.

Shoothe 9y ago
Hmm... But you'll still use TLS for transport so adding mutual auth doesn't really increase the attack surface that much. (it still requires ugly ASN.1 and X.509). Or maybe you suggest using signed requests without TLS (plain HTTP)?
- colmmacc 9y ago
  A TLS server without mutual auth doesn't need to do any online X509 processing, and only a tiny amount of ASN.1 (parsing the DH share, which is easy). It just serves certs, without parsing them. Mutual auth increases the TCB by a lot, the Kolmogorov complexity increases by several orders of magnitude.
  - Shoothe 9y ago
    Good point. Although I think the design was chosen because of the complexity of infrastructure behind your TLS server. Adding more things for the client to do so that you don't need to trust any intermediaries inside AWS data centers. (I'm not complaining, just an observation from my POV). (For the record in BeyondCorp all backend components are mutually authenticated but they still use sessions and U2F tokens so there are no trusted points).