How SSL Works

Nehal Hatem Eanass Abouzeid

Why SSL
The TLS protocol allows client-

server applications to communicate across a network in a way designed to prevent eavesdropping & tampering Tampering :(a device or process that makes unauthorized access to the protected object).

Why SSL
So the SSL provides : Confidentiality
By Encrypting data being sent between client and server, so that Only Client and Server can read sensitive data.

Integrity Protection Protect against modification of messages by an Unauthorized Party. Authentication Verify that a Computer you are talking to is who they claim to be. Servers are usually authenticated, and clients may be authenticated if requested by Confidentiality and Integrity are Done in the SSL Record Pro servers. Authentication is Done in the Handshake protocol .

How to ask for it

Two main ways to achieve this By using a different port number for (SSL/TLS) connections (e.g port 443 for HTTPS).
By using the regular port number and

have the client request that the server switch the connection to TLS using a protocol specific mechanism (e.g STARTTLS for mail and news prot

How This Is Done

When a Secured session is required by any of the

previous two means. A Handshake protocol is established between both sides, by the end of it data can be transferred secured What happens is as flow: 1. Computers agree on how to encrypt. 2. Server sends certificate. 3. Clients computer verifies the certificate. 4. Clients computer says start encrypting. 5. The server says start encrypting. 6. All messages after are then encrypted.

How SSL works

Client hello

Client PC

Server hello Certificate Server hello done Client key exchange Change cipher spec Finished Change cipher spec Finished

Web Server

Secure connection

How SSL works

HTTP

TCP

HTTP

HTTPS

TCP

SSL

HTTP

Common HTTP/HTTPS Connection

HTTP Connection on Port 80 Redirect to HTTPS HTTPS Connection on Port 443

Client PC

Server Certificate
Connection Established

Web Server

Requesting a Secure Connection

User clicks on a URL starting with https://.........................
SYN --------TCP_Port = 443 SYN+ACK
Client PC

ACK

Web Server

A secure connection is needed for this session. e.g. The browser establishes a TCP connection on the HTTPS TCP Port 443

SSL Handshake on the new TCP connection now begins

CLIENT_HELLO

SERVER_HELLO
Client PC

CERTIFICATE SERVER_DONE

Web Server

The client sends a CLIENT_HELLO command to the server, which includes: The highest SSL and TLS version supported by the client. (SSL 3.0 or TLS 1.0,1.1 or 1.2) Ciphers supported by the client. Encryption algorithm ( DES, 3DES,AES,IDEA,RC2-40) Hashing used for MAC (MD5,SHA) Note: The ciphers are listed in order of preference. Data compression methods that are supported by the client.

The session ID. If the client is starting a new SSL session, the session ID is 0. Key exchange method used for generating the public & private key used (RSA , Diffe-Hellman , DSA) Random data that is generated by the client for use in the key generation process. (to create Master Secret Key, That will be used after to create the encryption keys)
TLS is the developed version of SSL and it includes more alert messages than its predecessor. These alerts are more specific and better explain problems that either session endpoint (user or server) detects during secure

The server sends a SERVER_HELLO command to the client, which includes:

a response with all suitable choices for the Server from the lists the Client provided

The SSL or TLS version that will be used for the SSL session. The cipher that will be used for the SSL session. Data compression method that will be used for the SSL session.
SSL Version 3 and TLS have no compression algorithms defined at this time.

The session ID for the SSL session.

The server sends the CERTIFICATE command. This command includes: The server's certificate A chain of certificates beginning with the certificate of the certificate authority (CA) that assigned the server's certificate. (Optionally) The server sends the SERVER_DONE command. This command indicates that the server has completed this phase of the SSL handshake.

If client authentication will be performed, additional commands flow between the client and the server following the SERVER_DONE command.

Certificate Creation and Validation

A certificate has the following content:

1. The certificate issuers name (who it belongs to) 2. The subject : The entity for whom the certificate is being issued (Site, Company, Address) 3. The public key of the subject

4. Some time stamps

Server Obtaining the certificate

1. The server initiates a request for procuring a certificate from a trusted authority. This authority is called Certificate Authority (CA). Examples of CA : Verisign , Thawte , Trustwave etc.
2. The CA validates the Servers request after verifying related information through e.g. public records, This Takes Time.

3. CA creates a Signature for this certificate by condensing all details into a number (through Hashing) and encrypts the number by its private key

Client/Server Certificate Verification

1. The client contacts the certificate authority (CA) and provides the public key send by the Server for verification. 2. The certificate authority checks the public key and the hashed signature and if it can decrypt it using its private key then it is valid. Then it sends back the information (valid public key) to the client by encrypting the information using the CAs private key.

why is the encryption been done? The encryption is done to tell the client the CA is the one sending this information and the client can only decrypt it using the CAs public key. This means the information is authentic and is sent by the CA itself.

Client Verifies the Servers Certificate

CERTIFICATE_VERIFY CHANGE_CIPHER_SPEC FINISHED

Client PC

CHANGE_CIPHER_SPEC FINISHED

Web Server

Client informs the server that it has verified the server's certificate. The client sends the CHANGE_CIPHER_SPEC command. This command indicates that the contents of subsequent SSL record data sent by the client during the SSL session will be encrypted. i.e. All Data Sent after finishing Handshake will by encrypted

The client sends the FINISHED command.

This command includes a digest of all the SSL handshake commands that have flowed between the client and the server up to this point. Why ? To validate that none of the commands sent previously, which flow between the client and the server unencrypted, were altered in flight.

The server sends the CHANGE_CIPHER_SPEC command.

This command indicates that all subsequent data sent by the server during the SSL session will be encrypted. i.e. All Data Sent after finishing Handshake will by encrypted

The server sends the FINISHED command. This command includes a digest of all the SSL handshake

At this point, the client can send the symmetric secret key to the server after encrypting it with the public key received in the server's SSL Which then will be used for encryption of all data sent after

Applications for embedded SSL.

 The Internet-enabled vending machine can now become a reality SSL makes tampering with communications almost impossible.

Home automation systems can be Internet-enabled forgot to turn off the oven? Just log into your house from your computer at work and turn it off. SSL provides a secure means of protecting your home from hackers.
Readings from medical devices can be sent over a standard networkSSL protects your privacy. Make a telephone switch Web-configurableSSL encrypts all data, so no one monitoring the network can read your information. Since Web-based access means

 Remote-entry configurationchange the passcode on all the doors of a building simultaneously. SSL protects the passcode, allowing the doors to be connected to a standard corporate network, no need for expensive proprietary hardware! Television cable box monitoring/billingconnect a cable box to the Internet to monitor use and provide online billing. Utilities monitoring/billing (gas, electric, water) connect gas and electric meters to the Internet without the worry of users tampering with the

Referances
1. http://www.eventhelix.com/realtimemantra/networking/ssl.pdf
2. http://infosecminds.com/2010/03/16/ssl-how-it-works/ 3. http://video.google.com/videoplay?docid=7130470471741831613 4. http://ftp1.digi.com/support/documentation/0200054_d.pdf 5. http://tldp.org/HOWTO/pdf/SSL-Certificates-HOWTO.pdf