I think I'll buy my own copy today. :-)

I just noticed two days ago that my bank, for example, uses an RSA key exchange and I was kind of dismayed about the non-forward-secret sessions. But I don't know what I could tell them as a customer that would make them care about this problem. (I don't think my theoretical knowledge of why their key exchange method is bad will really help, compared to some kind of industry or governmental guidance that says "this technology is obsolete and everyone should stop using it", or, even better, "this technology is obsolete and banks should stop using it".)

Ultimately, I think the only way to kill the RSA key exchange is via a protocol revision, which is exactly what they've done in TLS 1.3. Sure, it will take a few years, but it will happen eventually.

I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

It's amazing how strong a motivation a grade or ranking can sometimes be. We saw this a lot with EFF's privacy practices report

https://www.eff.org/who-has-your-back-government-data-reques...

where companies were sometimes willing to make real changes to earn an extra star.

> I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

Oh yeah, that was something they complained about a lot with mandatory PFS in the TLSWG. :-(

Why do they need this for their consumer-facing sites, though? The theory over in the working group was about monitoring activities of bank employees on third-party web sites (I thought), rather than about monitoring activities of bank customers on the bank's own web site.

I don't see how this proves anything as a MITM attack would be able to do this just fine. Perhaps you mean this is where the CA-Cert comes in as the client can then verify that the process has not be tampered as the attacker can not sign with the matching CA-cert?

But that's only where the chain of trust begins. As the next step, the client must now verify that the certificate had been issued by a CA they trust, and they do that by recursively verifying the signature of each issuer in the certificate chain (along a few other things) until they reach a CA that's trusted by default (because it's in the client's root store).

Just to complicate things further: TLS 1.2 and earlier support many key exchange options, which implement key agreement and authentication in potentially different ways. For example, some key exchanges don't use certificates but rely on pre-shared keys. Another example, in the RSA key exchange the server proves ownership of the private key by being able to successfully handshake, and so on. TLS 1.3 made some improvements in this area and the key exchange process has been streamlined. My point here is that there are many other details to take into account, but I am trying to keep my explanations at a higher level.

(1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the difference is that at least with DH, in theory only /new/ sessions can be attacked (MitM impersonating going forward), but older sessions can't be opened up.

(2) Doesn't this mean that now the client needs a keypair & certificate? Otherwise, how does the client sign? And where does the client key pair come from? I'm pretty sure my browsers (i.e., clients) don't have their own keys & certificates.

TIA for answering my silly questions.

Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete.

The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete.

(2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.

To drill deeper in the the handshake, however, both client and server do sign the initial handshake (with the final negotiated session secret, effectively). The idea is that you need to ensure that the handshake hasn't been tampered with. An active network attacker could have changed the original TLS connection request (ClientHello) to force usage of a particular cryptographic component they know how to break. For example, SSL v2 had no handshake protection which is why someone in control of the network could always enforce the weakest encryption (only 40 bits).

One important point I would make is that my book doesn't dissect the protocols in detail. There is only one chapter (about 50 pages) dedicated to the protocol and I wanted to cover it at a level that virtually everyone will want to understand. If you want more than that, hundreds of pages won't be enough; in the end you will have to dive into the dozens of RFCs, and so on. What I do do, is point to those RFCs so that you at least know where to find the additional documentation. IIRC there are more than 600 links in the book and they can all be found here (automatically extracted from the DocBook XML manuscript): https://fsty.uk/bulletproof-ssl-and-tls

My realisation was that, in practice, actual protocol flaws are not the weakest link. Instead, there are hundreds of different problems everywhere in the ecosystem, so you need to look at the issues in the protocol, but also in the certification authorities and the certificate issuance process, SSL/TLS stacks, clients, browsers, servers, libraries, development and configuration practices, and so on. My book is thus very practical and examines all these aspects that you need to understand at at least some level if you want to use TLS.

BTW, please note that I will send you a free digital copy of the book if you buy the paperback _anywhere_ and send me the receipt. The benefit of the digital edition is that it's typically much more current than the paperback. In fact, the digital edition is fully up to date at the moment. I published a complete revision just yesterday.

In TLS 1.3, the full handshake is one RTT without any tricks; resumption also. There is also a 0-RTT resumption, but it sacrifices security for speed. Lots of people are unhappy about it.

If you do want to eavesdrop, you have several options. For one, you can terminate the TLS traffic, access it, then create another entirely separate TLS session to send it elsewhere. This is easier with a reverse proxy, in which case the proxy is the server. If you want to transparently intercept client-initiated sessions you have to install your root CA key in each client device.

Going back to servers, another option is private RSA key sharing, which allows for passive decryption, but works only with the RSA key exchange. Finally, you can also play with session ticket keys. If you share those, and enable session tickets, you'll also be able to passively decrypt. This last option works even with DHE/ECDHE key exchanges.