SSL / TLS
Secure Socket Layer / Transport Layer Security
Complete Exam-Ready Notes | 20-Mark Answer
1. Introduction and Definition
SSL (Secure Sockets Layer) was developed by Netscape to provide security when
transmitting information over the Internet. It is a protocol layer placed between a reliable
connection-oriented network layer protocol (e.g., TCP/IP) and the application protocol layer
(e.g., HTTP).
TLS (Transport Layer Security) is the successor and standardized version of SSL, based on
SSL 3.0. Both terms are often used interchangeably in practice.
Diagram: Position of SSL in the Protocol Stack
APPLICATION LAYER
[ HTTP ] [ LDAP ] [ IMAP ] [ ... ]
─────────────────────────────────────────
[ Secure Sockets Layer (SSL) ] ← SSL sits here
─────────────────────────────────────────
NETWORK LAYER: [ TCP/IP ]
SSL runs ABOVE TCP/IP and BELOW high-level application protocols
Key Services Provided by SSL
1. Authentication — Mutual authentication between client and server using digital
certificates.
2. Integrity — Use of digital signatures to ensure data is not tampered with during transit.
3. Confidentiality — Encryption of all data to ensure privacy during transmission.
SSL Versions
• SSLv2.0 — First public version; contained several security flaws.
• SSLv3.0 — Improved version with added support for certificate chain loading.
• TLS — IETF standard based on SSLv3.0; the current industry standard for secure
communications.
Important: SSL is NOT a single protocol. It consists of TWO LAYERS OF PROTOCOLS —
the Record Protocol (lower layer) and higher-level protocols (Handshake, Change Cipher
Spec, Alert).
2. SSL Protocol Stack Architecture
Diagram: SSL Protocol Stack
┌────────────────┬──────────────┬─────────────┬────────┬────────┐
│ SSL Handshake │ SSL Change │ SSL Alert │ │ │
│ Protocol │ Cipher Spec │ Protocol │ HTTP │ Telnet │ ...
├────────────────┴──────────────┴─────────────┴────────┴────────┤
│ SSL Record Protocol │
├────────────────────────────────────────────────────────────────┤
│ TCP │
├────────────────────────────────────────────────────────────────┤
│ IP │
└────────────────────────────────────────────────────────────────┘
Components of SSL Protocol Stack
• SSL Record Protocol — Provides basic security services to all higher-layer protocols.
HTTP operates on top of SSL via this layer.
• SSL Handshake Protocol — Used for mutual authentication, negotiation of encryption
algorithms, and key exchange.
• SSL Change Cipher Spec Protocol — Signals a switch from pending cipher state to
active (current) cipher state.
• SSL Alert Protocol — Conveys error messages and alerts between communicating
peers.
3. SSL Session vs SSL Connection
Two critical concepts in SSL must be clearly distinguished:
SSL CONNECTION SSL SESSION
A transport link (OSI layer) providing a An association between a client and a
suitable service type. server, created by the Handshake Protocol.
Connections are peer-to-peer and transient. Sessions define a set of cryptographic
parameters shared among multiple
connections.
Every connection is associated with exactly One session may support MULTIPLE
ONE session. simultaneous connections.
Short-lived; re-established frequently. Used to AVOID expensive renegotiation for
every connection.
Key Point: An SSL session is STATEFUL. Once established, current operating states exist
for both read and write. During Handshake, pending states are created; upon successful
completion, they become current states.
Session State Parameters
• Session Identifier — Arbitrary byte sequence chosen by the server to identify an active
or resumable session.
• Peer Certificate — An X.509.v3 certificate of the peer. This element may be null.
• Compression Method — Algorithm used to compress data prior to encryption.
• Cipher Spec — Specifies the bulk data encryption algorithm (null, AES, etc.) and hash
algorithm (MD5 / SHA-1) used for MAC. Also defines cryptographic attributes such as
hash_size.
• Master Secret — A 48-byte secret shared between client and server.
• Is Resumable — A flag indicating whether the session can be used to initiate new
connections.
Connection State Parameters
• Server and Client Random — Byte sequences chosen by server and client for each
individual connection.
• Server Write MAC Secret — Secret key used in MAC operations on data sent by the
server.
• Client Write MAC Secret — Secret key used in MAC operations on data sent by the
client.
• Server Write Key — Conventional encryption key for data encrypted by the server and
decrypted by the client.
• Client Write Key — Conventional encryption key for data encrypted by the client and
decrypted by the server.
• Initialization Vectors (IV) — Used when a block cipher in CBC mode is active. First
initialized by the Handshake Protocol; thereafter, the final ciphertext block of each record
serves as the IV for the next record.
• Sequence Numbers — Each party maintains separate sequence numbers for
transmitted and received messages. Reset to zero on a change cipher spec message.
Maximum value: 264 − 1.
4. SSL Record Protocol
Two Core Services
4. Confidentiality — The Handshake Protocol defines a shared secret key used for
conventional encryption of SSL payloads.
5. Message Integrity — The Handshake Protocol also defines a shared secret key used to
form a Message Authentication Code (MAC).
Diagram: SSL Record Protocol Operation
Application Data (e.g., 'abcdefghi')
│
Fragment / Combine
[ abc ] [ def ] [ ghi ] ← Record Protocol Units
│
Compress (optional, lossless)
[ Compressed Unit ]
│
Compute MAC + Encrypt
[ Encrypted Unit ]
│
Add Header → [ TCP Packet / SSL Record ]
Step-by-Step Processing
6. Fragmentation — Each message is fragmented into blocks of 2¹⁴ bytes (16,384 bytes)
or less.
7. Compression — Optionally applied. Must be lossless and must not increase content
length by more than 1024 bytes.
8. MAC Computation — A Message Authentication Code is computed over the
compressed data:
hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 || seq_num ||
[Link] || [Link] || [Link]))
pad_1 = byte 0x36, repeated 48 times (MD5) or 40 times (SHA-1)
pad_2 = byte 0x5C, repeated 48 times (MD5) or 40 times (SHA-1)
9. Encryption — Compressed data + MAC are encrypted. Total length must not exceed
2¹⁴ + 2048 bytes. Allowed algorithms: AES-128, AES-256, IDEA-128, DES-40, 3DES-
168, RC2-40, RC4-40, RC4-128, Fortezza.
10. Header Addition — A header is prepended to complete the SSL Record.
HMAC vs SSL MAC: In SSLv3, the two pads are CONCATENATED. In HMAC, they are
XORed. This is a key distinction often tested in exams.
SSL Record Format
┌──────────────┬──────────────┬──────────────┬────────────────────────┐
│ Content Type │ Major Version│ Minor Version│ Compressed Length │
│ (8 bits) │ (8 bits) │ (8 bits) │ (16 bits) │
├──────────────┴──────────────┴──────────────┴────────────────────────┤
│ Plaintext (optionally compressed) ← Encrypted │
├────────────────────────────────────────────────────────────────────┤
│ MAC (0, 16, or 20 bytes) ← Encrypted │
└────────────────────────────────────────────────────────────────────┘
Header Fields
• Content Type (8 bits) — Higher-layer protocol to process the enclosed fragment.
Types: change_cipher_spec, alert, handshake, application_data.
• Major Version (8 bits) — Indicates major SSL version in use. For SSLv3, value = 3.
• Minor Version (8 bits) — Indicates minor SSL version in use. For SSLv3, value = 0.
• Compressed Length (16 bits) — Length of the plaintext/compressed fragment.
Maximum value = 2¹⁴ + 2048.
5. SSL Change Cipher Spec Protocol
The Change Cipher Spec Protocol is the simplest of the three SSL-specific protocols.
• Consists of a single message containing a single byte with value 1.
• Its sole purpose: cause the pending state to be copied into the current state,
updating the cipher suite for the connection.
• Both client and server send this message during Handshake to activate the newly
negotiated encryption parameters.
6. SSL Alert Protocol
The SSL Alert Protocol conveys SSL-related alerts to the peer entity. Alert messages are
compressed and encrypted as per the current state.
Each message consists of two bytes:
11. Level (1st byte) — warning(1) or fatal(2). A fatal alert immediately terminates the
connection.
12. Alert Code (2nd byte) — Identifies the specific alert condition.
Fatal Alerts
• unexpected_message — An inappropriate message was received.
• bad_record_mac — An incorrect MAC was received.
• decompression_failure — Decompression function received improper input.
• handshake_failure — Sender could not negotiate an acceptable set of security
parameters.
• illegal_parameter — A handshake message field was out of range or inconsistent with
other fields.
Warning Alerts
• close_notify — Notifies recipient that no more messages will be sent on this
connection. Each party must send this before closing the write side.
• no_certificate — Sent when no appropriate certificate is available in response to a
request.
• bad_certificate — Received certificate was corrupt (e.g., signature did not verify).
• unsupported_certificate — Type of received certificate is not supported.
• certificate_revoked — Certificate has been revoked by its signer.
• certificate_expired — Certificate has expired.
• certificate_unknown — Some other unspecified issue rendered the certificate
unacceptable.
7. SSL Handshake Protocol
The SSL Handshake Protocol is the most complex and critical part of SSL. It allows the server
and client to:
• Authenticate each other
• Negotiate encryption and MAC algorithms
• Negotiate cryptographic keys to be used
Handshake Message Format
┌──────────┬────────────────────────┬──────────────────────────────────┐
│ Type │ Length │ Content │
│ 1 byte │ 3 bytes │ ≥ 0 bytes │
└──────────┴────────────────────────┴──────────────────────────────────┘
• Type (1 byte) — Indicates one of 10 possible message types.
• Length (3 bytes) — Length of the message in bytes.
• Content (≥0 bytes) — Parameters associated with this message.
Four Phases of SSL Handshake
Phase 1 — Establish Security Capabilities
Client initiates with a client_hello message containing the following parameters:
• Version — Highest SSL version understood by the client.
• Random — 32-bit timestamp + 28 bytes from a secure random number generator.
Serves as a nonce to prevent replay attacks.
• Session ID — Nonzero = update existing session or create new connection on that
session; Zero = initiate a brand new session.
• CipherSuite — List of cryptographic algorithm combinations supported by the client, in
decreasing order of preference. Each element defines a key exchange algorithm and a
CipherSpec.
• Compression Method — List of compression methods supported by the client.
Phase 2 — Server Authentication and Key Exchange
• Server sends its certificate message — contains one or a chain of X.509 certificates.
• The certificate message is required for any agreed-on key exchange method except
anonymous Diffie-Hellman.
• A server_key_exchange message may optionally be sent. It is NOT required when: (1)
the server has sent a certificate with fixed Diffie-Hellman parameters, or (2) RSA key
exchange is to be used.
Phase 3 — Client Authentication and Key Exchange
• After receiving server_done, the client verifies the server certificate and checks that
server_hello parameters are acceptable.
• If the server requested a certificate, the client sends a certificate message. If no
suitable certificate is available, it sends a no_certificate alert.
• Client sends the client_key_exchange message — its content depends on the type of
key exchange negotiated.
Phase 4 — Finish
• Client sends a change_cipher_spec message, copying the pending CipherSpec into
the current CipherSpec.
• Client immediately sends a finished message under the new algorithms, keys, and
secrets.
• The finished message verifies that the key exchange and authentication processes
were successful.
• Server responds with its own change_cipher_spec and finished message, completing
the handshake.
Critical: The Handshake Protocol is the ONLY mechanism through which SSL sessions are
created. No encryption keys can be established without successfully completing all four
phases.
Conclusion
SSL/TLS is a cornerstone of Internet security, providing confidentiality, integrity, and
authentication for data in transit. Its layered architecture — with the Record Protocol as the
foundation and the Handshake, Change Cipher Spec, and Alert Protocols as upper-layer
components — ensures that secure communication can be efficiently established and
maintained. The concept of sessions and connections allows expensive cryptographic
negotiations to be reused across multiple connections, improving performance. TLS, the
successor to SSL, continues to evolve (TLS 1.3 being the current standard), and underpins
HTTPS, secure email, VPNs, and virtually all encrypted communication on the modern Internet.
Exam Tips — What the Examiner Expects
13. Always draw diagrams — SSL protocol stack, SSL record format, and record protocol
operation flow are high-scoring visual aids.
14. Distinguish Session vs Connection clearly — Examiners specifically test this. A
comparison table earns bonus marks.
15. List all four Handshake phases — Name each phase and explain the messages
exchanged (client_hello, server_hello, certificate, etc.).
16. Mention MAC computation formula — Demonstrates deep understanding; quote
pad_1 and pad_2 values.
17. Quote exact sizes — Fragment size (2¹⁴ bytes), MAC sizes (0/16/20 bytes), Master
Secret (48 bytes), sequence number limit (2⁶⁴ − 1).
18. Compare SSL with HMAC — Concatenation (SSL) vs XOR (HMAC) — a commonly
tested distinction.
19. Mention all three sub-protocols — Handshake, Change Cipher Spec, and Alert — in
addition to the Record Protocol.
20. Structure your answer — Begin with a clear definition, cover each sub-protocol in a
dedicated section, and end with a meaningful conclusion linking SSL to real-world
HTTPS usage.