SSL and TLS

TLS Handshake Explained - ComputerphileComputerphile · the TLS handshake, message by message, 17 minBreaking Down the TLS HandshakeF5 DevCentral Community · TLS handshake breakdown, 8 minSSL/TLS Handshake ProcessSoftware Umpire · short SSL/TLS handshake summary, 4 min

Web securitySearch on YouTubeBookmarkSaved

Need for web securitySearch on YouTubeBookmarkSaved

Almost all businesses, most government agencies and many individuals now have web sites. Users access them with graphical web browsers over the Internet. But the Internet and the Web are extremely vulnerable to attack.

The World Wide Web (WWW) is a client-server application that runs over the Internet and TCP/IP intranets. These characteristics of web usage show the need for security tools:

• Web servers are relatively easy to configure and manage.
• Web content is increasingly easy to develop.
• The underlying software is complex. It may hide many potential security flaws.
• An attacker can use a web server as a launching pad into the entire computer complex of the corporation or agency.
• Casual users, untrained in security, are common clients. They do not know the risks, and they do not have the tools or knowledge for countermeasures.

Threats on the webSearch on YouTubeBookmarkSaved

The slide table puts web threats into four groups:

Security approachesSearch on YouTubeBookmarkSaved

Web security can occur at three levels of the protocol stack:

The rest of the deck is about the transport level.

SSLSearch on YouTubeBookmarkSaved

SSL overviewSearch on YouTubeBookmarkSaved

SSL (Secure Sockets Layer) is an encryption-based Internet security protocol. Netscape Communications Corporation developed it. Its purpose is privacy, authentication and data integrity in Internet communications.

The IETF deprecated SSL and released its successor, TLS, in 1999.

HTTPSSearch on YouTubeBookmarkSaved

SSL-enabled browsers can communicate securely with a server that has a digital certificate. A browser that does not support HTTP over SSL cannot request URLs with HTTPS.

HTTPS is a protocol that combines SSL and HTTP. HTTPS and HTTP are different protocols and use different ports (443 and 80). Thus, a server can run SSL and non-SSL requests at the same time.

SSL certificatesSearch on YouTubeBookmarkSaved

An SSL certificate is a digital document. It binds the identity of a website to a cryptographic key pair (public key and private key). It is a type of X.509 public-key certificate, but it is a server certificate. SSL certificates make an encrypted connection between a web browser and a server with a shared secret key.

The slide diagram has seven steps:

1. The browser sends a request to the server.
2. The server answers with its certificate (X.509).
3. The browser verifies the certificate: validation, trust, integrity, integrity with the domain name.
4. The browser generates a symmetric key.
5. Client identification: the browser sends the symmetric SSL key, encrypted, to the server.
6. The server verifies and decrypts the symmetric key.
7. Both sides use symmetric encryption for secure data transfer.

Certificate typesSearch on YouTubeBookmarkSaved

The slide shows two independent lists. The first list gives the trust level, which shows how much the CA checked:

The second list gives the coverage, which shows which names the certificate covers:

Example applicationSearch on YouTubeBookmarkSaved

The deck shows a VPN client configuration (illustrative). The user selects SSL-VPN (the other option is IPsec VPN). The user sets the remote gateway (vpn.example.org) and the port 443.

TLS architectureSearch on YouTubeBookmarkSaved

TLS overviewSearch on YouTubeBookmarkSaved

TLS (Transport Layer Security) [RFC 5246] is an Internet standard. It evolved from the commercial protocol SSL. TLS uses TCP to give a reliable end-to-end secure service. Some applications are Web (HTTP+TLS), Email (SMTP+TLS) and File Transfer (FTP+TLS).

The slide timeline gives the versions:

Protocol layersSearch on YouTubeBookmarkSaved

TLS is not one protocol. It is two layers of protocols:

• The Record Protocol gives basic security services to upper-layer protocols such as HTTP.
• TLS defines three higher-layer protocols that manage TLS exchanges: the Handshake Protocol, the Change Cipher Spec Protocol and the Alert Protocol.
• The Heartbeat Protocol is a fourth higher-layer protocol.

The stack, top to bottom: Handshake, Change Cipher Spec, Alert, HTTP and Heartbeat; then the Record Protocol; then TCP; then IP.

Connection and sessionSearch on YouTubeBookmarkSaved

Session stateSearch on YouTubeBookmarkSaved

Connection stateSearch on YouTubeBookmarkSaved

Record protocolSearch on YouTubeBookmarkSaved

ServicesSearch on YouTubeBookmarkSaved

The record protocol gives two basic security services for TLS connections:

Operation stepsSearch on YouTubeBookmarkSaved

The steps before transmission are:

1. Take an application message as input.
2. Fragment the data into manageable blocks.
3. Optionally, compress.
4. Apply a MAC.
5. Encrypt.
6. Add a header.
7. Transmit the result in a TCP segment.

