Hacker News new | past | comments | ask | show | jobs | submit login

When you say access, do you mean intercept and decrypt?

I’m fairly sure root certificates are only affect the browser’s trust of a server’s public key and is not involved in the security of encryption—for that you’d still need the server’s individual private key.

And even then I’m still not sure if the private key is sufficient given modern encryption protocols. Hopefully someone else can chime in to elaborate here.




Regarding your last point, even if you can monitor (but not alter) all traffic on the Internet, in real-time, all of the time, forever, that does not let you decrypt any traffic (now or in the future) if the parties are using forward-secret ciphersuites (those whose key exchange is performed with ephemeral private keys, instead of the key corresponding to the public key in the certificate).

At the moment, these are the DHE- and ECDHE- ciphersuites in TLS1.2 and below, and are mandatory in TLS1.3 (RSA key exchange was removed).

This only becomes a concern if your adversary can alter traffic in real-time (because they can use a compromised root to obtain their own certificate for the service you're talking to, and pretend to be them to you, and you will then negotiate your keying material with them instead, which naturally gives them the ability to decrypt the traffic before forwarding it along to its intended destination). Several technologies, such as HPKP, CAA, and CT, are designed to eliminate or mitigate this.


Fun TLS 1.2 (and earlier) caveat:

If you can obtain the theoretically short-lived but certainly not truly ephemeral STEK (Session Ticket Encryption Key) from a server, then any sessions which enabled session tickets even if those tickets were never used can be decrypted using the STEK.

This doesn't work in TLS 1.3




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: