Computer Security (UNIT IV )

Secure Socket Layer (SSL)

● The Secure Socket Layer (SSL) protocol is an Internet protocol for the secure exchange of
information between a Web browser and a Web server.
● SSL provides two basic security services: authentication and confidentiality.
● All the major Web browsers support SSL.
● The SSL layer is located between the application layer and the transport layer in the TCP/IP
protocol suite.
 The Working of SSL

SSL has three sub-protocols, namely the Handshake Protocol, the Record Protocol, and
the Alert Protocol.

1. The SSL 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.
● The handshake protocol consists of a series of messages between the client and the
server. Each of these messages has the format

● (a) Type (1 byte): This field indicates one of the ten possible message types as given
below.
● (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, as listed below
● The handshake protocol is actually made up of four phases. These phases are
1. Establish security capabilities
2. Server authentication and key exchange
3. Client authentication and key exchange
4. Finish

Phase 1. Establish Security Capabilities

● This first phase of the SSL handshake is used to initiate a logical connection and
establish the security capabilities associated with that connection.
● This consists of two messages, the client hello and the server hello.
● The client sends the client hello message to the server and waits for the server’s
response. Accordingly, the server sends back a server hello message to the client.

● Client Hello message: It consists of the following fields.

1. Version: It specifies the highest version of SSL that the client can support.
2. Random: It contains two sub-fields: ●
3. A 32-bit date-time field that identifies the current system date and time on the client
computer.
 4. A 28-byte random number generated by the random-number generator software built
inside the client computer.
5. 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.
6. Cipher suite: It contains a list of the cryptographic algorithms supported by the client
(e.g. RSA, Diffie-Hellman, etc.), in the decreasing order of preference.
7. Compression method: This field contains a list of the compression algorithms
supported by the client.

● Server Hello message: It contains the same fields as in the client hello message.
However, but with a different purpose.
1. Version: It specifies the lower of the versions suggested by the client and the highest
supported by the server. For instance, if the client had suggested version 3, but the
server also supports version 3.1, the server will select 3.
2. Random: It is the Random value generated by the server and has same structure as
that of Client Random number but is independent of the client’s Random value.
3. 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.
4. Cipher suite: It contains a single cipher suite, which the server selects from the list
sent earlier by the client.
5. Compression method: Contains a compression algorithm, which the server selects
from the list sent earlier by the client.

Phase 2. Server Authentication and Key Exchange

● The server initiates this second phase of the SSL handshake, and is the sole sender of all
the messages in this phase. The client is the sole recipient of all these messages.
● This phase contains four steps namely Certificate, Server key exchange, Certificate
request, and Server hello done.
1. Certificate: The server sends its digital certificate to the client so that client can
authenticate the server using the server’s public key from the server’s certificate.
2. Server Key Exchange: This message is optional. It is used only if the server does not
send its digital certificate to the client in step 1 above. In this, the server sends its public
key to the client (as the certificate is not available).
3. Certificate Request: The server can request for the client’s digital certificate. But this
message is optional because the client authentication in SSL is optional.
4. Server hello done: Server sends this message to client to indicate that its portion of the
hello message (i.e. the server 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. After sending this message, the server
waits for the client’s response

Phase 3. Client Authentication and Key Exchange

● The client initiates this third phase of the SSL handshake, and is the sole sender of all the
messages in this phase. The server is the sole recipient of all these messages.
● This phase contains three steps namely Certificate, Client key exchange, and Certificate
verify.
1. Certificate: It is an optional step and is performed only if the server has 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.
2. Client Key Exchange: In this, 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.
3. Certificate Verify: It is necessary only if the server has 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 (in Phase 1: Establish security capabilities) after hashing them
together using MD5 and SHA-1, and signs the result with its private key

Phase 4. Finish
● The client initiates this fourth phase of the SSL handshake, which the server ends.
● This phase contains four steps. 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 created and sent by the client in the Client key exchange
message, both the client and the server create a master secret.
● The client and server generate a 48-byte quantity called the master secret which is known
only to them. 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.

Finally, the symmetric keys to be used by the client and the server are generated.
 2. The SSL Record Protocol:

● The Record Protocol executes 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.
● Record 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.

Working of Record Protocol

● The SSL record protocol takes an application message as input. First, it fragments it into
smaller blocks, optionally compresses each block, adds MAC, encrypts it, adds a header
and gives it to the transport layer, where the TCP protocol processes it like any other TCP
block. At the receiver’s end, the header of each block is removed; the block is then
decrypted, verified, decompressed, and reassembled into application messages. These
steps are as follows:
1. Fragmentation: The original application message is broken into blocks of less than
or equal to 214 bytes.
2. Compression: The fragmented blocks are optionally compressed. The compression
process must not result in the loss of the original data, which means that this must be
a lossless compression mechanism.
3. Addition of MAC: Using the shared secret key established previously in the
handshake protocol, the Message Authentication Code (MAC) for each block is
calculated.
4. Encryption Using the symmetric key established previously in the handshake
protocol, the output of the previous step is now encrypted.
5. Append Header Finally, a header is added to the encrypted block. The header
contains the following fields:
➔ Content type (8 bits): It specifies the protocol used for processing the record
in the next higher level (e.g. handshake, alert, change cipher).
➔ Major version (8 bits): It specifies the major version of the SSL protocol in
use.
➔ Minor version (8 bits): It specifies the minor version of the SSL protocol in
use.
➔ Compressed length (16 bits): Specifies the length in bytes of the original
plain-text block (or the compressed block, if compression is used)
● The final SSL message now looks like below
 3. The SSL Alert Protocol
● 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 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.

List of Fatal Errors:

List of Non-fatal Errors

 Closing and Resuming SSL Connections

● Before ending communication, the client and the server inform each other that their side
of the connection is ending.
● Each party sends a Close notify alert to the other party. This ensures a graceful closure
of the connection.
● 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.