In today's digital world, the security of data exchange on the Internet is of crucial importance. HTTPS (HyperText Transfer Protocol Secure) is a protocol that ensures the secure transfer of data between a web server and a web browser. In this blog post, we will take an in-depth look at the HTTPS transport protocol, explain the role of TLS 1.2 (Transport Layer Security) and go into detail about how encryption and CA (Certificate Authority) validation work. At the end of the article, we have created a summarised example of an HTTPS request from a client to the web server www.swissmakers.ch for better understanding. This is intended to summarise the individual steps once again in a conclusive and comprehensible manner.

HTTPS and TLS: A brief overview

HTTPS is an extension of the HTTP protocol and uses TLS to ensure secure communication over a computer network. While HTTP transmits the data in plain text, HTTPS encrypts the data to protect it from unauthorised access.

TLS is the protocol that enables secure communication via HTTPS. It consists of two main phases: the TLS handshake and the Data transmission (record protocol).
The TLS handshake is used to establish a secure connection between the client (web browser) and the server (web server), while the data transfer takes over the actual encryption of the data with the negotiated keys.

The TLS handshake in detail

The TLS handshake is a multi-stage process that comprises the following simplified steps:

Client HelloThe client sends a message to the server with the supported TLS versions, encryption suites and other configuration parameters that are supported by the client.
Server HelloThe server responds with its supported versions and selects the most secure parameters available for the connection, including the TLS version and encryption suite supported by both parties.
Certificate exchangeThe server sends its public digital certificate (which contains the public key, among other things), which has been signed by a trusted certification authority (CA), to the client.
Key exchangeAfter successful validation by the CA (on the client side), the client and server exchange cryptographic keys (asymmetrically encrypted) in order to later establish a symmetric encryption to make this possible. This can be done using various methods, e.g. with RSA or alternatively Diffie-Hellman.
Handshake conclusionBoth parties confirm that the handshake is complete.
The secure connection is established using symmetric encryption.

Encryption and decryption of data

After a successful TLS handshake, the encrypted transmission of the data begins. Symmetric encryption algorithms such as AES (Advanced Encryption Standard) are used. Symmetric encryption means that the same key for both encrypting and decrypting the data is used.

Symmetric encryption

Server-side encryptionThe server encrypts the data with the symmetric key and sends it to the client.
Client-side encryptionThe client encrypts its requests or responses with the same symmetric key and sends them to the server.

This method ensures that only the respective client and server can encrypt, decrypt and read the transmitted data.

Asymmetric encryption and key exchange

With the TLS handshake, asymmetric encryption is used to securely exchange symmetric keys. A key pair is used, which consists of a public key (public key) and a private key (private key):

Public keyIs sent from the server to the client and can be used by anyone to encrypt data.
Private keyIs stored securely on the server and used to decrypt the data encrypted with the public key.

The actual key exchange can take place using various methods, including RSA key exchange or an additional Diffie-Hellman key, which can be configured on the server. Diffie-Hellman is a method in which two parties can jointly generate an additional secret key, even if the communication takes place over an insecure connection. This method can be used in combination with other algorithms, for example to increase the security of a reverse proxy or a web server.

It is important to emphasise that TLS also works without the additional implementation of Diffie-Hellman. The RSA key exchange, in which the symmetric key is encrypted with the server's public key and then decrypted by the server with its private key, is the standard procedure.

CA validation

The validation of the public key via trusted public certification authorities (Public Trusted Root CAs) is an important part of the TLS handshake for a connection that is later considered "secure". This is because the respective CA checks the identity of the server operator based on the domain when requesting the creation of a new public key (setting up a new HTTPS-encrypted website) and only issues a digital certificate (which confirms the authenticity of the https://-Seite that can later be accessed) if all checks have been successfully completed.
It can therefore be assumed (in most cases) that once the server certificate has been successfully checked by the client, it is valid and no man-in-the-middle attacks can take place.

The client certificate check: The client (browser) checks the certificate during the TLS handshake by checking the certificate chain against the List of trusted root CAs validates / checks checksums. If the certificate is classified as trustworthy and the certificate chain has not been broken, a validated and secure connection can be established. In our case, the root CA is "ISRG Root X1", from which a sub-CA called "R3" was created, which in turn issued our certificate for "swissmakers.ch".

Why not just anyone can obtain a certificate for any domain

As already briefly mentioned, in order to successfully issue a new certificate for a "new to be encrypted" website connection via HTTPS, the owner rights must first be checked. At Let's Encrypt, for example, the following checks can be carried out:

DNS validationThe applicant must create a specific DNS entry, which the CA can check by performing a DNS query on the relevant domain before issuing.
HTTP validationThe applicant must store a specific file in the web server root of the domain or enable a similar automated verification method via a web server module, which in turn can be retrieved and verified by the CA.

Only the owner of the domain can make the two necessary settings for these validation types and therefore only he can apply for and receive a new certificate.

The creation of a new certificate roughly involves the following steps:

Certificate applicationThe server operator applies for a digital certificate from a CA. For example, Let's Encrypt can be used to obtain a free certificate. The certificate request is signed with a previously generated local private key.
VerificationThe CA checks the identity of the applicant and validates that they have the necessary rights as the owner of the domain for which the certificate is being issued. For example, Let's Encrypt can carry out domain validation via DNS entries, which are to be created by the server operator.
Issue of the certificateAfter successful verification, the CA issues the digital certificate and signs it with the CA's private key.

Example: HTTP request to www.swissmakers.ch

Here is a detailed example of what happens when a PC sends an HTTP request to www.swissmakers.ch via a web browser:

DNS resolutionThe browser resolves the domain www.swissmakers.ch into an IP address via DNS (Domain Name System).
Connection setupThe browser initiates a TCP connection to the IP address of the server.
TLS handshakeThe browser starts the TLS handshake to establish a secure connection:
- The browser sends a Client Hello Message.
- The server responds with a Server Hello message and sends its digital certificate.
- The browser checks the certificate against the list of trusted CAs.
- The browser and the server exchange cryptographic keys.
- Both parties confirm the conclusion of the handshake.
Secure data transmissionAfter the TLS handshake, the actual HTTP request is sent via the encrypted connection (HTTPS):
- The browser sends an encrypted GET request to the server "https://www.swissmakers.ch".
- The server processes the request and sends back the encrypted response.
Display of the website: The browser decrypts the response and displays the web page to the user. www.swissmakers.ch to:

Conclusion

HTTPS and TLS play a crucial role in securing communication on the internet. The use of encryption and certificate validation ensures that data is transmitted securely between the client and the server. Understanding how HTTPS and TLS work is essential to ensure secure external and internal communication between application servers and clients.

For more in-depth information on algorithms or protocols, we recommend the Youtube channel of the renowned Professor of Cryptography Prof Dr Christof Paar.

We hope that this blog post has given you an overview of the HTTPS transport protocol and the role of TLS in secure data transmission. Stay safe and make sure you use encrypted connections in your internal networks too!

Michael Reber

Years of experience in Linux, security, SIEM and private cloud