TLS runs over a reliable transport (TCP), which means that we must
first complete the TCP three-way handshake, which takes one full
With the TCP connection in place, the client sends a number of
specifications in plain text, such as the version of the TLS protocol
it is running, the list of supported ciphersuites, and other TLS
options it may want to use.
The server picks the TLS protocol version for further communication,
decides on a ciphersuite from the list provided by the client,
attaches its certificate, and sends the response back to the client.
Optionally, the server can also send a request for the client’s
certificate and parameters for other TLS extensions.
Assuming both sides are able to negotiate a common version and cipher,
and the client is happy with the certificate provided by the server,
the client initiates either the RSA or the Diffie-Hellman key
exchange, which is used to establish the symmetric key for the ensuing
The server processes the key exchange parameters sent by the client,
checks message integrity by verifying the MAC, and returns an
encrypted Finished message back to the client.
The client decrypts the message with the negotiated symmetric key,
verifies the MAC, and if all is well, then the tunnel is established
and application data can now be sent.
It should theoretically be possible to obtain the session key on either the Sender or Receiver end of the communication ... however this key (should) only last the duration of the session (if not shorter due to renegotiation of a key). Most applications secure the storage of this session key so it can not easily be obtained.
It should be noted that the session key could also be used for a cipher other than AES ... see here