Deep Dive: Fundamentals of HTTP/HTTPS, SSL/TLS and Encryption

In this article we’ll look at the security side of an application: the industry standards that keep your users’ data safe as it travels over the network. It isn’t a networking deep dive. The aim is to understand these concepts from an application developer’s point of view.

Why secure the connection?

Without a secure connection, anything sent over the network is exposed to attackers, and a compromise can have serious consequences.

Say you log in to an online banking site that isn’t secure. Your credentials cross the network as plain text, and an attacker who has broken into the network can simply read them and take over the account.

Encryption

In simple terms, encryption scrambles text (the username and password in our example) with an algorithm before it’s sent. The result is unreadable, and only the intended recipient can decrypt it. There are two kinds of encryption used to send data over a network: symmetric and asymmetric.

Symmetric encryption

Symmetric encryption uses a single key to encrypt the plain text, and only that same key can decrypt it. It’s fast and lightweight, but it has a flaw when used over a network. Can you guess what it is?

That’s right: the recipient needs the key to decrypt the text, so the key has to be sent over the network too. If an attacker gets hold of the key, the encryption is worthless.

So we have a fast, lightweight algorithm, but how do we get the symmetric key safely to the other side?

Asymmetric encryption

Asymmetric encryption overcomes this by using a pair of keys: a public key and a private key. Anything encrypted with the public key can only be decrypted with the private key. Anyone can have the public key and use it to encrypt data, but even an attacker holding the public key and the encrypted data can’t decrypt it without the private key. The private key stays safely on the server and is never sent over the network.

Here’s how the two work together:

1. The client asks the server for data, and the server sends its public key.
2. The attacker copies the public key as it crosses the network.
3. The client generates a symmetric key and encrypts it with the public key.
4. The client sends the encrypted symmetric key to the server.
5. The server decrypts it with its private key, so now both sides have the symmetric key.
6. The attacker has the encrypted key too, but can’t decrypt it.
7. From here on, data is encrypted with the symmetric key.

Asymmetric encryption is very secure, but it’s much slower and heavier than symmetric encryption. So the standard approach is to use asymmetric encryption to set up a secure session, then symmetric encryption for the data inside it.

But wait. What if an attacker on the network reroutes all the traffic meant for the bank to their own look-alike site, and tricks you into entering your credentials there?

1. The attacker takes control of the network and routes the traffic to their own site.
2. You enter your credentials. The fake site hands you the attacker’s public key, so the attacker can decrypt everything with their own private key, and the account is compromised.

Is there a way for clients and browsers to tell the real bank from the fake one? This is where SSL (Secure Sockets Layer) and TLS (Transport Layer Security) come in.

SSL and TLS

SSL is the protocol that encrypts communication over a network, using both symmetric and asymmetric encryption as described above. TLS is its modern successor; SSL itself is deprecated. The name stuck, though, and people use SSL and TLS interchangeably.

To serve a site over TLS, the owner needs a TLS certificate. Once installed, the certificate is what lets browsers tell legitimate sites from impostors.

TLS certificates

Earlier, the server sent its public key before the secure session was set up. In TLS, the server sends a certificate instead: a document that contains its public key and the name of the site it belongs to, signed so that clients can trust it.

Creating a certificate

You can create a certificate with openssl, or with keytool for Java applications. But once you have one, how do clients and browsers know the site is legitimate?

The certificate has to be signed. You could sign it yourself, but nobody is going to trust a certificate you vouched for yourself. That’s where certificate authorities (CAs) come in.

You send a certificate signing request (CSR) to a recognised CA, such as DigiCert or Let’s Encrypt. The CA checks that you really control the domain (and, for some certificates, who you are as an organisation), then signs your certificate.

An attacker asking a CA to sign a certificate for your bank’s domain will be turned down, because they can’t prove they control it. But what if the attacker gets a fake CA to sign it?

How the browser decides

This is where your browser and operating system come in. They ship with a trust store: a list of CA root certificates they trust. A site’s certificate has to chain back to one of those roots:

On a Mac, you can see the trusted roots in Keychain Access → System Roots → Certificates. A few of them:

Name	Expires
AAA Certificate Services	Dec 31, 2028
AC RAIZ FNMT-RCM	Dec 31, 2029
ACCVRAIZ1	Dec 31, 2030
Actalis Authentication Root CA	Sep 22, 2030
Apple Root CA	Feb 9, 2035

When a site’s certificate doesn’t check out, because it isn’t signed by a trusted CA, has expired, or was issued for a different domain, the browser stops and shows a full-page warning such as “This Connection Is Not Private” or “Your connection is not private”, telling you the site may be impersonating the one you asked for.

Conclusion

That’s it for this article. I hope it gave you a good grasp of these concepts. If you want to see the keytool commands for generating a certificate and using it in an application, read How to Enable HTTPS (SSL/TLS) in a Java Spring Boot Application.

References

• What is SSL/TLS encryption? (F5 glossary)
• How Let’s Encrypt works
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3