Transport Layer Security (TLS)

• Transport Layer Security
• Wikipedia
• Successor protocol to SSL

At the heart of TLS is Public Key Infrastructure (PKI) and in particular X.509 certificates.

Overview

• https://www.cloudflare.com/en-gb/learning/ssl/transport-layer-security-tls/

The Transport Layer Security (TLS) protocol is used to establish a secure connection between a client and a server and ensure the privacy and integrity of information during transmission. It uses a symmetric key for bulk encryption, asymmetric key for Authorization and key exchange, and message authentication codes for message integrity. It uses the RSA algorithm with strengths of 1024 and 2048 bits. Using TLS, one can reduce security risks such as message tampering, message forgery, and message interception. An advantage of TLS is that it is independent of the application protocol. Higher-level protocols can lie on top of TLS transparently. TLS consists of two layers: TLS Record Protocol and TLS Handshake Protocol.

SSL (Secure Sockets Layer)

The Secure Sockets Layer (SSL) protocol is an Application Layer protocol developed by Netscape for managing the security of message transmission on the Internet. It is used to provide a secure authentication mechanism between two communicating applications, such as a client and a server. SSL requires a reliable transport protocol, such as TCP, for data transmission and reception. It uses RSA asymmetric (public-key) encryption to encrypt data transferred over SSL connections. Any application-layer protocol that is higher than SSL, such as HTTP, FTP, and Telnet, can form a transparent layer over SSL. SSL acts as an arbitrator between the encryption algorithm and the session key; it also verifies the destination server prior to the transmission and reception of data. SSL encrypts the complete data of the application protocol to ensure security.

SSL also offers "channel security" with three basic properties:

• Private channel – All the messages are encrypted after a simple handshake is used to define a secret key.
• Authenticated channel – The server endpoint of the conversation is always encrypted, whereas the client endpoint is optionally authenticated.
• Reliable channel – Message transfer has an integrity check.

SSL uses both asymmetric and symmetric authentication mechanisms. Public-key encryption verifies the identities of the server, the client, or both. Once authentication has occurred, the client and server can create symmetric keys, allowing them to communicate and transfer data rapidly. An SSL session is responsible for carrying out the SSL handshake protocol to organize the states of the server and clients, thus ensuring consistency of the protocol.

SSL Handshake Protocol Flow

The SSL handshake protocol works on top of the SSL record layer. The processes executed in the three-way handshake protocol are as follows:

1. The client sends a hello message to the server, to which the server must respond with a hello message, or the connection will fail due to the occurrence of a fatal error. The attributes established due to the server and client hello are protocol version, session ID, cipher suite, and compression method.

2. After the connection is established, the server sends a certificate to the client for authentication. In addition, the server might send a server-key exchange message. On authentication of the server, it may ask the client for the certificate (if appropriate for the cipher suite selected).

3. The server sends a "hello done" message to inform the client that the handshake phase is complete and waits for the client's response.

4. If the client receives a certificate-request message, the client must respond to the message by sending a certificate message or "no certificate" alert. The server sends the client key-exchange message. The content of the message depends on the public-key algorithm between the server hello and the client hello. If the certificate sent by the client has signing ability, a digitally signed certificate verifies the message, and the client transmits it.

5. The client transmits the changed cipher-spec message and copies the pending cipher spec into the current cipher spec. The client sends a message to initiate the completion of the message under the new algorithm, keys, and secrets.

6. In response, the server replies by sending its own changed cipher-spec message, transfers the pending cipher spec to the current cipher spec, and initiates the completion of the message under the new cipher spec. At this point, the handshake is complete and the server starts exchanging the application-layer data.

SSL Session Resumption

The resumption of a previous session or the replication of an existing session proceeds as follows:

• The client initiates the communication by sending a hello message with the session ID of the session that is to be resumed.
• If the server finds a match, it re-establishes the session under the specified session state with the same session ID.
• At this point, both the server and the client exchange the changed spec messages and proceed directly to the finished messages.
• After re-establishment, the server and client exchange data at the application layer.
• If the session ID does not exist, the server creates a new session ID. The SSL client and server then carry out a complete handshake.

TLS Protocol Architecture

1. TLS Record Protocol

