3 ms·

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

by 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
  - schoen 7y ago
    > a session key which was itself encrypted using Public Key cryptography based on the public key in the certificate This all depends on the ciphersuite used by the client and server. In TLS 1.2 some ciphersuites use forward-secret methods (typically "DHE" and "ECDHE"), and some don't. In TLS 1.3 you always get the benefits that you mention, but in TLS 1.2 and earlier you sometimes get them. :-)
    - wolf550e 7y ago
      ECDHE or DHE with TLSv1.2 is in practice not "sometimes" but "almost all the time". See https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/ "Forward Secrecy" is not supported on 2.1% of sites.

by 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
- schoen 7y ago
  > a session key which was itself encrypted using Public Key cryptography based on the public key in the certificate This all depends on the ciphersuite used by the client and server. In TLS 1.2 some ciphersuites use forward-secret methods (typically "DHE" and "ECDHE"), and some don't. In TLS 1.3 you always get the benefits that you mention, but in TLS 1.2 and earlier you sometimes get them. :-)
  - wolf550e 7y ago
    ECDHE or DHE with TLSv1.2 is in practice not "sometimes" but "almost all the time". See https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/ "Forward Secrecy" is not supported on 2.1% of sites.