6 ms·

If so many services use Let's Encrypt, do you think there's a risk they become a target for sneaky surveillance activities?

upofadown 7y ago
It is much better to target a small and obscure certificate authority if you are interested in conducting wide scale MITM attacks. The entire system is only as strong as the weakest link.
- Polylactic_acid 7y ago
  Isn't this what certificate transparency was meant to solve?
cmrx64 7y ago
https://letsencrypt.org/docs/ct-logs/ https://letsencrypt.org/docs/ct-logs/ why target them when it's OSINT? :) [ed: compromise of their HSM would be bad and I didn't consider active attacks, only passive]
- Swtrz 7y ago
  Are there any documented cases of HSM breaches anywhere or involving a CA?
  - Rebelgecko 7y ago
    IIRC, the Diginotar attack (used to make a fake certs and MITM *.google.com for many Iranians) involved replacing some of the dll files used to interface with HSMs. Dunno if it's confirmed that this is how the bad certs were made.
  - tialaramex 7y ago
    Attackers had effective control over the DigiNotar CA before it was distrusted and eventually went bankrupt in, I think, 2011. They may not have been able to extract the keys from the HSM (this would probably require physical access) but they had the ability to cause issuance without accurate records kept so there's not a lot of practical difference. Incidents at WoSign/ StartCom presumably involved malfeasance by key staff. I guess that doesn't count as a breach unless you'd call it a "Bank raid" if the manager just empties the vault into his own car and flees. At Symantec they knew third parties had the independent ability to issue with any of their CAs but that was specifically contracted third parties (in particular a Korean firm named CrossCert) not just random people, it's just that issuance records weren't properly kept and oversight was inadequate. Again the ability to cause issuance isn't technically a breach, the keys stayed inside the HSM but it was possible to cause unrecorded issuance so there's not much moral difference.
  - dlgeek 7y ago
    tialaramex did a great job answering the second part of your question, so I'll take a swing at the first. I don't know of any public cases where an org has disclosed that an external attacker exfiltrated key material from an HSM. That being said, there have been a number of disclosed vulnerabilities against HSMs/vendors that could allow this sort of attack to happen. CVE-2015-5464 is my favorite of these. There are also plenty of attacks that compromise the servers that talk to the HSMs, which usually would give an attacker the ability to perform arbitrary crypto operations using the keys in the HSM with no restrictions and little-to-no audit trail. I also know of attacks where the compromised "servers" are part of the HSM itself, but outside of the crypto/FIPS boundary.
Dylan16807 7y ago
Like what? All the certs they issue are already public.
- zymhan 7y ago
  Just because the certs they issue are "public" doesn't mean the information can be decrypted. But if you compromise the security of a PKI, you can decrypt the traffic.
  - schoen 7y ago
    Only by misissuing certificates, which hopefully can be caught with CT nowadays. Let's Encrypt doesn't have the ability to decrypt subscribers' traffic.
    - tialaramex 7y ago
      Specifically, in SSL or with older (non-browser) TLS up to 1.2 the encryption of traffic depends on a session key which was itself encrypted using Public Key cryptography based on the public key in the certificate. The CA doesn't have the corresponding Private Key (if you use Let's Encrypt's popular Certbot tool it is minting that key on your machine and never sends it anywhere) and so it could not decrypt this message and get the session key. This is a bit clunky but it works. Bad guys who steal your key (from you not from Let's Encrypt) could retrospectively decrypt stuff though. In TLS 1.3 the session key is always chosen before any certificates go anywhere, using some flavour of elliptic curve Diffie Hellman key agreement - both sides agree on the same secret key without it being sent anywhere because Mathematics is Cool. So even if you were a fool and entrusted the Private Key corresponding to your web servers to somebody you shouldn't there's no way for bad guys to decrypt stuff without a live MITM attack. The middle ground (modern browser, co-operative server, but older TLS version) is in between, bad guys can't retrospectively decrypt but it is clunky and some stuff (e.g. certificates) is not encrypted at all.
      - zymhan 7y ago
        Thanks, that's a nice explanation