The TLS Record Protocol is a layered protocol. It provides secured connections with an encryption method such as DES. It secures application data using the keys generated during the handshake and verifies its integrity and origin. The TLS Record Protocol provides connection security with two basic properties:

• The connection is private: Uses symmetric cryptography for data encryption (e.g., DES). The protocol generates unique keys for symmetric encryption for each connection, depending on a secret negotiated by another protocol (such as the TLS Handshake Protocol). One can use the TLS Record Protocol without encryption.
• The connection is reliable: It provides a message integrity check at the time of message transport using a keyed MAC. Secure hash functions (e.g., SHA, md5) help to perform MAC computations.

The TLS Record Protocol does the following:

• Fragments outgoing data into manageable blocks and reassembles incoming data
• Optionally compresses outgoing data and decompresses incoming data
• Applies MAC to the outgoing data and uses MAC to verify the incoming data
• Encrypts outgoing data and decrypts incoming data

The TLS Record Protocol sends the outgoing encrypted data to the TCP layer for transport.

2. TLS Handshake Protocol

The TLS Handshake Protocol allows the client and server to authenticate each other and select an encryption algorithm and cryptographic keys prior to data exchange by the application protocol. It provides connection security with three basic properties:

• The peer's identity can be authenticated using asymmetric cryptography. This can be made optional but is mostly required for at least one of the peers.
• The negotiation of a shared secret is secure.
• The negotiation is reliable.

The TLS Handshake Protocol operates on top of the TLS Record Protocol and is responsible for producing cryptographic parameters of the session state. At the start of communication, the TLS client and server agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use asymmetric cryptography techniques to create shared secrets.

The steps involved in the TLS Handshake Protocol are as follows:

• Initially, the client sends a "Client hello" message accompanied by the client's random value and supported cipher suites to the server.
• The server responds to the client by sending a "Server hello" message accompanied by the server's random value.
• The server sends its certificate to the client for authentication and may request the client's certificate. The server sends the "Server hello done" message.
• The client sends its certificate to the server, if requested.
• The client generates a random pre-master secret and encrypts it with the server's public key; then, it sends the encrypted pre-master secret to the server.
• The server receives the pre-master secret. Thereafter, the client and server each create the master secret and session keys based on the pre-master secret.
• The client sends "Change cipher spec" to the server to indicate that it will start using the new session keys for hashing and encrypting messages. The client also sends "Client finished".
• The server receives "Change cipher spec" from the client and switches its record layer security state to symmetric encryption using the session keys. Then, the server sends "Server finished" to the client.
• Now, the client and server can exchange application data over the secure channel they have established, and all the messages exchanged between the client and server are encrypted using a session key.

TLS Handshake Process

TLS is still using TCP as its transport protocol, so we will still see acknowledgment packets from the stream coming over port 443.

1. Client and server exchange hello messages to agree on connection parameters.
2. Client and server exchange necessary cryptographic parameters to establish a premaster secret.
3. Client and server will exchange x.509 certificates and cryptographic information allowing for authentication within the session.
4. Generate a master secret from the premaster secret and exchanged random values.
5. Client and server issue negotiated security parameters to the record layer portion of the TLS protocol.
6. Client and server verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.

• We can see that the client establishes a session to the server using port 443 boxed in blue:

  • This signals the server that it wishes to use HTTPS as the application communication protocol.

• Once a session is initiated via TCP:

  • A TLS ClientHello is sent next to begin the TLS handshake

• During the handshake several parameters are agreed upon:

  • Session identifier
  • Peer x509 certificate
  • Compression algorithm to be used
  • The cipher spec encryption algorithm
  • Session resumability
  • A 48-byte master secret shared between the client and server to validate the session.

• Once the session is established:

  • All data and methods will be sent through the TLS connection and appear as TLS Application Data as seen in the red box

TLS CA Certificates

Certificates are data structures that include a public key, a digital signature, and some other data. Clients use certificates to authenticate servers during TLS handshakes.

Issues

CA certificate key too weak

References

• curl - SSL CA Certificates

Tools

Links

1. openssl
2. Debugging SSL
3. Debugging SSL in Spring
4. TLS Client Authentication

Documentation

• https://carrickbartle.com/certificates.html