DSP IA 2: M-4

1) Explain SSL Architecture in detail.

SSL is a security protocol that provides a safe communication channel between a

client (like a web browser) and a server (like a website).
It works on top of TCP and ensures that data sent over the internet is private and
secure.

Structure of SSL

SSL is not a single protocol — it has two main layers:

1. SSL Record Protocol

• Provides the basic security services for data.

• Ensures confidentiality (through encryption) and message integrity (through

MAC).

• It takes the data from higher layers (like HTTP), breaks it into blocks, compresses
it (optional), adds a MAC, encrypts it, and sends it securely.

• On receiving, it decrypts, verifies, and reassembles the data.

2. Higher-Level Protocols

These manage the setup and control of SSL sessions and connections:

1. Handshake Protocol
 o Used at the start of a session.

o The client and server:

▪ Authenticate each other,

▪ Agree on the encryption and hashing algorithms,

▪ Generate shared secret keys.

2. Change Cipher Spec Protocol

o Very small protocol (only 1 byte).

o It tells the other side to start using the newly agreed encryption and
keys.

3. Alert Protocol

o Used to send warnings or error messages.

o Example: “bad_record_mac” or “handshake_failure”.

2) Explain SSL Handshake protocol in detail.

The Handshake Protocol is the most important and complex part of SSL.
It happens before any actual data (like website content) is sent.

Its main job is to make the client (browser) and server (website):

• Authenticate each other (prove identity)

• Agree on encryption and hashing algorithms

• Create shared secret keys to protect future communication

Structure

Each message in the handshake has:

• Type (1 byte): What kind of handshake message it is

• Length (3 bytes): Size of the message

• Content: The data or parameters sent

Phases of SSL Handshake

The handshake happens in 4 main phases:

Phase 1: Establish Security Capabilities

• The client starts by sending a message called ClientHello.

It includes:

o Version: Highest SSL version the client supports

o Random: A random number (used later to create secret keys)

o Session ID: To continue an old session or start a new one

o Cipher Suite: List of encryption algorithms the client supports

Purpose:
The client tells the server what it can handle (versions, ciphers, etc.).

Phase 2: Server Authentication and Key Exchange

• The server responds with:

o ServerHello: Chooses the SSL version and cipher from the client’s list

o Certificate: Sends its digital certificate (proves identity)

o ServerKeyExchange (optional): Sends public key info if needed

o ServerHelloDone: Indicates the server is done sending setup info

Purpose:
The client can now verify the server’s identity using the certificate.

Phase 3: Client Authentication and Key Exchange

• The client:

o Verifies the server’s certificate.

o Sends a ClientKeyExchange message — includes a pre-master secret (a

random number encrypted using the server’s public key).

o Optionally sends its own certificate for mutual authentication.

Purpose:
Both sides now have what they need to generate the master secret key.
Phase 4: Finish

• The client sends:

o ChangeCipherSpec message → tells server to start using the new

encryption keys.

o Finished message → verifies everything so far is correct.

• The server replies with:

o Its own ChangeCipherSpec message.

o Finished message.

4) Explain SSL Record Protocol Operation

• The SSL Record Protocol is a part of SSL (Secure Sockets Layer) that helps keep
messages safe when sent between a client (like your browser) and a web server.

• It works by taking application messages and doing these steps:

 o Fragmentation: Breaks large messages into smaller blocks (about 16,384
bytes or less).

o Compression (Optional): Compresses each block to save space (though

often, no compression is used).

o Message Integrity: Adds a Message Authentication Code (MAC) using a

shared secret key to check that the message isn’t changed or tampered
with.

o Encryption: Encrypts the block plus MAC with a symmetric encryption

algorithm, so only the right receiver can read it.

o Header Attachment: Adds a short header to each encrypted block that

explains what kind of data and which SSL version is used.

o Transmission: Sends the protected message in a TCP segment (normal

internet packet).

• On the receiving side, these steps are reversed:

o Reads the header to understand the message.

o Decrypts the block.

o Checks the MAC to confirm integrity.

o Decompresses (if compressed).

o Reassembles the small blocks into the original message.

5 ) Example of Master Key Generation in SSL

When a browser and server want to talk securely, they both create random values called
"nonces" and exchange them during the handshake.

1. The client (browser) creates a "premaster secret," a random number, and sends it
securely to the server (usually using the server’s public key from its certificate).

2. Both the client and the server then use the premaster secret and the two random
values (from the "hello" messages) to create the "master secret."

o This master secret is 48 bytes long and unique for the session.

3. The master secret is never sent over the network; both sides calculate it
independently using the premaster secret and the random numbers.

4. From this master secret, both the client and server generate all the session keys
needed for encrypting and protecting the rest of their communication.
6) Explain Different Key Exchange Methods Used in CipherSuite SSL

SSL CipherSuite uses several types of key exchange methods, including:

1. RSA Key Exchange:

o The client creates a random "premaster secret," then encrypts it with the
server’s public RSA key (from its certificate) and sends to server. Both
sides derive the master key from it.

2. Diffie-Hellman Key Exchange:

o Both client and server agree on a shared secret through Diffie-Hellman

math—never sending the actual secret, but working it out from exchanged
values. This can be anonymous (no authentication) or use certificates
(authenticated fixed/ephemeral DH).

3. Fortezza:

o A special key exchange for government/military use, based on proprietary

hardware. (Rarely used outside of official sites.)

4. Anonymous Key Exchange:

o Some cipher suites allow key exchange without authentication (e.g.,

anonymous Diffie-Hellman), but this is insecure and not normally
recommended.