3 ms·
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.
by NovemberWhiskey 6y ago
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.
- 0xEFF 6y agoFair though, today I learned getting rid of RSA and using opinionated DH parameters is a significant aspect of what defines TLS 1.3.
- tialaramex 6y agoFirstly, 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.