This is the first packet which is sent from the client to the server. The client tells the server that he wants to establish a secure connection and informs the server about all cipher suites which are supported by the client. Following picture shows the client hello more in detail:
One Cipher Suite could be:
That means that this suite uses RSA for Key Exchange. As symmetric cipher this suite uses AES with a keysize of 256 Bit. As mode of operation CBC is used, and SHA256 as hash algorithm.At the beginning of the connection, the server does not know which suites are supported by the client and vice versa. As the client wants to establish the connection, it is his task to tell the server about all supported cipher suites.
- server_hello: After the client_hello, the server answers with server_hello. Following picture shows it in detail:
The server decides which suite he would like to use. In the given example he decides to use TLS_RSA_WITH_AES_256_CBC_SHA256.
- Server Authentication: The server sends its certificate to the client which then can test wether the certificate is valid or not.
- Key Exchange: When TLS_RSA is used, the client generates a random Pre Master Secret (PMS) which is sent to the server encrypted with the public key of the server. The server is able to decrypt the encrypted PMS with its private Key. Both, server and client then derive a common secret from the PMS.
- The rest of the communication gets encrypted symmetrically with AES_256_CBC.
All in all, this mechanism seems to be quite secure. Authenticity is provided through the certificate and confidentiality is provided through the symmetric encryption. However, a closer look reveals that it’s not that secure after all:
In my opinion, one of the current major risks of SSL is making use of RSA for the encryption of the symmetric key. If a weak RSA key has been used, or some third know about the private key, all the traffic can be decrypted:
As mentioned above at the beginning of a TLS communication, SSL uses RSA for authentication. But unfortunately, RSA is also used for Key Exchange. Actually RSA is only intended to be used for authentication and not for Key Exchange. There are much better protocols for that problem. Diffie-Hellman is a very common key exchange protocol. But Diffie-Hellman is not used by SSL by default. So the symmetric connection depends exclusivley on the secrecy of the private key.
If Diffie Hellman would be used, a third party is not able to decrypt the connection, even if he knows about the private key. The following picture shows a simple SSL connection – remember: Wireshark still knows my private key!
Unfortunately Diffie-Hellman Key Exchange doesn’t get used very often, though all modern browser do support it.
Dear SSL developers… In future versions of SSL, please disallow Key Exchange without Diffie-Hellman or any other kind of perfect forward secrecy by default. Do not argue by backward compatibility. Argument with security. Disallow medium and weak ciphers.
Check your configuration using nice tools like SSL Test.
Maybe it’s generally time for a new secure protocol like SSL. Without all that inherited waste.
Nice article on this topic: SSL: Intercepted today, decrypted tomorrow