 SSL stands for Secure Sockets Layer.

It is a standard security technology that

establishes an encrypted link between a web server and a browser, ensuring that all
data transmitted between the server and the browser remains private and integral.
 It provides two basic security services: authentication and confidentiality.
 Netscape Corporation developed SSL in 1994. Since then, SSL has become the
world’s most popular Web-security mechanism.
 SSL is used to secure sensitive data such as login credentials, credit card
information, and other personal information.
 SSL provides for secure communication between client and server by allowing
mutual authentication, the use of digital signatures for integrity and encryption for
privacy.
 SSL protocol has different versions such as SSLv2.0, SSLv3.0, where SSLv3.0 has
an advantage with the addition of support for certificate chain loading.
 SSL 3.0 is the basis for the Transport Layer Security [TLS] protocol standard. SSL
is designed to make use of TCP to provide a reliable end-to-end secure service.
Only the application layer data is encrypted by SSL. The lower-layer
headers are not encrypted.
 SSL has three sub-protocols:
◦ Handshake Protocol
◦ Record Protocol
◦ Alert 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.
 The handshake protocol consists of a series of messages between the client
and the server. Each of these messages has the format :
 Each handshake message has three fields, as follows:
 (a) Type (1 byte) This field indicates one of the ten possible message types.
 (b) Length (3 bytes) This field indicates the length of the message in bytes.
 (c) Content (1 or more bytes) This field contains the parameters associated
with this message, depending on the message type.
 The handshake protocol is actually made up of four phases:
● Establish security capabilities
● Server authentication and key exchange
● Client authentication and key exchange
● Finish
 The process starts with a client hello message from the client to the server. It Consists of the
following parameters:
 ■ Version: This field identifies the highest version of SSL that the client can support.
 ■ Random: This field is useful for the 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 inside the
 client computer.
 ■ Session id: This is a variable-length session identifier. If this field contains a 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 suite: This list contains a list of the cryptographic algorithms supported by the client (e.g.
 RSA, Diffie-Hellman, etc.), in the decreasing order of preference.
 ■ Compression method :This field contains a list of the compression algorithms supported by the
 client.
 The server sends back a server hello message to the client. This message also
contains the same fields as in the client hello message.
 Version: This field identifies the lower of the versions suggested by the client and
the highest supported by the server.
 Random :This field has the same structure as the Random field of the client.
However, the Random value generated by the server is completely independent of
the client’s Random value.
 Session id: If the session id value sent by the client was non-zero, the server uses
the same value. Otherwise, the server creates a new session id and puts it in this
field.
 Cipher suite: Contains a single cipher suite, which the server selects from the list
sent earlier by the client.
 Compression method :Contains a compression algorithm, which the server selects
from the list sent earlier by the client.
 Certificate: The server sends its digital certificate and the entire chain leading
up to root CA 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.
 Server key exchange: It is optional. It is used only if the server does not send
its digital certificate to the client in step 1 above. In this step, the server sends
its public key to the client .
 Certificate request :the server can request for the client’s digital certificate. The
client authentication in SSL is optional, and the server may not always expect
the client to be authenticated.
 Server hello done: message indicates to the client that its portion of the hello
message is complete. This indicates 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, the server waits for the client’s
response.
 Certificate: It is optional. This step is performed only if the server had requested for the
client’s digital certificate. If the server has requested for 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 continue or not

 Client key exchange: It allows the client to send information to the server, but in the opposite
direction. This information is related to the 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 sends this encrypted pre-master secret to the server.

 Certificate verify: It is necessary only if the server had demanded client authentication.
As we know, if this is the case, the client has already sent its 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 corresponding to the certificate. For this purpose, in this
optional step, the client combines the pre-master secret with the random numbers exchanged
by the client and the server earlier after hashing them together using MD5 and SHA-1, and
signs the result with its private key.
 The client initiates this fourth phase of the SSL handshake, which the
server end.
 The first two messages are from the client:
Change cipher specs, Finished.
 The server responds back with two identical messages:
