Protocols for security TLS

Summary

The lecture introduces Transport Layer Security (TLS) as the protocol that supports secure web communication, commonly encountered through HTTPS. TLS sits between TCP and HTTP in the network stack and helps address authentication, confidentiality, and non-repudiation concerns.

TLS has two main parts:

• TLS Handshake Protocol: Establishes the parameters for a secure connection, authenticates the server (and sometimes the client), and sets up shared key material.
• TLS Record Protocol: Uses the negotiated settings and keys to protect data as it is sent.

The lecture explains why TLS uses both public-key and symmetric-key cryptography. Public-key operations are comparatively costly, so they are used during setup to establish shared secret material. Symmetric encryption is then used for bulk data transfer.

Handshake Process

1. Client Hello: The client begins the exchange by sending information such as a random value, session identifier, supported cipher suites, protocol version, and compression options.
2. Server Hello and certificate: The server responds with its own random value, selects supported options, and sends its digital certificate, which provides information about the server, including its public key.
3. Server authentication: The client checks the server’s certificate.
4. Key exchange: The client generates a premaster secret and sends it encrypted with the server’s public key. The server uses its private key to recover it.
5. Shared key generation: Both sides use the premaster secret and the previously exchanged random values to derive the key material that protects the session.
6. Confirmation: The client and server exchange final handshake messages to confirm that negotiation is complete. The lecture also notes that a client may authenticate itself to the server, although this is less common.

The handshake negotiates the cryptographic and data-handling options the two sides will use, including the bulk-encryption algorithm, message-authentication method, and compression method.

Session Reuse

A full handshake requires multiple cryptographic operations and takes time. The lecture describes maintaining session information at both ends so that a later connection can resume an existing session instead of repeating the entire key-exchange process. The client can offer a cached session identifier, which the server may accept. This reduces setup work and connection delay.

TLS Overhead

TLS adds overhead beyond the TCP connection process. The lecture identifies two main sources:

• Additional round trips: The handshake adds messages before protected application data can be exchanged.
• Extra computation: The client and server perform certificate verification, key exchange, key derivation, encryption or decryption, and message-authentication work.

The lecture distinguishes the handshake’s costs, such as certificate checking and establishing keys, from the record protocol’s costs, which include protecting bulk data. It says the next lesson will examine the increase in processing time in more detail.

The lecture names RSA, DES, 3DES, RC4, MD5, and SHA-1 as examples. These are presented as examples from the lecture, not as recommendations for current secure deployments.

Speakers and Sources

• Speaker: One instructor or lecturer, unnamed in the subtitles.
• Other speakers: None identifiable.
• Sources or organizations mentioned: Certifying authorities are discussed in connection with digital certificates, but no specific authority or external speaker is named.