1

I read some topics where people claim to be able to decrypt SSL/TLS communications just by having the private key of the recipient.

But, I recently learned that a public key can, but should never encrypt something longer than the length of the associated private key. For instance, if the peer has a 2048 bits private key, it should never encrypt something longer than 255 bytes + NULL character. If one encrypts something longer than this, it would become vulnerable to attacks such as blocks cutting, redundancy analysis, etc. (I'm not expert in this domain, sorry for bad vocabulary).

That said, RSA handshake consists, in fact, in an exchange of public keys, followed by a secured exchange of an AES key, which is then used to encrypt all communications without any length cap. So RSA based exchange is only used at the handshake moment.

So, is this AES key exchange a part of the SSL/TLS protocol, or some servers will just never communicate with packets longer than their private key's length ?

If ALL SSL/TLS communications are done this way (AES thing), that means that to be able to decrypt packets, one needs to capture the handshake to decrypt the AES key, and if he doesn't, then having both private keys is just useless, right ?

But, that would also mean that having only one private key would be enough to decrypt the AES key, and therefore the whole communication. So, such a communication should involve 2 AES keys, one for each peer, right ? Then, just like an RSA exchange, A would encrypt packets with B's key, and vice versa.

What applies in real life ? Packets length limit or AES based communications ? One or two AES key(s) ?

Thank you to help me understand ! And sorry but english ain't my main langage.

Best regards.

1

That said, RSA handshake consists, in fact, in an exchange of public keys, followed by a secured exchange of an AES key, which is then used to encrypt all communications without any length cap. So RSA based exchange is only used at the handshake moment.

There is no RSA handshake but a TLS handshake. And there is usually no (bidirectional) exchange of public keys but in most cases only the server will provide a certificate which includes a public key.

The TLS handshake includes a key exchange which is usually either RSA key exchange or DH key exchange. With RSA key exchange the client will create some random secret, encrypt it with the servers public key (taken from the certificate) and send it to the server. The server then can extract this secret using its private key. The encryption key for the symmetric encryption (which can be AES but also something else) is then created based on this shared secret. This means with RSA key exchange only the private key of the server is needed to decrypt the sniffed traffic.

Note that modern implementations prefer to use DH key exchange. In this case knowing the servers private key will not help in decrypting the traffic. Instead the shared secret from this specific session is needed.

For a deeper understanding of TLS I recommend to study How does SSL/TLS work?.

  • Well, you say that with RSA, you need only the server's private key, but you actually need it to decrypt the shared secret right ? So you need to capture the handshake to decrypt anything, am I right ? Only symmetric keys are encrypted with RSA, but never are communications right ? And thanks for the link, i will read this ! I don't know DH, I will search about this too. – NdFeB Jun 10 '17 at 14:22
  • Ok, nvm i read your answer again and i understood better. So yeah, capturing the handshake is mandatory, and one cannot decrypt a communication if he didn't capture it. Thanks a lot! – NdFeB Jun 10 '17 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.