Now, we are going to capture packets with Wireshark when executing the script showed in the previous section to see the communication between the client and the domain server.

The following screenshot shows the interaction between the SSL client and the remote server:

Let's examine the SSL handshake process between the client and the server:

• In the first step of an SSL handshake, the client sends a Hello message to the remote server, saying what it is capable of in terms handling key files, encrypting messages, doing message integrity checks, and so on.
• Then, it sends the TLS version 1.0 and a random number to generate a master secret to encrypt the subsequent message exchanges. This is helpful for preventing any third-party from looking inside the packets.
• Finally, the random numbers that are seen in the hello messages are used to generate the pre-master secret, which both ends will process further to arrive at the master secret, and then use that to generate the symmetric key.

In the following screenshot, you can see that the client is presenting a set of 29 cipher suites to the server to choose relevant algorithms:

• In the second packet that's sent from server to client, the server selects the TLS_ECDHE_RSA_WITH_RC4_128_SHA cipher suite for the purpose of connecting to the client. This means that the server wants to use the RSA algorithm for key handling, RC4 for encryption, and SHA for integrity checking (hashing). This is shown in the following screenshot:

• In the second phase of the SSL handshake, the server sends an SSL certificate to the client. This certificate is issued by a CA, as mentioned in the Implementing the SSL client section. It contains a serial number, public key, validity period, and the details of the subject and the issuer.

The following screenshot show the remote server certificate, where we can see the server's public key inside the packet:

• In the third phase of the handshake, the client exchanges a key and calculates a master secret to encrypt the messages and continue further communications. The client also sends the request to change the cipher specification that was agreed on the previous phase. From that moment, the encryption of the message begins. The following screenshot shows this process:

• In the final part of the SSL handshake process, a new session ticket is generated by the server for the client's particular session. This happens due to a TLS extension where the client advertises its support by sending an empty session ticket extension in the Hello client message. The server answers with an empty session ticket extension in its Hello server message. This session ticket mechanism enables the client to remember the whole session state, and the server becomes less engaged in maintaining a server-side session cache.

The following screenshot shows an example for presenting an SSL session ticket, where we can see the Session Ticket Lifetime: