The document provides an overview of the Secure Socket Layer (SSL) protocol in 3 phases: 1. It explains how SSL works as an additional layer between the application and transport layers in the TCP/IP model to encrypt data in transit. 2. It describes the SSL handshake protocol which involves a series of messages to establish security capabilities, authenticate the server, and exchange encryption keys. 3. It outlines the 4 phases of the handshake protocol: establishing capabilities, server authentication and key exchange, client authentication and key exchange, and finishing the handshake by generating symmetric keys for encryption.

1. “The Fundamental of Secure
Socket Layer (SSL)”
By:
-Vishal Kumar
(CEH, CHFI, CISE, MCP)
info@prohackers.in
Part - 1

2. Topics to be Covered in this Presentation
• Introduction of Secure Socket Layer SSL
• The Position of SSL in the TCP/IP Suit
• Working of Secure Socket Layer
• Working of Handshake Protocol
• Phases of Handshake protocol
• Establish Security Capabilities
• Server Authentication and Key Exchange
• Client Authentication and Key Exchange
• Finish

3. Introduction:
The Secure socket Layer (SSL) protocol is an Internet protocol
for the secure exchange of information between a Web browser
and a Web server. It provides two basic security services:
Authentication and Confidentiality. SSL is developed by the
Netscape Corporation in 1994. Since then, it is become most
popular Web-Security mechanism. Currently SSL comes in three
versions 2, 3 and 3.1; the most popular of them is version 3
which is released in 1995.

4. The Position of SSL in TCP/IP Protocol Suit
The SSL layer is located between the application layer and the
transport layer. It is consider as an additional layer in TCP/IP
Suit.
As such, the communication between the various TCP/IP protocol
layers is now as shown below

5. The Position of SSL in TCP/IP Protocol Suit
Fig: SSL is located between application and transport layer

6. The Position of SSL in TCP/IP Protocol Suit
As we can see in the above image, the application layer of the
sending computer (X) prepares the data to be sent to receiving
computer (Y), as usual. However, unlike what happens in the
normal case, the application layer is not passed directly to the
transport layer now. Instead the application-layer data is passed
to the SSL layer. Here the SSL layer performs encryption on the
data received from the application layer (indicated by the Dark
Gray color), and also add its own encryption information header,
called SSL Header (SH) to the encryption data. We will later study
what exactly happens in this process.

7. The Position of SSL in TCP/IP Protocol Suit
After this, the SSL layer data (L5) become the input for the
transport layer. It adds its own header (H4) and passes it on to
the internet layer, and so on. This process happens exactly the
way it happens in the case of normal TCP/IP data transfer.
Finally, when the data reaches the physical layer, it is sent in the
form of voltage pulses across the transmission medium.
At the receiver’s end the process happens pretty similar to how it
happens in the case of normal TCP/IP connection, until it reaches
the new SSL layer. The SSL layer at the receiver’s end remove the
SSL Header (SH), decrypt the encrypted data and give the plain-
text data back to the application layer of the receiving computer.
Thus, only the application layer data is encrypted by the SSL.

8. Working of Secure Socket layer (SSL)
The SSL contains three
sub protocols.

9. 1. The Handshake Protocol
The handshake protocol of SSL is the first sub-protocol used by
the client and the server to communicate using an SSL-enabled
connection. This is similar to how Alice and Bob would first shake
hands with each other accompanied with a hello before they start
conversing.
SSL tunnel ..Hello
hi
Bob
Alice

10. Content of Handshake Protocol
The handshake protocol consists of a series of messages between the
client and the server. Each of these massages has the format
showing below.
Fig: format for the handshake protocol messages
As shown in the above figure, each handshake messages has three
fields, as follows:

11. Content of Handshake Protocol
(A). Type (1 byte): this fields indicate one of the ten possible
message types, mention in below table
S. No Message Type Parameters
1 Hello Request None
2 Client Hello Version, Random number, Session ID, Cipher Suit, Compression Method
3 Server Hello Version, Random number, Session ID, Cipher Suit, Compression Method
4 Certificate Chain of X05.9V3 Certificates
5 Server-Key Exchange Parameters, Signature
6 Certificate Request Type, Authorities
7 Server Hello Done None
8 Certificate verify Signature
9 Client-key Exchange Parameters, Signatures
10 Finished Hash Values

12. Content of Handshake Protocol
(B). Length (3 bytes): this field indicates the length of the message
in bytes.
(C). Content (1 or more bytes): this field contain the parameter
associated with the message, depending on the message type, as
listed in above table.

13. Phases of Handshake Protocol:
There are four phases of handshake protocol as shown in the
below image:

14. Phase 1. Establish Security Capabilities
Phase 1. Establish Security Capabilities – this first phase of SSL
Handshake protocol is used to initiate a logical connection and
establish the security capabilities associated with the connection.
This consists of two messages, the client hello and the server hello.

15. Phase 1. Establish Security Capabilities
As shown in the above figure, the process starts with a client hello
message from the client to server. It consists of the following
parameter:
• Version - This fields identify the highest version of SSL that the
client can support, this can be 2, 3, or 3.1.
• Random – This field is useful for later, actual communication
between the client and the server, it contains two sub-fields:
• A 32-bit date-time field that identifies the current system date and time on
the client computer.
• A 28-byte random number generated by the random-number generator
software built in the client computer.

16. Phase 1. Establish Security Capabilities
• Session Id – This is a variable-length session identifier. If these
fields contain non-zero value, it means that there is already a
connection between the client and the server, and the client
wishes to update the parameters of that connection. A zero value
in this field indicates that the client wants to create a new
connection with the server.
• Cipher Suit – This list contains a list of cryptographic algorithms
supported by the client (e.g. RSA, Diffie-Hellman, etc.) in the
decreasing order of preference.

17. Phase 1. Establish Security Capabilities
• Compression Method – This field contains a list of compression
algorithms supported by the client.
The client sends the client hello message to the server and wait
for the server’s response. Accordingly, the server sends back a
server hello message to the client. This message also contains the
same fields as in the client hello message. The server hello
message consists of the following fields:

18. Phase 1. Establish Security Capabilities
• Version – This fields identifies the lower of the version
suggested by the client and the highest supported by the server.
For example, if the client has suggested version 3, but the
server also supports version 3.1, the server will select 3.
• Random – This field has the same structure as the Random filed
of the client.
• Session id – If the session id value sent by the client was non-
zero, the server use the same value. Otherwise, the server
creates a new session id and put it in this field.

19. Phase 1. Establish Security Capabilities
• Cipher Suit – It contains the single cipher suit, which the server
selects from the list sent earlier by the client.
• Compression Method – It contains compression algorithms,
which the server selects from the list sent earlier by the client.

20. Phase 2. Server Authentication and Key-
Exchange
Phase 2. Server Authentication and Key-Exchange – The server
initiates the second phase of the SSL handshake protocol, and it is
the sole sender of all the messages in this phase. And the client is
the sole recipient of all the massages. This phase contains four
steps as shown in the below figure:

21. Phase 2. Server Authentication and Key-
Exchange
Let us discuss the four steps of this phase:
1. Certificate - In the first step (Certificate), the server sends its
digital certificate and the entire chain leading up to root CA
(Certificate Authority) to the client. This will help the client
to authenticate the server using the server’s public key from
the server’s certificate. The server’s certificate is mandatory
in all situations, except if the key is being agreed upon by
using Diffie-Hellman.

22. Phase 2. Server Authentication and Key-
Exchange
2. Server Key Exchange – This step is optional. It is used only if the
server does note sends its digital certificate to the client in step 1.
In this step the server sends its public key to client (as the
certificate is not available)
3. Certificate Request – In this step, the server can request for the
client’s digital certificate. The client authentication in SSL is
optional, and server may not always expect the client to be
authenticated. Therefore, this step is optional.

23. Phase 2. Server Authentication and Key-
Exchange
4. Server hello done – This message indicates to the client that
its portion of the hello message (the server hello message) is
complete. This indicated to the client that the client can now
(optionally) verify the certificates sent by the server, and ensure
that all the parameters sent by the server are acceptable. This
message does not have any parameters. After sending this
message, server waits for the client’s response.

24. Phase 3. Client Authentication and Key-
Exchange
Phase 3. Client Authentication and Key-Exchange – The Client
initiate this third phase of SSL handshake protocol, and is the sole
sender of all the messages of this phase. The server is the sole
recipient of all messages. The phase contains three steps which
are shown in the below figure.

25. Phase 3. Client Authentication and Key-
Exchange
Step 1: Certificate – This step is optional, this step is performed
only if the server has requested for the client’s digital
certificate. If the server has requested the client’s certificate,
and if the client does not have one, the client sends a No
Certificate message, instead of a Certificate message. It then is
up to the server to decide if it wants to still communicate or not.
Step 2: Client Key Exchange – Like the Server Key Exchange
message, this step allows the client to send information to server,
but in the opposite direction. This information related to the

26. Phase 3. Client Authentication and Key-
Exchange
symmetric key that both the parties will use in this session. Here
the client creates a 48-byte pre-master secret, and encrypts it with
the server’s public key and send this encrypted pre-master secret
to the server.

27. Phase 3. Client Authentication and Key-
Exchange
Step 3: Certificate Verify – This step is necessary only if the server
had demanded client authentication. As we know, if this is the
case, the client has already sent it’s certificate to the server.
However, additionally, the client also needs to prove to the server
that it is the correct and authorized holder of the private key
crossponding to the certificate. For this purpose, in this optional
step, the client combine the pre-master secret with the random
numbers exchange by the client and the server earlier (in Phase 1:
Establish Security Capabilities) after hashing them together using
MD5 and SHA-1, and signs the results its private key.

28. Phase 4. Finish
Phase 4. Finish – The Client initiate the fourth of the SSL handshake
protocol, which the server ends. This phase contains four steps as
shown in the below image. The first two messages are from the client:
Change cipher specs, Finished. The server responds back with two
identical messages: Change cipher specs, Finished.

29. Phase 4. Finish
Based on the pre-master secret that was created and sent by the
client in the Client key exchange message, both the client and
server create a master secret.
Before secure encryption and integrity verification can be
performed on records, the client and server need to generate
shared secret information known only to them. This value is 48-
byte quantity called the master secret. The master secret is used
to generate keys and secrets for encryption and MAC (Message
Authentication Code) computation. The master secret is calculated
after computing message digest of the pre-master secret, client
random and server random as shown in the below figure.

30. Phase 4. Finish

31. Phase 4. Finish
The technical specification of calculation master secret is as
follows:
Finally, the symmetric keys to be used by the client and the server
are generated. The conceptual process is shown below:
Fig: Symmetric-key generation concept

32. Phase 4. Finish
After this the first step (Change cipher specs) is confirmation form
the client that all is well its end, which is strengthens with the
Finished message. The server sends the same message to client.

33. Feedback
Thanks for reading this presentation
Please give us your feedback at
info@prohackers.in
Your feedback is most valuable for us for improving the presentation
You can also suggest the topic on which you want the presentation
Website: www.prohackers.in
FB page: www.facebook.com/theprohackers2017
Join FB Group: www.facebook.com/groups/group.prohackers/
Watch us on: www.youtube.com//channel/UCcyYSi1sh1SmyMlGfB-Vq6A