The steps on received data are:

1. Remove the header.
2. Decrypt.
3. Verify.
4. Decompress.
5. Reassemble.
6. Deliver to the higher-level users.

Pipeline limitsSearch on YouTubeBookmarkSaved

The slide diagram gives these limits:

The slide also gives the cipher choices:

Record formatSearch on YouTubeBookmarkSaved

Each record starts with a header of four fields. After the header comes the plaintext (optionally compressed) and a MAC of 0, 16 or 20 bytes. Encryption covers the plaintext and the MAC.

Upper-layer protocolsSearch on YouTubeBookmarkSaved

Change cipher specSearch on YouTubeBookmarkSaved

The Change Cipher Spec Protocol has one message. The message is one byte with the value 1. Its only purpose is to copy the pending state into the current state. This updates the cipher suite for this connection.

Alert protocolSearch on YouTubeBookmarkSaved

The alert protocol sends TLS-related alerts to the peer entity. Each message has two bytes:

The deck shows an alert example from a FortiClient VPN (SSL-VPN) client. A warning dialog shows "Credential or SSLVPN configuration is wrong. (-7200)".

Handshake protocolSearch on YouTubeBookmarkSaved

The handshake protocol lets the server and the client:

• authenticate each other,
• negotiate an encryption and MAC algorithm,
• negotiate the cryptographic keys that protect data in a TLS record.

The handshake occurs before the transmission of any application data. Each handshake message has three fields:

Handshake phasesSearch on YouTubeBookmarkSaved

The client and server need an initial exchange. It makes a logical connection and sets the security capabilities. The exchange has 4 phases:

The shaded messages on the slide are optional or situation-dependent. They are: certificate, server_key_exchange and certificate_request in phase 2, and certificate and certificate_verify in phase 3.

Heartbeat protocolSearch on YouTubeBookmarkSaved

A heartbeat is a periodic signal from hardware or software. It shows normal operation, or it synchronizes other parts of a system. A heartbeat protocol monitors the availability of a protocol entity. The slide cites RFC 6250; the TLS Heartbeat RFC number is 6520.

• It runs on top of the TLS Record Protocol.
• It has two message types: heartbeat_request and heartbeat_response.
• The two peers agree to use it during Phase 1 of the Handshake Protocol.

The heartbeat has two purposes:

1. It tells the sender that the recipient is still alive, even when the TCP connection had no activity for some time.
2. It makes activity on the connection during idle periods. This prevents closure by a firewall that does not accept idle connections.

Cryptographic computationsSearch on YouTubeBookmarkSaved

Master secretSearch on YouTubeBookmarkSaved

The shared master secret is a one-time 48-byte value. Secure key exchange makes it for this session. The creation has two stages:

1. The parties exchange a pre_master_secret.
2. Both parties calculate the master_secret.

There are two ways to exchange the pre_master_secret:

Both sides then compute the master secret:

$\text{master\_secret} = \text{PRF}(\text{pre\_master\_secret},\ \text{"master secret"},\ \text{ClientHello.random} \Vert \text{ServerHello.random})$

ClientHello.random and ServerHello.random are the two nonces from the initial hello messages. PRF is the pseudorandom function.

Key blockSearch on YouTubeBookmarkSaved

The second item is the generation of cryptographic parameters from the master secret. A CipherSpec needs six values:

The parties hash the master secret into a sequence of secure bytes of sufficient length. The slide formula is (the symbol ‘ on the slide means concatenation):

key_block =
  MD5(master_secret || SHA('A'  || master_secret || ServerHello.random || ClientHello.random)) ||
  MD5(master_secret || SHA('BB' || master_secret || ServerHello.random || ClientHello.random)) ||
  ...

The labels 'A', 'BB', 'CCC' and so on change for each block. The computation continues until the key_block is long enough.

Pseudorandom functionSearch on YouTubeBookmarkSaved

To make the PRF as secure as possible, TLS uses two hash algorithms in it. The PRF takes a secret value, an identifying label and a seed value. It gives an output of arbitrary length:

$\text{PRF}(\text{secret}, \text{label}, \text{seed}) = \text{P\_hash}(\text{secret}, \text{label} \Vert \text{seed})$

The data expansion function P_hash() is a chain of HMACs:

$A(0) = \text{seed}, \qquad A(i) = \text{HMAC}(\text{secret}, A(i-1))$

$\text{P\_hash}(\text{secret}, \text{seed}) = \text{HMAC}(\text{secret}, A(1) \Vert \text{seed}) \Vert \text{HMAC}(\text{secret}, A(2) \Vert \text{seed}) \Vert \cdots$

Each output block has a length equal to the hash size. P_hash repeats the chain until it has enough bytes.

Quick self-testSearch on YouTubeBookmarkSaved