LukeShu 7y ago
A few years ago I attended a conference talk from one of the Let's Encrypt folks. At the end, when he took questions, someone asked something along the lines of "what if the government targets Let's Encrypt for sneaky surveillance things". And his reply was something along the lines of "We're partially founded by the EFF. The EFF is actively looking for organizations that the government has done that with, in order to sue the government." Edit: https://media.libreplanet.org/u/libreplanet/m/seth-schoen-lets-encrypt/ https://media.libreplanet.org/u/libreplanet/m/seth-schoen-le... the question is at 46:22.
joosters 7y ago
There's not much to spy on. It's not like LetsEncrypt generate your private keys and give them to you. They sign a request that you send them (and they don't get to ever see your actual private key). So an evil CA won't be able to crack your encrypted website. An evil CA can of course generate fake certificates for any hostname they like, but those people already exist. Have you taken a look at just how many different root CAs are out there, and are trusted by your OS/browser? It includes hundreds of companies and governments. Then there are even more (countless?) 'second level CAs' (I forget the proper term, sorry!) who can also generate and sign a trusted certificate for any hostname, because, while they aren't a root CA, their authority has been signed in turn by a top-level CA. The web of trust is very large and has many points of failure.
- paulddraper 7y ago
  > 'second level CAs' (I forget the proper term, sorry!) Perhaps intermediate CA. https://en.wikipedia.org/w/index.php?title=Intermediate_certificate_authorities&redirect=no https://en.wikipedia.org/w/index.php?title=Intermediate_cert...
- DaiPlusPlus 7y ago
  > So an evil CA won't be able to crack your encrypted website. If the evil CA is default-trusted by major OS and browser vendors then they can - with their own private key then do a MITM.
  - tgsovlerkhgsel 7y ago
    That would require them to issue a separate certificate. Certificate Transparency provides significant deterrence against that. They can either log it into Certificate Transparency (and include the SCT, the "receipt" for logging it, in the cert), or not do that. If they log it, the server operator can see (in the public CT logs) that a certificate was issued for his domain by someone else, and raise hell. If they don't log it, the certificate won't have an SCT. That means that software that enforces CT can treat the certificate as invalid, and if someone saw the cert on the wire, it would immediately appear suspicious since all Let's Encrypt certs are supposed to have an SCT. They could also get an evil CT log to issue a SCT without logging it, but that would generate irrefutable cryptographic proof of malfeasance of the CT log.

upofadown 7y ago

It is much better to target a small and obscure certificate authority if you are interested in conducting wide scale MITM attacks. The entire system is only as strong as the weakest link.

Polylactic_acid 7y ago
Isn't this what certificate transparency was meant to solve?

cmrx64 7y ago

https://letsencrypt.org/docs/ct-logs/ https://letsencrypt.org/docs/ct-logs/ why target them when it's OSINT? :) [ed: compromise of their HSM would be bad and I didn't consider active attacks, only passive]

Swtrz 7y ago
Are there any documented cases of HSM breaches anywhere or involving a CA?
- Rebelgecko 7y ago
  IIRC, the Diginotar attack (used to make a fake certs and MITM *.google.com for many Iranians) involved replacing some of the dll files used to interface with HSMs. Dunno if it's confirmed that this is how the bad certs were made.
- tialaramex 7y ago
  Attackers had effective control over the DigiNotar CA before it was distrusted and eventually went bankrupt in, I think, 2011. They may not have been able to extract the keys from the HSM (this would probably require physical access) but they had the ability to cause issuance without accurate records kept so there's not a lot of practical difference. Incidents at WoSign/ StartCom presumably involved malfeasance by key staff. I guess that doesn't count as a breach unless you'd call it a "Bank raid" if the manager just empties the vault into his own car and flees. At Symantec they knew third parties had the independent ability to issue with any of their CAs but that was specifically contracted third parties (in particular a Korean firm named CrossCert) not just random people, it's just that issuance records weren't properly kept and oversight was inadequate. Again the ability to cause issuance isn't technically a breach, the keys stayed inside the HSM but it was possible to cause unrecorded issuance so there's not much moral difference.
- dlgeek 7y ago
  tialaramex did a great job answering the second part of your question, so I'll take a swing at the first. I don't know of any public cases where an org has disclosed that an external attacker exfiltrated key material from an HSM. That being said, there have been a number of disclosed vulnerabilities against HSMs/vendors that could allow this sort of attack to happen. CVE-2015-5464 is my favorite of these. There are also plenty of attacks that compromise the servers that talk to the HSMs, which usually would give an attacker the ability to perform arbitrary crypto operations using the keys in the HSM with no restrictions and little-to-no audit trail. I also know of attacks where the compromised "servers" are part of the HSM itself, but outside of the crypto/FIPS boundary.

Dylan16807 7y ago

Like what? All the certs they issue are already public.

zymhan 7y ago
Just because the certs they issue are "public" doesn't mean the information can be decrypted. But if you compromise the security of a PKI, you can decrypt the traffic.
- schoen 7y ago
  Only by misissuing certificates, which hopefully can be caught with CT nowadays. Let's Encrypt doesn't have the ability to decrypt subscribers' traffic.
  - tialaramex 7y ago
    Specifically, in SSL or with older (non-browser) TLS up to 1.2 the encryption of traffic depends on a session key which was itself encrypted using Public Key cryptography based on the public key in the certificate. The CA doesn't have the corresponding Private Key (if you use Let's Encrypt's popular Certbot tool it is minting that key on your machine and never sends it anywhere) and so it could not decrypt this message and get the session key. This is a bit clunky but it works. Bad guys who steal your key (from you not from Let's Encrypt) could retrospectively decrypt stuff though. In TLS 1.3 the session key is always chosen before any certificates go anywhere, using some flavour of elliptic curve Diffie Hellman key agreement - both sides agree on the same secret key without it being sent anywhere because Mathematics is Cool. So even if you were a fool and entrusted the Private Key corresponding to your web servers to somebody you shouldn't there's no way for bad guys to decrypt stuff without a live MITM attack. The middle ground (modern browser, co-operative server, but older TLS version) is in between, bad guys can't retrospectively decrypt but it is clunky and some stuff (e.g. certificates) is not encrypted at all.
    - zymhan 7y ago
      Thanks, that's a nice explanation

