Quartz 4

levels of SSL_TLS

19 min read

Level 1: The Big Picture - What and Why?

What are SSL/TLS?

  • They are security protocols designed to provide secure communication over a computer network.
  • They operate at the Transport Layer in the Internet model, sitting between the Application Layer (like HTTP) and a reliable transport protocol (like TCP). (See Figure 17.1)
  • TLS is essentially the successor to SSL. TLS is an IETF standard based on SSL. The text discusses SSL (specifically SSLv3) first, then TLS, and compares them.

Why Do We Need Them?

Imagine online shopping:

  1. Authentication: You need to be sure the website you’re giving your credit card to is the actual vendor, not an impostor (Entity Authentication).
  2. Integrity: You and the vendor need assurance that the messages (like your order or credit card number) haven’t been tampered with during transit (Message Integrity).
  3. Confidentiality: You need to ensure that eavesdroppers cannot read sensitive information like your credit card number (Confidentiality).

SSL/TLS provide these crucial security services for applications using TCP, enabling secure transactions (like https:// browsing).

Objectives Covered (from text):

  • Discuss the need for security services at the transport layer (Covered above).
  • (Other objectives will be covered in lower levels).

Level 2: Core Concepts & Services

What Services Do SSL/TLS Provide? (Based on SSL Description)

When application data (like an HTTP request) is given to SSL/TLS, it performs several steps:

  1. Fragmentation: Breaks the data into manageable blocks (e.g., bytes or less in SSL).
  2. Compression (Optional): Compresses the data fragments to save bandwidth (using negotiated lossless methods; default is often no compression).
  3. Message Integrity: Adds a Message Authentication Code (MAC) using a keyed-hash function to ensure the data hasn’t been altered.
  4. Confidentiality: Encrypts the original data fragment and the MAC using symmetric-key cryptography.
  5. Framing: Adds an SSL/TLS header to the encrypted payload before passing it to TCP.

Key Concepts: Sessions vs. Connections

SSL/TLS make a distinction:

  • Session: A longer-term association between a client and server. It establishes shared security parameters like the session ID, peer certificates, chosen cipher suite, compression method, and a shared master secret. A session can be established, suspended, and resumed. Resuming avoids the computationally expensive process of creating a new master secret.
    • Session State Parameters (Table 17.2): Session ID, Peer Certificate, Compression Method, Cipher Suite, Master Secret, Is Resumable flag.
  • Connection: A specific communication link within a session. Multiple connections can exist within a single session. Connections use the parameters established by the session (especially the master secret) to derive unique keys for encrypting and authenticating data for that specific connection.
    • Connection State Parameters (Table 17.3): Server/Client Random Numbers, MAC secrets (read/write), Encryption keys (read/write), Initialization Vectors (IVs), Sequence Numbers.

Analogy: Think of a session as establishing a secure “meeting room” (with agreed-upon security rules and a master key). A connection is like a specific conversation happening within that room, using keys derived from the master key for that particular talk.

The Four Protocols within SSL/TLS (Figure 17.12)

SSL/TLS aren’t monolithic; they consist of several sub-protocols working together:

  1. Record Protocol: This is the workhorse. It takes data from the application layer (or messages from the other SSL/TLS protocols), applies the services (fragmentation, compression, MAC, encryption, framing), and passes the result to TCP. It also handles the reverse process for incoming data.
  2. Handshake Protocol: Used to negotiate the security parameters for a session and connection. This includes:
    • Negotiating the Cipher Suite (algorithms for keys, encryption, MAC).
    • Authenticating the server to the client (mandatory in most cases).
    • Authenticating the client to the server (optional).
    • Establishing the shared master secret.
  3. ChangeCipherSpec Protocol: A very simple protocol consisting of a single message. It signals the point at which the newly negotiated cryptographic parameters (pending state) should become active for the connection.
  4. Alert Protocol: Used to signal errors or warning conditions (e.g., bad certificate, decryption failure). Messages indicate the severity (warning or fatal) and the type of alert.

Objectives Covered (from text):

  • Discuss the general architecture of SSL (Services, Session/Connection, 4 Protocols).
  • (TLS architecture and comparison in later levels).

Level 3: SSL Deep Dive - Architecture & Mechanisms

SSL Architecture Components

1. Key Exchange Algorithms (Figure 17.2)

Before secure communication can begin, the client and server need to establish a shared secret called the pre-master secret. This is then used (along with random numbers) to create the master secret. SSL supports several methods:

  • NULL: No key exchange, no security.
  • RSA: The client generates the pre-master secret, encrypts it with the server’s RSA public key (obtained from the server’s certificate), and sends it to the server. (Figure 17.3)
  • Anonymous Diffie-Hellman (DH): Uses the standard DH protocol. Client and server exchange DH parameters and public values in plaintext. Insecure against man-in-the-middle attacks because parties are not authenticated. (Figure 17.4)
  • Ephemeral Diffie-Hellman (DHE): Uses DH but signs the DH public values with the sender’s private key (RSA or DSS). The public key for verification is sent in a certificate. Provides authentication and thwarts man-in-the-middle. Keys are temporary (“ephemeral”). (Figure 17.5)
  • Fixed Diffie-Hellman: Parties have long-term, fixed DH public keys contained within certificates signed by a CA. No direct exchange of DH public values needed during the handshake; they are retrieved from the certificates.
  • Fortezza: A US government-specified protocol family (not detailed in the text).

2. Encryption/Decryption Algorithms (Figure 17.6)

Used for confidentiality (encrypting data + MAC). Negotiated during the handshake. SSLv3 supports:

  • NULL: No encryption.
  • Stream RC4: RC4 with 40-bit or 128-bit keys.
  • Block RC2: RC2 (CBC mode) with 40-bit keys.
  • Block DES: DES (CBC mode) with 40-bit keys (DES40_CBC), standard 56-bit keys (DES_CBC), or Triple DES (3DES_EDE_CBC) with 168-bit keys.
  • Block IDEA: IDEA (CBC mode) with 128-bit keys.
  • Block Fortezza: FORTEZZA_CBC with 96-bit keys.
  • Note: Block ciphers (except Fortezza) use an 8-byte Initialization Vector (IV).

3. Hash Algorithms (Figure 17.7)

Used for creating the Message Authentication Code (MAC) for integrity.

  • NULL: No authentication.
  • MD5: Uses a 128-bit key with the MD5 hash function.
  • SHA-1: Uses a 160-bit key with the SHA-1 hash function.

4. Cipher Suite

A specific combination of:

  • Key Exchange Algorithm
  • Encryption Algorithm
  • Hash Algorithm (for MAC)

Examples (Table 17.1): SSL_RSA_WITH_RC4_128_MD5, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA The client offers a list of supported suites; the server chooses one.

5. Compression Algorithm

SSLv3 defines the mechanism but not specific algorithms. The default is NULL (no compression). Systems can negotiate other lossless algorithms if implemented.

6. Cryptographic Parameter Generation (SSLv3)

SSL needs six secrets for a connection (3 for client→server, 3 for server→client):

  • Client Write MAC Key, Server Write MAC Key
  • Client Write Encryption Key, Server Write Encryption Key
  • Client Write IV, Server Write IV (for block ciphers)

These are generated through a multi-step process:

  1. Exchange Random Numbers: Client sends ClientHello.random, Server sends ServerHello.random.
  2. Establish Pre-Master Secret: Using the chosen Key Exchange method (e.g., RSA encryption, DH exchange).
  3. Calculate Master Secret: A 48-byte secret derived from the pre-master secret and the exchanged random numbers using MD5 and SHA-1 hashing. (Figure 17.8)
    • MasterSecret = MD5(pre_master_secret + SHA1(“A” + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA1(“BB” + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA1(“CCC” + pre_master_secret + ClientHello.random + ServerHello.random))
  4. Generate Key Material: The master secret is repeatedly hashed (similar process to master secret generation, using different constants “A”, “BB”, etc.) to produce a long stream of bytes called the key material. (Figure 17.9)
  5. Extract Keys and IVs: The required six secrets are simply carved out sequentially from the generated key material block. (Figure 17.10)

SSL Handshake Protocol (Figure 17.13)

This protocol negotiates the session parameters and establishes the keys. It proceeds in four phases:

Phase I: Establishing Security Capabilities (Figure 17.14)

  • Client → Server: ClientHello
    • Highest SSL version supported.
    • Client’s random number (ClientHello.random).
    • Session ID (0 for new session, previous ID to attempt resumption).
    • List of supported Cipher Suites (client preference order).
    • List of supported Compression Methods.
  • Server → Client: ServerHello
    • Chosen SSL version (lower of client/server max).
    • Server’s random number (ServerHello.random).
    • Session ID (new ID if starting new session, client’s ID if resuming).
    • Chosen Cipher Suite (from client’s list).
    • Chosen Compression Method (from client’s list).
  • Outcome: Version, Cipher Suite, Compression, Random Numbers agreed upon.

Phase II: Server Authentication and Key Exchange (Figure 17.15, 17.16)

  • Server → Client: Certificate (Optional)
    • Server’s X.509 certificate chain. (Not sent for anonymous methods).
  • Server → Client: ServerKeyExchange (Optional)
    • Contains server’s contribution to key exchange if needed (e.g., Ephemeral DH public key signed by server, or anonymous DH parameters). Not needed for RSA key exchange (where client sends secret) or Fixed DH (where key is in cert).
  • Server → Client: CertificateRequest (Optional)
    • Requests the client’s certificate for authentication. Specifies acceptable certificate types and CAs. (Cannot be sent if server is anonymous).
  • Server → Client: ServerHelloDone
    • Signals the end of the server’s messages for this phase.
  • Outcome: Server is authenticated (if cert sent), client knows server’s public key (if needed), client is requested to authenticate (if needed).

Phase III: Client Authentication and Key Exchange (Figure 17.17, 17.18)

  • Client → Server: Certificate (Optional)
    • Client’s X.509 certificate chain (only if requested by server). If requested but none available, may send an alert.
  • Client → Server: ClientKeyExchange
    • Client’s contribution to key exchange. Contents depend on the negotiated method:
      • RSA: Encrypted pre-master secret.
      • DH (Anon/Ephemeral): Client’s DH public value.
      • Fixed DH: Empty.
  • Client → Server: CertificateVerify (Optional)
    • Proof that the client owns the private key corresponding to the public key in its certificate. Typically a hash of previous handshake messages signed with the client’s private key. (Sent only if client sent a certificate with signing capability).
  • Outcome: Client is authenticated (if cert/verify sent), Pre-master secret is established. Both sides can now calculate the master secret and derive keys.

Phase IV: Finalizing Handshake (Figure 17.19)

  • Client → Server: ChangeCipherSpec
    • Signals that the client is switching to the newly negotiated cipher suite and keys for subsequent messages. Client moves keys from pending to active state (for writing).
  • Client → Server: Finished
    • First message protected by the new parameters. Contains a hash of all previous handshake messages (using master secret and specific padding). Verifies that key exchange and authentication were successful.
  • Server → Client: ChangeCipherSpec
    • Signals the server is switching to the new parameters. Server moves keys from pending to active state (for writing).
  • Server → Client: Finished
    • Server’s first protected message. Contains a similar hash verifying its view of the handshake.
  • Outcome: Handshake complete. Secure application data can now be exchanged using the Record Protocol with the negotiated parameters.

SSL ChangeCipherSpec Protocol (Figure 17.20)

  • A single message (CCS, value 1) encapsulated by the Record Protocol (type 20).
  • Marks the transition from the pending state (where negotiated parameters are stored) to the active state (where parameters are used for protection).
  • Sending CCS: Move write parameters from pending to active.
  • Receiving CCS: Move read parameters from pending to active.
  • Ensures sender and receiver switch to encryption/MAC simultaneously.

SSL Alert Protocol (Table 17.4)

  • Messages encapsulated by Record Protocol (type 21).
  • Format: Level (1 byte: 1=warning, 2=fatal) + Description (1 byte: code for specific alert).
  • Examples: bad_certificate, handshake_failure, decompression_failure, close_notify (graceful shutdown). Fatal alerts terminate the connection.

SSL Record Protocol in Action (Figure 17.21)

Takes data/messages from upper layers and processes for sending:

  1. Fragmentation: Break into blocks bytes.
  2. Compression (Optional): Compress fragment (output original + 1024 bytes).
  3. Add MAC (Signing): Calculate MAC using write MAC key and hash algorithm over: MAC_write_secret + pad_1 + seq_num + compressed_type + compressed_length + compressed_fragment. Then hash that result with MAC_write_secret + pad_2. (Figure 17.22 shows this HMAC-like structure).
  4. Encryption: Encrypt (Compressed Fragment + MAC) using write encryption key and IV. Add padding for block ciphers if needed.
  5. Add Header: Prepend SSL Record Header (Type, Version, Length).
  6. Transmit: Send via TCP.

Receiving process is the reverse: Read Header → Decrypt → Verify MAC → Decompress → Reassemble fragments.

Objectives Covered (from text):

  • Discuss the general architecture of SSL (Completed).
  • Compare and contrast SSL and TLS (Partially, SSL side covered).

Level 4: SSL Message Formats

This level looks at the structure of the actual messages.

Record Protocol Header (Figure 17.23)

Present on all SSL messages sent over TCP.

  • Protocol / Content Type (1 byte): Identifies the encapsulated protocol:
    • 20: ChangeCipherSpec
    • 21: Alert
    • 22: Handshake
    • 23: Application Data
  • Version (2 bytes): SSL version (e.g., Major=3, Minor=0 for SSLv3.0).
  • Length (2 bytes): Length of the encapsulated data (fragment, MAC, padding) in bytes (max + overhead).

ChangeCipherSpec Message (Figure 17.24)

  • Record Header: Type=20, Version=3.0, Length=1.
  • Payload (1 byte): CCS value (always 1).

Alert Message (Figure 17.25)

  • Record Header: Type=21, Version=3.0, Length=2.
  • Payload (2 bytes):
    • Level (1 byte): 1 (warning) or 2 (fatal).
    • Description (1 byte): Alert code (from Table 17.4).

Handshake Protocol Messages (Figure 17.26)

  • Record Header: Type=22, Version=3.0, Length=variable.
  • Payload: One or more Handshake messages. Each has a generic 4-byte header:
    • Type (1 byte): Handshake message type (from Table 17.5, e.g., 1=ClientHello, 2=ServerHello, 11=Certificate, 16=ClientKeyExchange, 20=Finished).
    • Length (3 bytes): Length of the handshake message body (excluding this 4-byte header).

Specific Handshake Message Formats (Examples):

  • HelloRequest (Type 0, Figure 17.27): Server requests client to start a new handshake. Body is empty (Length=0).
  • ClientHello (Type 1, Figure 17.28):
    • Version (2 bytes): Client’s highest supported SSL/TLS version.
    • Random (32 bytes): Client-generated random number.
    • Session ID Length (1 byte) + Session ID (variable): 0 length/empty for new session, ID for resumption attempt.
    • Cipher Suite Length (2 bytes) + Cipher Suites (variable): List of 2-byte codes for suites client supports.
    • Compression Method Length (1 byte) + Compression Methods (variable): List of 1-byte codes for methods client supports.
  • ServerHello (Type 2, Figure 17.29):
    • Version (2 bytes): Negotiated SSL/TLS version.
    • Random (32 bytes): Server-generated random number.
    • Session ID Length (1 byte) + Session ID (variable): Session ID for this session.
    • Selected Cipher Suite (2 bytes): The single suite chosen by the server.
    • Selected Compression Method (1 byte): The single method chosen by the server.
  • Certificate (Type 11, Figure 17.30):
    • Certificate Chain Length (3 bytes): Total length of all certificate data following.
    • Certificate Chain (variable): Sequence of certificates. Each certificate preceded by its own 3-byte length field.
  • ServerKeyExchange (Type 12, Figure 17.31): Format depends entirely on the key exchange algorithm (e.g., DH parameters + signature).
  • CertificateRequest (Type 13, Figure 17.32):
    • Cert Types Length (1 byte) + Cert Types (variable): List of acceptable certificate types (e.g., RSA sign, DSS sign).
    • CAs Length (2 bytes) + CAs (variable): List of distinguished names of acceptable Certificate Authorities. Each CA name preceded by its 2-byte length.
  • ServerHelloDone (Type 14, Figure 17.33): Body is empty (Length=0).
  • CertificateVerify (Type 15, Figure 17.34):
    • Hash (variable): Signature created using client’s private key.
      • For DSS cert: SHA-1 hash (20 bytes) of handshake messages.
      • For RSA cert: MD5 hash (16 bytes) || SHA-1 hash (20 bytes) = 36 bytes total, of handshake messages combined with master secret and padding (Figure 17.35).
  • ClientKeyExchange (Type 16, Figure 17.36): Format depends on key exchange (e.g., encrypted pre-master secret for RSA).
  • Finished (Type 20, Figure 17.37):
    • Hash (36 bytes): MD5 hash || SHA-1 hash. Both hashes computed over handshake messages + sender identifier (“CLNT” or “SRVR”) + master secret + padding. (Figure 17.38). This message is encrypted under the newly negotiated keys.

Application Data Message (Figure 17.39 - shows TLS version but structure is similar)

  • Record Header: Type=23, Version=3.0, Length=variable.
  • Payload: Encrypted (Compressed Fragment + MAC).

Objectives Covered:

  • (Implicitly supports understanding of SSL architecture and comparison with TLS).

Level 5: TLS Deep Dive - Differences from SSLv3

TLS (Transport Layer Security) version 1.0 is defined in RFC 2246 and is the IETF standard successor to SSLv3. It’s very similar but introduces some key differences and improvements.

1. Version Number

  • SSL: Current version discussed is 3.0.
  • TLS: Protocol version is 1.0 (internally represented as {3, 1}, making it look like SSL 3.1 for backward compatibility hints).

2. Cipher Suites (Table 17.6)

  • No Fortezza: TLS removes support for the Fortezza key exchange and encryption methods.
  • Naming: Cipher suites start with “TLS_” instead of “SSL_“. (e.g., TLS_RSA_WITH_3DES_EDE_CBC_SHA).
  • Otherwise, the list of common suites is largely the same initially. (More suites were added in later TLS versions).

3. Generation of Cryptographic Secrets

This is more complex and arguably more secure in TLS.

  • Data Expansion Function (Figure 17.40): A generic function to expand a secret using repeated HMAC applications (either HMAC-MD5 or HMAC-SHA1). Takes a secret and a seed. Creates output by chaining HMACs: HMAC(secret, seed), HMAC(secret, HMAC_output_1), etc. Concatenates results.
  • Pseudorandom Function (PRF) (Figure 17.41): The core function in TLS for generating secrets. It combines both MD5 and SHA-1 hashing for increased robustness.
    • Takes: secret, label (ASCII string like “master secret”), seed.
    • Splits secret into two halves.
    • Uses one half with the MD5-based data expansion function (with label + seed as its seed).
    • Uses the other half with the SHA1-based data expansion function (with label + seed as its seed).
    • XORs the results from the two expansion functions to produce the final output.
  • Master Secret Calculation (Figure 17.42):
    • Uses the PRF.
    • master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random)
    • Note: pre_master_secret is used only once, unlike SSL’s multiple hash inputs.
  • Key Material Calculation (Figure 17.43):
    • Also uses the PRF.
    • key_material = PRF(master_secret, “key expansion”, ServerHello.random + ClientHello.random) (Note randoms are swapped compared to master secret calculation).
    • The required keys and IVs are still carved out of this key_material block. TLS calculation can produce variable amounts of key material more easily.

4. Alert Protocol (Table 17.7)

  • TLS supports most SSL alerts.
  • Removes NoCertificate: TLS handles this differently within the handshake.
  • Adds New Alerts: decryption_failed, record_overflow, unknown_ca, access_denied, decode_error, decrypt_error, export_restriction, protocol_version, insufficient_security, internal_error, user_canceled, no_renegotiation.

5. Handshake Protocol Changes

  • CertificateVerify Message (Figure 17.44):
    • Simplified hash calculation. It only hashes the handshake messages up to that point using MD5 and SHA-1. The master secret and padding used in SSL are not included.
    • Signature = sign(MD5(handshake_messages) + SHA1(handshake_messages)) (Conceptual, actual hash input depends on signature algorithm).
  • Finished Message (Figure 17.45):
    • Uses the TLS PRF for hash calculation instead of SSL’s custom MD5/SHA1 concatenation.
    • verify_data = PRF(master_secret, finished_label, MD5(handshake_messages) + SHA1(handshake_messages))
    • finished_label is “client finished” for the client’s message, “server finished” for the server’s. Length is 12 bytes.

6. Record Protocol Changes (HMAC) (Figure 17.46)

  • HMAC for Integrity: TLS mandates the use of the formal HMAC algorithm (defined in RFC 2104, covered in Chapter 11) for message authentication, rather than SSL’s ad-hoc construction.
  • HMAC Calculation:
    • HMAC = Hash(MAC_write_secret + opad, Hash(MAC_write_secret + ipad, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment))
    • ipad is repeated, opad is repeated. Hash is MD5 or SHA-1 based on cipher suite.
    • Note the inclusion of the TLSCompressed.version in the HMAC input, providing additional protection against version rollback attacks within the MAC itself.

Objectives Covered:

  • Discuss the general architecture of TLS (Differences from SSL).
  • Compare and contrast SSL and TLS (Completed).

Level 6: Cryptographic Generation Details (SSL vs. TLS)

Let’s focus specifically on how the crucial Master Secret and Key Material are generated.

Master Secret Generation

  • Goal: Create a 48-byte shared secret from the pre_master_secret and the ClientHello.random / ServerHello.random.
  • SSLv3 (Figure 17.8):
    • Uses a three-part concatenation based on MD5 and SHA-1.
    • MD5(pre + SHA1(“A” + pre + rands)) | MD5(pre + SHA1(“BB” + pre + rands)) | MD5(pre + SHA1(“CCC” + pre + rands))
    • Relies on specific constants (“A”, “BB”, “CCC”).
    • Uses the pre_master_secret multiple times as direct input to hash functions.
  • TLSv1.0 (Figure 17.42):
    • Uses the formal PRF function.
    • PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random)
    • PRF internally uses both MD5 and SHA-1 (via HMAC) in a structured way.
    • Considered cryptographically stronger due to the use of PRF/HMAC and reliance on a standard construction. pre_master_secret is used as the PRF secret, not directly hashed multiple times.

Key Material Generation

  • Goal: Create a long stream of pseudo-random bytes from the master_secret and randoms, from which specific connection keys (MAC keys, encryption keys, IVs) are extracted.
  • SSLv3 (Figure 17.9):
    • Uses a process very similar to master secret generation, but with the master_secret as input and different constants (“A”, “BB”, “CCC”, …).
    • MD5(master + SHA1(“A” + master + rands)) | MD5(master + SHA1(“BB” + master + rands)) | … (repeated until enough bytes generated).
    • Randoms used: ClientHello.random + ServerHello.random.
  • TLSv1.0 (Figure 17.43):
    • Uses the PRF again.
    • PRF(master_secret, “key expansion”, ServerHello.random + ClientHello.random) (Note swap in random order compared to master secret generation seed).
    • PRF can be iterated or configured to generate arbitrary lengths of output cleanly.

Comparison: TLS uses a more modern, standardized pseudo-random function (PRF) based on HMAC for both master secret and key material generation. This is generally considered more secure and flexible than SSLv3’s custom constructions.

Level 7: MAC/HMAC Calculation Details (SSL vs. TLS)

Let’s compare how message integrity is calculated for application data.

SSLv3 MAC (Figure 17.22)

  • Construction: An ad-hoc, HMAC-like structure.
  • Process:
    1. Inner Hash: Hash(MAC_write_secret + pad_1 + seq_num + SSLCompressed.type + SSLCompressed.length + SSLCompressed.fragment)
    2. Outer Hash: Hash(MAC_write_secret + pad_2 + Inner_Hash_Result)
  • Hash: MD5 or SHA-1.
  • Secrets: MAC_write_secret.
  • Padding: pad_1 ( repeated), pad_2 ( repeated). Length depends on hash function (48 bytes for MD5, 40 for SHA-1).
  • Included Data: Sequence number, type, length, and fragment content.

TLSv1.0 HMAC (Figure 17.46)

  • Construction: Uses the standardized HMAC algorithm (RFC 2104).
  • Process (Standard HMAC):
    • HMAC = Hash( (key XOR opad) + Hash( (key XOR ipad) + data ) )
  • TLS Application:
    • key is the MAC_write_secret (padded to block size if needed).
    • data is seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment.
  • Hash: MD5 or SHA-1 (or newer hashes in later TLS versions).
  • Secrets: MAC_write_secret.
  • Padding: ipad ( repeated 64 times), opad ( repeated 64 times). Standard block size for MD5/SHA1 is 512 bits (64 bytes).
  • Included Data: Sequence number, type, protocol version, length, and fragment content.

Comparison: TLS uses the well-vetted, standard HMAC construction, which has security proofs that SSL’s construction lacks. Additionally, TLS includes the protocol version within the authenticated data, providing stronger protection against certain types of version rollback attacks compared to SSLv3.

This covers the material presented in the chapter from high-level concepts down to specific cryptographic and message format details, highlighting the key aspects of SSLv3 and its evolution into TLSv1.0.

Graph View

Backlinks