30 ms·

We Built Cages: TLS cert provisioning and secrets management in an enclave

5 points by banann 4y ago

8organicbits 4y ago
This is impressive and super informative, thank you! > The issued CA includes a name constraint so that the Cage can only issue a cert for {cage_name}.{app_uuid}.cages.evervault.com I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint you mention on the intermediary certificate should be honored, but any name constraints on the Cages root CA may not be (I'm not sure of there is one). As far as I know, there's no requirement to do so. The folks at BetterTLS have offered to track this behavior across different TLS clients, but I'm curious if you've tested any TLS client behaviors. > The Crypto API runs on loopback, and the user process can access it on 127.0.0.1:9999. This reminds me of the AWS Metadata API. If an attacker can trick the user process to read and leak data from that API, they can privilege escalate[2]. AWS hardened that API, which may be a good approach to follow [3]. [1] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [2] https://attack.mitre.org/techniques/T1552/005/ https://attack.mitre.org/techniques/T1552/005/ [3] https://dev.to/artis3n/how-aws-s-ec2-instance-metadata-v2-prevents-ssrf-3ip0 https://dev.to/artis3n/how-aws-s-ec2-instance-metadata-v2-pr...
- banann 4y ago
  Thanks for the response, some great points there! > I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint you mention on the intermediary certificate should be honored, but any name constraints on the Cages root CA may not be (I'm not sure if there is one). Our customers are currently using our clients that attest the connection and honour the name constraint. We'll document what wider support looks like before we release the product fully - we're still in beta atm. Thanks for the tip re BetterTLS! > This reminds me of the AWS Metadata API. If an attacker can trick the user process to read and leak data from that API, they can privilege escalate[2]. AWS hardened that API, which may be a good approach to follow [3]. The attack surface is much smaller than the metadata api due to it only being accessible on the enclave. When the crypto API sends the request to E3 it checks the token and attestation doc to ensure the request came from the right enclave (based on PCRs in the attestation doc), and also the expected IP. That being said I think adding an expected header in the API to mitigate SSRF makes a lot of sense and also blocking requests that have an X-Forwarded-For header.

5 points by banann 4y ago

This is impressive and super informative, thank you! > The issued CA includes a name constraint so that the Cage can only issue a cert for {cage_name}.{app_uuid}.cages.evervault.com I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint you mention on the intermediary certificate should be honored, but any name constraints on the Cages root CA may not be (I'm not sure of there is one). As far as I know, there's no requirement to do so. The folks at BetterTLS have offered to track this behavior across different TLS clients, but I'm curious if you've tested any TLS client behaviors. > The Crypto API runs on loopback, and the user process can access it on 127.0.0.1:9999. This reminds me of the AWS Metadata API. If an attacker can trick the user process to read and leak data from that API, they can privilege escalate[2]. AWS hardened that API, which may be a good approach to follow [3]. [1] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [2] https://attack.mitre.org/techniques/T1552/005/ https://attack.mitre.org/techniques/T1552/005/ [3] https://dev.to/artis3n/how-aws-s-ec2-instance-metadata-v2-prevents-ssrf-3ip0 https://dev.to/artis3n/how-aws-s-ec2-instance-metadata-v2-pr...

banann 4y ago
Thanks for the response, some great points there! > I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint you mention on the intermediary certificate should be honored, but any name constraints on the Cages root CA may not be (I'm not sure if there is one). Our customers are currently using our clients that attest the connection and honour the name constraint. We'll document what wider support looks like before we release the product fully - we're still in beta atm. Thanks for the tip re BetterTLS! > This reminds me of the AWS Metadata API. If an attacker can trick the user process to read and leak data from that API, they can privilege escalate[2]. AWS hardened that API, which may be a good approach to follow [3]. The attack surface is much smaller than the metadata api due to it only being accessible on the enclave. When the crypto API sends the request to E3 it checks the token and attestation doc to ensure the request came from the right enclave (based on PCRs in the attestation doc), and also the expected IP. That being said I think adding an expected header in the API to mitigate SSRF makes a lot of sense and also blocking requests that have an X-Forwarded-For header.