6 ms·

Most companies need to be able to answer the question, "is this client one of ours," when protecting sensitive resources. Most companies will instead answer th

Most companies need to be able to answer the question, "is this client one of ours," when protecting sensitive resources. Most companies will instead answer the question, "is the client on our network," and pretend that it was the same question. The fact that it clearly is not has some very obvious security implications and attack vectors that we've been living with for decades. Beyondcorp tries to more directly answer the original question about device identity rather than subbing in the network question in its place. The fact that this approach is novel says a lot about the maturity of our industry.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
colmmacc 9y ago
Even the question "Is this client one of ours?" is a bad question to ask. A much better question is "Is this specific action authorized and authenticated?". When you only authenticate a client, with a mechanism such as TLS Mutual-Auth, or ALTS, you still aren't really authenticating the actions, just the channel. That leaves the system open to request smuggling attacks, hi-jacking attacks, context-mismatch attacks (TLS is particularly cumbersome here, because authentication contexts can change mid-request), layering violations like credential lengthening problems (do you tear down a previously opened connection when the credential used to establish it expires or is revoked?), and vulnerabilities in the channel authentication mechanism (e.g. X509 and ASN1 are both notorious problem areas). I work at AWS, so I'm biased, but it seems much stronger to me to use a system that AAA's each action, like a request signing protocol (ours is https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html https://docs.aws.amazon.com/general/latest/gr/signature-vers... ). Request signing systems like that authenticate each action, which is very granular, it permits strong offline signing (just like my iPhone banking app does), and it's agnostic to the details of networks and clients and things like hi-jacking and smuggling just can't work. Of course, today's browsers aren't really set up for this; they don't support built-in request signing, but I still find it a little weird to see VPNs/networks traded for a model whose expiry date also went by years ago.
- Shoothe 9y ago
  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.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

colmmacc 9y ago

Even the question "Is this client one of ours?" is a bad question to ask. A much better question is "Is this specific action authorized and authenticated?". When you only authenticate a client, with a mechanism such as TLS Mutual-Auth, or ALTS, you still aren't really authenticating the actions, just the channel. That leaves the system open to request smuggling attacks, hi-jacking attacks, context-mismatch attacks (TLS is particularly cumbersome here, because authentication contexts can change mid-request), layering violations like credential lengthening problems (do you tear down a previously opened connection when the credential used to establish it expires or is revoked?), and vulnerabilities in the channel authentication mechanism (e.g. X509 and ASN1 are both notorious problem areas). I work at AWS, so I'm biased, but it seems much stronger to me to use a system that AAA's each action, like a request signing protocol (ours is https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html https://docs.aws.amazon.com/general/latest/gr/signature-vers... ). Request signing systems like that authenticate each action, which is very granular, it permits strong offline signing (just like my iPhone banking app does), and it's agnostic to the details of networks and clients and things like hi-jacking and smuggling just can't work. Of course, today's browsers aren't really set up for this; they don't support built-in request signing, but I still find it a little weird to see VPNs/networks traded for a model whose expiry date also went by years ago.

Shoothe 9y ago
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.