LukeShu 7y ago

A few years ago I attended a conference talk from one of the Let's Encrypt folks. At the end, when he took questions, someone asked something along the lines of "what if the government targets Let's Encrypt for sneaky surveillance things". And his reply was something along the lines of "We're partially founded by the EFF. The EFF is actively looking for organizations that the government has done that with, in order to sue the government." Edit: https://media.libreplanet.org/u/libreplanet/m/seth-schoen-lets-encrypt/ https://media.libreplanet.org/u/libreplanet/m/seth-schoen-le... the question is at 46:22.

joosters 7y ago

There's not much to spy on. It's not like LetsEncrypt generate your private keys and give them to you. They sign a request that you send them (and they don't get to ever see your actual private key). So an evil CA won't be able to crack your encrypted website. An evil CA can of course generate fake certificates for any hostname they like, but those people already exist. Have you taken a look at just how many different root CAs are out there, and are trusted by your OS/browser? It includes hundreds of companies and governments. Then there are even more (countless?) 'second level CAs' (I forget the proper term, sorry!) who can also generate and sign a trusted certificate for any hostname, because, while they aren't a root CA, their authority has been signed in turn by a top-level CA. The web of trust is very large and has many points of failure.

paulddraper 7y ago
> 'second level CAs' (I forget the proper term, sorry!) Perhaps intermediate CA. https://en.wikipedia.org/w/index.php?title=Intermediate_certificate_authorities&redirect=no https://en.wikipedia.org/w/index.php?title=Intermediate_cert...
DaiPlusPlus 7y ago
> So an evil CA won't be able to crack your encrypted website. If the evil CA is default-trusted by major OS and browser vendors then they can - with their own private key then do a MITM.
- tgsovlerkhgsel 7y ago
  That would require them to issue a separate certificate. Certificate Transparency provides significant deterrence against that. They can either log it into Certificate Transparency (and include the SCT, the "receipt" for logging it, in the cert), or not do that. If they log it, the server operator can see (in the public CT logs) that a certificate was issued for his domain by someone else, and raise hell. If they don't log it, the certificate won't have an SCT. That means that software that enforces CT can treat the certificate as invalid, and if someone saw the cert on the wire, it would immediately appear suspicious since all Let's Encrypt certs are supposed to have an SCT. They could also get an evil CT log to issue a SCT without logging it, but that would generate irrefutable cryptographic proof of malfeasance of the CT log.