"Anyone that can intercept a handshake has the keys"
Sorry but no, that's complete and utter nonsense. In fact, even if you have the server's private key you cannot passively snoop on a TLS-encrypted connection unless it uses some ancient ciphersuite that doesn't include DH/ECDH. And active interception (i.e. a man-in-the-middle-attack) requires having a valid certificate for the domain that the client is trying to connect to. In other words, to be able to decrypt TLS traffic to random domains you need to be able to generate valid certs for them hence you need the private key of a certificate authority trusted by the client, typically achieved (in cases where the interception is desired by the user, e.g. for debugging) by generating your own CA and installing its cert into the client as a trusted root certificate.
There have been rare cases where real-world traffic interception happened using a real CA key but those got caught very quickly and resulted in the CA responsible getting distrusted by all browsers, see e.g. DigiNotar (whose infrastructure got compromised by attackers who subsequently used it to issue unauthorized certs) and CNNIC (which willfully issued an unconstrained CA certificate to a company that used it for TLS interception). And nowadays it has become _extremely_ easy to detect rogue CA behaviour thanks to a mechanism called "Certificate Transparency" (introduced by Google in response to previous CA incidents) which requires CAs to submit certificates to public append-only logs before those certificates are accepted as valid by browsers that implement CT (Chrome and Safari), enabling admins to track whether unauthorized certificates have been issued for their domains.
Biting the hand that feeds IT
