0th Root Secure Network (0SNet)
Negotiation of TLS Parameters for HTTPS Encryption
Information that is leaked and efforts to secure them
Browsing the web was originally insecure allowing eavesdroppers to see exactly what the user was doing. This is no longer possible due to the use of Transport Layer Security (TLS) underneath to encrypt all of the web traffic. However, before the data becomes encrypted, the client and server negotiate the parameters for encryption in the form of Hello messages.
This initial negotiation to establish a secure session happens in cleartext. It involves a handshake mechanism with a Hello message sent by the client (ClientHello) and a Hello response by the server (ServerHello).
A few basics on the TLS protocol (Version 1.2) —
- Client and Server exchange data in the form of Records
- Record can be one of 4 types: Alert, Handshake, Application Data, or Change Cipher
Client Hello
ClientHello message is of Handshake Record type and is the first message in the protocol. A sample format of the message is shown below,
This message includes the protocol version, client’s random number, the session identifier, accepted ciphers, and compression methods. Optionally, extensions may be present, such as the server_name extension which provides the domain name of the website to the server.
Do note, as the message is in plain text it is possible for eavesdroppers to parse the server_name extension and know which site the user is connecting to. Recently, there are renewed efforts to encrypt this in the form of Encrypted Client Hello (ECH), discussed later in this article.
Server Hello
In response to the ClientHello, the server sends a ServerHello message,
This message informs the client of the chosen protocol version (eg: TLS 1.2), selected cipher from the list of ciphers that the client provided (eg: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384), server’s random number, and its supported extensions.
Immediately after the Hello message, the Server sends out 3 additional messages in a sequence, which are Server Certificate, Server Key Exchange, and Server Hello Done. The first message provides the server’s certificate for the client to verify, while the second message contains the key exchange parameters to generate a temporary secret which ultimately is used to create the final encryption key, and the last one is simply a signaling message.
Do note, all of these still continue to be in plain text. There are mechanisms within these messages to detect tampering by a middle man. However, an eavesdropper will still know the cipher used and the certificate provided by the server that could contain personal information such as, to whom the certificate was issued.
Encryption
Finally, the client processes the server’s Hello messages and sends its part of the key exchange parameters as a Client Key Exchange message. Now, both the client and server can generate the temporary secret. With which, create an identical set of keys for encrypting and decrypting application data.
A Change Cipher message is sent by both parties as a signal to switch to encrypted data transfer. All Records following that message will be fully encrypted with the newly established key.
It is important to note, client, verifies the server’s certificate using a database of trusted root certificates before sending the Client Key Exchange message. This is done in order to ensure the endpoint acting as the server, with whom the encryption parameters are being negotiated, is legitimate.
TLS Version 1.3
The newer version of the protocol has significant changes, which will be discussed in a separate article, one of them is the encryption of the server’s certificate. This is intended to only protect from passive monitoring, as described in the security properties of the protocol,
Protection of endpoint identities: The server’s identity (certificate) should be protected against passive attackers. The client’s identity should be protected against both passive and active attackers.
The protocol introduces a new message EncryptedExtensions to protect the information in extensions sent by the server. However, this does not protect the extensions in ClientHello, such as server_name, which continue to remain in plain text.
Encrypted Client Hello
A work in progress specification defines a new extension Encrypted Client Hello for TLS 1.3 that encrypts the contents of server_name, and other sensitive, extensions in the ClientHello message. While this ensures the communication over TLS is fully confidential, it will still be possible to deduce some information through other channels, such as plain text DNS queries.
The specification goes to considerable lengths to achieve its goals. It uses a ClientHelloOuter structure which is the actual ClientHello message with the encrypted_client_hello extension, and the extension data containing the encrypted ClientHelloInner structure and associated encryption parameters.
ClientHelloInner is the to-be-used ClientHello message for servers that understand encrypted_client_hello extension. It will ultimately contain the domain name for the website within server_name extension, and hence keeping it protected from passive monitoring.
There is considerable work already in progress to secure the information transmitted over TLS. However, there are still several areas that need to be worked on to ensure the complete confidentiality of the communication. It is yet to be seen if it is even possible. As they say, Humans are the weakest link in security.
References:
At 0th Root, we provide a solution 0th Root Secure Network — 0SNet to secure the organization’s internal web apps with TLS client certificates. Do check out our product, it is easy to deploy and available as images on AWS, GCP, and Azure.
