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.