After a SaaS company TLS handshake, application data is encrypted with a symmetric key both sides derived. Why is that bulk data not encrypted with the server long-term private key?
Select an answer to reveal the explanation.
Short Explanation
You do not lock a shipping container with the rare stamp you use to prove who you are. The server long-term private key is for authentication or key agreement, and the bulk data uses the symmetric traffic key both sides derived. The trap is thinking private keys are faster for bulk data, that the certificate encrypts the body, or that NAT supplies confidentiality.
Full Explanation
After the handshake, both sides protect application records with a symmetric traffic key they derived. The server long-term private key is not that bulk cipher. It stays off the wire and is used so the server can authenticate or take part in the key exchange. The reason is "The long-term private key is for authentication or key agreement, while bulk data uses the symmetric traffic key". Asymmetric operations are the heavy ones, which is why bulk data does not use the private key, so "Private keys are faster for bulk data, so the symmetric key exists only as a fallback after the handshake" has the cost reversed. The certificate carries the public key and the identity. It does not encrypt the application body, so "The server certificate itself encrypts the application body once the handshake is finished" fails. Network address translation rewrites addresses. It does not provide confidentiality, so "Network address translation supplies the confidentiality protecting that application data" fails. Exam caveat: on current handshakes the long-term private key authenticates the exchange, and an older RSA key-transport suite used it to decrypt a premaster secret; neither role is the symmetric cipher on the application records. Operational check: confirm the application data is protected by the traffic key established at the handshake, and confirm the long-term private key was not sent as the bulk key.