Understanding HTTPS Encryption:
TLS, SSL, and Let's Encrypt

You have certainly noticed the locket sign in front of URLs that begin with HTTPS when browsing the web. HTTPS stands for Hypertext Transfer Protocol Secure and is the secure version of HTTP. Thanks to this protocol, data is securely communicated between browsers and websites.

An integral part of this process is Transport Layer Security (TLS), a protocol for authentication and encryption. TLS could be seen as a postal service that provides the sending of tamper-proof envelopes. A TLS certificate is the tool to seal the envelope, as well as remove the seal. The certificate authority (Let's Encrypt) is the entity verifying that you own the right to seal/unseal envelopes for a specific destination and grants you a license to do so for a finite amount of time. Their expertise makes them able to produce a unique license that is tamper-proof.

Let’s dig into the inner workings of HTTPS encryption, and specifically TLS, SSL, and Let’s Encrypt, by taking it one step at a time.

What is TLS?

TLS is a protocol used to establish authenticated and encrypted links between computers within a network. It is the standard protocol for keeping an internet connection secure, making the exchange of any sensitive data between two systems secure. It prevents other parties from reading and modifying any information transferred. In essence, it makes all the data transferred impossible to read.

According to the Open Systems Interconnection (OSI) Model, TLS sits between the Transport layer and the Application layer of a networking system, as seen in the image below.

tls and the osi model — Original image by Alexis Cascio

TLS vs. SSL

Secure Sockets Layer (SSL) is a legacy protocol, and TLS is its successor. SSL is also a protocol for establishing authenticated and encrypted links between computers within a network. The SSL protocol was deprecated with the release of TLS 1.0 in 1999, but it is still common to refer to these two technologies as “SSL” or “SSL/TLS” for convenience.

TLS/SSL termination

In any traffic encryption process, there are two sides — one side encrypts traffic, and the other decrypts it. Due to this fact, TLS termination always has to happen somewhere along the chain. In a client <-> reverse-proxy <-> server architecture, there are two ways to handle TLS termination.

Traffic passthrough: The reverse proxy intercepts the incoming encrypted traffic, but instead of handling the TLS termination, forwards the encrypted traffic to the server. In this scenario, the server performs the TLS termination and handles the computational and configuration costs of the decryption. To decrypt the encrypted traffic, the server needs to have the appropriate TLS certificates, keys, etc. — the bigger your infrastructure and the more servers you employ, the bigger the cost, as each server needs to have its own set of TLS certificates and keys.

TLS termination at the reverse proxy level: The reverse proxy intercepts encrypted traffic, handles the TLS termination, and communicates the data in clear text to the server. In this scenario, all workload and the cost of decryption are handled by the reverse proxy. The benefit of this approach is that everything takes place in the reverse proxy, and you don’t have to configure each server to handle TLS termination or manage TLS certificates and keys for each server separately.

What is Let’s Encrypt?

Let's Encrypt is a certificate authority (CA) that issues trusted certificates. Trusted certificates come from a trusted authority. This authority is trusted because it has not been compromised, meaning that no certificates from that authority could be obtained in a malicious way. In short, this means that the certificate used to secure the connection is indeed the one belonging to the website you are browsing.

How does Let’s Encrypt work?

According to the official Let’s Encrypt documentation:

“The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention. This is accomplished by running a certificate management agent on the web server.”
Source: letsencrypt.org

Let's Encrypt, provides Domain Validation (DV) certificates. It issues certificates for specific domains in exchange for proof of ownership for those domains. To make this exchange, domains rely on the ACME protocol. Nobody other than the owner of the domain can obtain the certificate. The ACME protocol defines the challenges that must be resolved to obtain a certificate. Challenges are scenarios where you can prove the ownership of one domain. There are three types of challenges:

HTTP: Proving ownership by serving a file containing a specific token on the specific domain (on a custom path).
TLS: Proving ownership by handling the connection to the specific domain with a temporary TLS certificate containing a specific token.
DNS: Proving ownership by creating a TXT record containing a specific token that would be then publicly available and verified by Let’s Encrypt.

Let’s Encrypt communicates the specific token to you after requesting a challenge in all three challenges.

Let's Encrypt CA is supported out-of-the-box by all browsers, but it’s not the only certificate authority available. The difference between Let's Encrypt and the other authorities is that it is free and easily automatable, thanks to its support within a lot of tools.

Other authorities proceed to identity checks — including legal identity checks — in order to issue TLS certificates. These authorities are ensuring you are who you say you are, and they are making sure they are issuing a TLS certificate to a genuine person or company. These certificates are called Organizational Validation (OV) certificates, and they are the reason why automation is less feasible when using those CA.

What is automated TLS certificate management?

Automated TLS certificate management is the automation of the TLS certificate issuance. It sounds a bit simplistic, but it essentially means that the initial issuance and the renewal of the TLS certificates are handled automatically by a process that handles ACME challenges for you.

Automating TLS certificates can have a significant impact on your business or day-to-day workload. Automated TLS is convenient — it saves you time, effort, and money by delegating the issuance of certificates to a tool capable of automating it.

How can you automate TLS?

In Traefik Proxy, TLS certificates can be obtained automatically, thanks to the routing configuration, and served right away to provide secured and trusted connections.

Traefik Proxy has two functions in this context, one being the TLS automation that takes care of the issuing and renewing of certifications. This is achieved by leveraging the actual routing configuration, saving you from all the extra hassle.

The second function is that it automatically loads/uses the TLS certificates it has obtained for the proper requests and serves them right away, with no additional configuration, to the correct routes, saving you time and effort. Check out this detailed guide on how to get started with Traefik Proxy and TLS to learn more.

See the API Gateway Cloud Natives TrustWant to simplify the discovery, security, and deployment of APIs and microservices? Explore Traefik Enterprise today.Learn More

Why should you encrypt your traffic?

Privacy and security are the two main reasons you should always encrypt your traffic, as it makes all data transferred impossible to read.

If you choose not to encrypt traffic, the impact on your business or organization can be significant. The leak of private, company, or client information is just one of the dire effects caused by non-encrypted traffic. This can even have legal consequences for companies if attackers manage to steal the personal information of customers. In short, unencrypted traffic is considered a serious security breach that can later escalate to a potential breach of your infrastructure.

Networking is about routing data and delivering it to the right user. Not unlike posting a physical letter, data is transmitted over wires to reach the right recipient. But to do so, data is passing through entities composing the network; each of them can potentially read the data. If the data is in clear text, it is very easy to read its contents and even modify them. This way, an attacker can exploit data by taking control of the original data exchange, assuming the role of the user who initiated the exchange — also known as a man-in-the-middle attack.

Encrypted traffic is also a basic requirement for web browsing as more and more users are now aware of potential security issues when using the internet. Having an unsecured website can seriously hurt the image of your organization.

SEO is yet another factor you should take into consideration. Google, as well as most browsers, favor HTTPS, so your application is less likely to be found organically and may be inaccessible or not function fully without encryption. And going even beyond SEO, encrypted traffic is also a basic requirement for web browsing.

More and more users are now aware of potential security issues when using the internet. They know they should not trust a website that does not provide an HTTPS connection. So, having a secure website is also a matter of company image and trust.

In the future, it is reasonable to assume that browsers will not support plain text HTTP. Google Chrome, for example, recently made its first step in this direction by announcing an HTTPS-Only Mode that upgrades all non-encrypted HTTP connections to encrypted HTTPS alternatives when possible. Firefox has already been doing the same since 2020.

How can Let’s Encrypt help and why should you use it?

Now that you understand the risks of unencrypted traffic, you can also understand the significance of adding a mechanism for issuing trusted certificates to your networking infrastructure. As mentioned earlier, Let’s Encrypt is a Certificate Authority and is trusted and secure. It is also important to emphasize that it is free!

Since Let’s Encrypt uses domain validation certificates, it is very easy to automate. After the initial setup of the certificate issuance for a certain domain, you can use Let’s Encrypt to completely automate the process of renewing certificates.

Distributed Let’s Encrypt

Finally, let’s take the principles of Let’s Encrypt to the next level. With multi-cluster Kubernetes architectures gradually becoming the norm, the hassle that is TLS certificate management continues to increase. And although you can delegate this responsibility to Let's Encrypt, integrating automated certificate management in a distributed environment is no walk in the park. How can you avoid generating duplicate certificates, and how can you share certificates?

That's where Traefik Enterprise comes in.

Traefik Enterprise clusters communicate with an external agent to share Let's Encrypt certificates. The operating principles are simple: Traefik Enterprise clusters reach the agent to request certificates, and the agent generates the certificates. The agent then stores the certificates in a HashiCorp Vault instance, which is then used by the Traefik Enterprise clusters to provide the certificates. Check out this guide to learn more about distributed Let’s Encrypt with Traefik Enterprise.

Now your traffic is encrypted in an automated, worry-free setup throughout your environment. Time to take a break.

Try the API Gateway Cloud Natives TrustWant to simplify the discovery, security, and deployment of APIs and microservices? Try Traefik Enterprise free.Start Your Free Trial