Re:Now I understand why almost no one uses encrypted email
by austincheney on Friday April 17, 2020 @03:27AM
(#22896953)
This website explains the distinct “pipes” better and more precisely than does the Wikipedia article: https://hpbn.co/transport-layer-security-tls/
Those pipes are the asymmetric handshake to exchange the shared secret and the symmetric encryption provided by that shared secret.
Certificates do not provide encryption and thus are not a “pipe”. Certificates are used to prove the identity of one of the end points (the server).
Re:Now I understand why almost no one uses encrypted email
by tialaramex on Friday April 17, 2020 @11:08PM
(#22905029)
Those two "pipes" you're talking about aren't one inside the other, the key agreement just takes place sequentially before the key is used because of casuality.
It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more.
In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said.
Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode).
Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to.
There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.