Find out Browser's AES generated key on SSL/TLS

Question

When it comes to TLS handshakes. first of all I'm wondering how the AES keys which are responsible for encrypting data is generated? is it generated randomly on the browser and it's securely sent to HTTPS server or server is responsible for generating those keys? Secondly is there any way to actually find out those AES keys which browser(for example Chrome) uses for encrypting data (after SSL/TLS authentication successfully handled)?

Answer 1

This depends on the Key exchange algorithm being used.

When RSA key exchange is used, the key is randomly generated by the client and then encrypted using the server's certificate. When using RSA key exchange, the server has very little say on the session key.

Modern TLS configuration usually recommends Diffie Hellman, which is more appropriately called key agreement protocol because the Session key is calculated using random inputs from both the client and server.

Both Firefox and Chrome have a feature to dump the Session key to a file, by setting the SSLKEYLOGFILE environment variable.

Answer 2

0 ms

TLS runs over a reliable transport (TCP), which means that we must first complete the TCP three-way handshake, which takes one full roundtrip.

56 ms

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.

84 ms

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.

112 ms

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 session.

140 ms

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.

168 ms

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.

reference

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