Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

> Since the certificate carries the bank's legitimate public key, when you use it to generate your shared secret only the bank will be able to decrypt it.

I appreciate it isn't central to the article's purpose, but this is wrong, and as background noise it contributes to a misunderstanding that causes other problems every time it occurs.

I will describe what's done in TLS 1.3 because that's clearer, but you should know this isn't how your TLS 1.2 server actually works in real use today either.

TLS encryption doesn't care about these certificates. (Elliptic curve) Diffie-Hellman is used to agree random keys, and the random keys encrypt everything. In TLS 1.3 nobody even says anything about certificates before that step happens - the certificates are sent encrypted.

So why have certificates at all? Because without them you're having a secure conversation... but you don't know who you are having a conversation with. So now we're definitely communicating securely with someone let's check it's who we expected. In TLS 1.3 the server (and optionally client) can send a certificate, claiming some identity, and then they sign the transcript (a record of everything said so far) with the corresponding private key, in effect saying "This is proof you are having this conversation with me".

That seems just a little bit picky. The author of the article already points out that the purpose of the certificates is to avoid the man-in-the-middle attack.

It is also, factually, a description of how RSA key agreement works.

Firstly, if we're being picky it isn't factually a description of RSA key agreement. For RSA kex the shared secret is just picked by the client (hopefully at random) and then it's encrypted with that RSA public key for transmission in order to achieve the implied authentication. You don't use the public key to generate the shared secret as this quote suggests.

More importantly, nobody still does this. If you're writing new HTTPS Servers, in Go, in 2021, your only reason to even implement RSA kex is that it's technically still Mandatory To Implement for TLS 1.2 and so it's a compliance consideration. You definitely shouldn't have clients that still think RSA kex is a good idea.

The reason I care though isn't about being technically correct, it's because people get the idea that this sort of 1990s hybrid crypto is really how things work, and then they're confused because of course that's not how anything they actually use works. At best this means TLS gets a reputation for being more mysterious or complicated than it really is, and at worst we get cargo cult solutions that make "sense" based on the misunderstanding but alas aren't actually secure in practice.

Fair though, today I learned getting rid of RSA and using opinionated DH parameters is a significant aspect of what defines TLS 1.3.

Thank you for the comment! I will revise that part of the post to avoid confusion.

But even in Diffie-Helman the DH parameters will be signed with with server's RSA key. This is how the client can be sure who it is negotiating with. As such the bank analogy for public key crypto is still worthwhile.

Also your comment seems like an odd nitpick given the author states in the first paragraph:

>"I won't be covering how the protocol itself works in detail here ..."

And in the sentence before that they also linked to previous articles they've published on both DH and RSA which go heavily into the details of how each works. It's seems to me like they actually were being quite careful to avoid the very thing you are being critical of even though it was obvious that it wasn't the point in the article.

Reply on news.ycombinator.com