How SSL works?


The Secure Socket Layer sits in between the application layer (such as HTTP or RMI) and the transport layer (usually TCP). It provides

encryption, authentication and session management services to the application layer.


The figure above shows its position in the TCP/IP four layer model. SSL is most often associated with HTTP( the ubiquitous HTTPS protocol)

but by no means is limited to this. Virtually all common Internet protocols – Telnet, SMTP, NNTP, FTP, LDAP etc can be used with secure sockets.

SSL is an Internet standard first developed by Netscape in 1994. IETF has more recently taken over SSL development and renamed it Transport

Layer Security (TLS). TLS version 1.0 is a minor development of SSL 3.0 (the protocol in fact identifies itself as SSL 3.1 during the negotiation phase).


SSL Handshaking


Setting up secure communication between client and server takes quite a bit of setting up. The encryption and authentication parts of SSL are optional

and a number of ciphers can be used for each. This cipher suite needs to be negotiated and then key information and (optionally) digital certificates

exchanged. SSL handshaking takes care of all this when the SSL connection is first established.


  1. The client sends a hello message to the server. This incorporates information about the highest SSL version the client supports and a list of supported

cipher suites.


  1. The server sends its response back to the client:


    1. A hello message incorporating information about the highest version of SSL and the best cipher suite supported by both client and server.
    2. Optionally a certificate chain if the server wishes to authenticate itself to the client.
    3. Optionally a certificate request if the server wants to authenticate the client. This is more often used in special applications and intranets than

in the Internet.

    1. The server public key is sent unless a certificate with a suitable public key has already been transmitted.
    2. A hello finished message to indicate that the response is finished.


  1. The client then checks the certificate chain sent by the server. If the client is a web browser and it cannot trace the certificate chain to a known

trusted Certificate Authority a security warning message pops up.

If the browser accepts the certificate chain the client will respond with:

a.       A certificate chain if the server requested it.

b.      A session key encrypted with the server’s public key. The session key is randomly generated for each SSL session and used for symmetric

encryption of data. If no RSA public key cipher is available, Diffie Hellman may be used for key agreement instead.

c.       Optionally, a certificate verify message. The client sends the server some signed information, the server can then use the client certificate to verify that

the client is in the possession of the private key corresponding to the certificate’s public key. This option is rarely used.

d.      A change cipher spec message indicating that the server should switch to encrypted mode. The client selects the strongest cipher supported by both parties.

e.       A finished message to indicate that the response is finished.


  1. The server checks the client’s certificate chain(if any), decrypts the session key and finally responds to the information sent by the client with:
    1. A change cipher spec message indicating that the client should switch to encrypted mode.
    2. A finished message to indicate that the SSL handshaking process is finished.


       At this point the SSL session is established and encrypted data can be exchanged between the client and the server. For all data a HMAC message authentication code is calculated to guarantee data authenticity and integrity. If the client is a browser, it will indicate that the connection is secure by displaying

a key symbol (Netscape) or a lock symbol (IE) in its status line.