Change cipher specs, Finished.
• Based on the pre-master secret that was created and sent by the client in the Client key
exchange message, both the client and the server create a master secret.
• Before secure encryption or integrity verification can be performed on records, the client
and server need to generate shared secret information known only to them. This value is a
48-byte quantity called the master secret.
• The master secret is used to generate keys and secrets for encryption and MAC
computations. The master secret is calculated after computing message digests of the pre-
master secret, client random and server random,
After this, the first step (Change cipher specs) is a confirmation from the client
that all is well from its end, which it strengthens with the Finished message. The
server sends identical messages to the client.
 The Record Protocol in SSL comes into picture after a successful handshake is
completed between the client and the server.
 That is, after the client and the server have optionally authenticated each other
and have decided what algorithms to use for secure information exchange, we enter
into the SSL record protocol.
 This protocol provides two services to an SSL connection, as follows:
 (a) Confidentiality This is achieved by using the secret key that is defined by the
handshake protocol.
 (b) Integrity The handshake protocol also defines a shared secret key (MAC) that is
used for assuring the message integrity
 Fragmentation :The original application message is broken into blocks, so
that the size of each block is less than or equal to 2^14 bytes (16,384
bytes).
 Compression :The fragmented blocks are optionally compressed. The
compression process must not result into the loss of the original data,
which means that this must be a lossless compression mechanism.
 Addition of MAC :Using the shared secret key established previously in
the handshake protocol, the Message Authentication Code (MAC) for each
block is calculated. This operation is similar to the HMAC algorithm.
 Encryption: Using the symmetric key established previously in the
handshake protocol, the output of the previous step is now encrypted. This
encryption may not increase the overall size of the block by more than
1024 bytes.
 Append Header Finally, a header is added to the encrypted block. The header
contains the following fields:

1.Content type (8 bits) :Specifies the protocol used for processing the
record in the next higher level (e.g. handshake, alert, change cipher).

2. Major version (8 bits) :Specifies the major version of the SSL

protocol in use. For instance, if SSL version 3.1 is in use, this field contains
3.

3. Minor version (8 bits) Specifies the minor version of the SSL

protocol in use. For instance, if SSL version 3.0 is in use, this field
contains 0.

4.Compressed length (16 bits) Specifies the length in bytes of the original
plain-text block (or the compressed block, if compression is used).
 When either the client or the server detects an error, the detecting party
sends an alert message to the other party.
 If the error is fatal, both the parties immediately close the SSL connection .
 Both the parties also destroy the session identifiers, secrets and keys
associated with this connection before it is terminated.
 Other errors, which are not so severe, do not result in the termination of the
connection. Instead, the parties handle the error and continue.
• Each alert message consists of two bytes. The first byte signifies the
type of error. If it is a warning, this byte contains 1.
• If the error is fatal, this byte contains 2. The second byte specifies
the actual error.
 Before ending their communication, the client and the server must inform each
other that their side of the connection is ending.
 When a party receives this alert, it must immediately stop whatever it is doing,
send its own Close notify alert and end the connection from its side as well.
 If an SSL connection ends without a Close notify from either party, it cannot be
resumed.
 The handshake protocol in SSL is quite complex and time consuming, as it
uses asymmetric-key cryptography. Therefore, if desired, a client and a server
can decide to reuse or resume an earlier SSL connection, rather than creating a
fresh one with a new handshake.
 However, for this to be possible, both the parties must agree on the reuse. If
either party feels that it is dangerous to reuse the earlier connection, or if the
other party’s certificate has expired since the last connection, it can force the
other party to perform a fresh handshake.
 As per the SSL specifications, any SSL connection should not be reused
after 24 hours in any case.
 Transport Layer Security (TLS) is an IETF standardization
initiative, whose goal is to come out with an Internet standard
version of SSL.
 Netscape wanted to standardize SSL, and hence handed the
protocol over to IETF. There are subtle differences between
SSL and TLS.
 However, the core idea and implementation are quite similar.
TLS is defined in RFC 2246.