ESP32/ESP8266 with HTTPS and SSL/TLS Encryption: Basic Concepts

This article is a quick and simple introduction to HTTPS and SSL/TLS encryption with the ESP32 and ESP8266 NodeMCU board. We’ll take a look at some concepts and terms that you’ve probably heard before but you might not know exactly what they mean: HTTPS, SSL/TLS, certificates, asymmetric and symmetric key encryption, and more.

Table of Contents

Throughout this article, we’ll cover the following subjects:

• What is HTTPS?
  • Why do you need HTTPS?
• What is SSL/TLS?
• How does SSL/TLS encryption work?
  • Public key and private key
• Communication over HTTPS
• SSL certificates
• Self-signed certificates
• ESP32: HTTPS requests (Arduino IDE)
• ESP32 HTTPS server (Arduino IDE)
• ESP8266: HTTPS requests (Arduino IDE)
• ESP8266 HTTPS server (Arduino IDE)

What is HTTPS? 

HTTPS is the secure version of the HTTP protocol, hence the “S”, which stands for secure.

HTTP is a protocol to transfer data over the internet. When that data is encrypted with SSL/TLS, it’s called HTTPS.

To simplify, HTTPS is just the HTTP protocol but with encrypted data using SSL/TLS.

Why do you need HTTPS?

Using HTTPS ensures the following:

• Privacy: no one can spy on your requests and passwords because the messages are encrypted.
• Integrity: the message is not manipulated on its way to its destination (prevents men-in-the-middle) attacks.
• Identification: when using HTTPS, via SSL certificates, you ensure you are connected to the server you would expect.

What is SSL/TLS?

SSL stands for Secure Socket Layer and TLS stands for Transport Layer Security. These are two protocols used for secured encryption. SSL is currently deprecated. TLS 1.3 is currently the most recent protocol used for secure encryption on the web.

How does SSL/TLS encryption work?

There are two types of encryption algorithms: symmetric key algorithm and asymmetric key algorithm.

Symmetric Key Encryption

With a symmetric-key algorithm, the same key is used to encrypt and decrypt the messages. So, both the client and server need to have the same key.

The disadvantage of using a symmetric key algorithm is that keys are hard to share and you need to be careful how and with who you distribute the key.

Asymmetric Key Encryption

The SSL/TLS encryption uses asymmetric keys.

How does asymmetric key encryption work? Very briefly:

• You have two asymmetric keys: a public key and a private key.
• The public key and private key work together.
• The public key, as the name suggests, is visible to anyone.
• Only the private key can decrypt the message encrypted with the corresponding public key.

Public Key and Private Key

In summary, here’s how it works:

• The browser client tries to contact the server.
• The server sends the public key to the client (browser) via the server’s SSL certificate.
• The browser sends a message to the server encrypted with the public key.
• Only the ones with the private key (the server) can decipher the message.

Communication over HTTPS

How the communication between the server and client works over HTTPS? The following diagram shows a high-level overview of how it works.

• You, the client on your browser, try to connect with the server (1);
• The server sends back its certificate (2) so that the browser can check the authenticity of the server (3). The certificate contains the public key.
• If the certificate is valid, the client creates a new key (called session key) (4) that will be used later to encrypt communication between the client and server.
• The client encrypts the session key using the public key sent by the server (5).
• The server receives the session key encrypted with the public key and can decipher the message because only the server has access to the corresponding private key to decrypt the message (6);
• From now on, both the client and server have a secret key (that’s only known to them) that they can use to encrypt further communication (7) (symmetric key encryption).

SSL Certificates

SSL certificates are issued by legitimate Certificate Authorities. One of the most known is LetsEncrypt. Certificate Authorities also confirm the identity of the certificate owner and provide proof that the certificate is valid. 

When a Certificate Authority issues a certificate, it signs the certificate with its root certificate. This root certificate should be on the database of trusted certificates.

Your browser then checks if the certificate is valid (if it was signed with a root certificate on the database of trusted root certificates) and displays a green lock icon on the browser bar if it is.

Self-signed Certificates

You can self-sign your certificates. These provide the same level of encryption as one generated by an authority, and these are free. However, all browsers will check if the certificate is issued by a trusted Certificate Authority. So, you’ll be warned by your browser that the site you’re visiting is not safe because it doesn’t trust the certificate and so, can’t identify its owner.

The web browser will display a warning sign and the HTTPS letters in red. This means the website has a certificate, but the certificate is unverified (like self-signed certificates) or out of date. This means that the connection between you and the server is encrypted, but no one can guarantee that the domain really belongs to the company indicated on the site. 

Self-signed certificates are fine to use on your DIY and IoT projects, intranets, like your local network, or inside a company’s network. However, if you’re creating a project for a company that will be accessed by clients outside the company network, like a public website, it’s best to use a certificate from a Certificate Authority.

SSL certificates have an expiry date. So, if you’re using an ESP32 to connect to a website via HTTPS, you should keep in mind that you’ll need to update the code with the new website’s certificate in the future.

If you’re still confused about all of these new terms, we recommend taking a look at the following website that explains in a fun way how everything works: https://howhttps.works/.

ESP32: HTTPS Requests (Arduino IDE)

If you’re familiar with HTTP requests with the ESP32 “migrating” to HTTPS is very straightforward.

If you’re using the WiFiClient library, you just need to make the following changes:

1. Use WiFiClientSecure.h library instead of WiFiClient.h
2. Use port 443 instead of port 80
3. Change the host URL to https instead of http

With this, you ensure that your communication is encrypted using TLS.

An additional security step is to check the server certificate (the certificate of the website you want to connect to). You can skip this step while testing and prototyping. The communication will be encrypted, but you won’t be sure of the integrity of the server you are trying to communicate with.

You can also find examples using HTTPS with the HTTPClient library.

If you want to start working on your HTTPS requests right away, take a look at the examples provided in the ESP32 package for the Arduino core.

• WiFiClientSecure example: File > Examples > ESP32 > WFiClientSecure > WiFiClientSecure
• HTTPClient with HTTPS example: File > Examples > ESP32 > BasicHttpsClient > BasicHttpsClient

ESP32 HTTPS Server (Arduino IDE)

At the moment, there are not many examples of building an HTTPS web server with the ESP32 using the Arduino core. Unfortunately, the AsyncWebServer library that we use in most of our projects, doesn’t fully support HTTPS at the moment.

Nevertheless, there is another library that provides easy methods to build an ESP32 HTTPS web server, including an example that generates certificates on the fly. Here’s a link to the library: esp32_https_server library.

If you’re familiar with ESP-IDF, you can take a look at the documentation on the following link:

• ESP-IDF HTTPS Server Documentation

ESP8266 HTTPS Requests (Arduino IDE)

There are several examples that show how to make HTTPS requests with the ESP8266. You can check the examples available in your Arduino IDE. Make sure you have the latest version of the ESP8266 boards installed to make sure you have access to the latest version of the examples and that these will work.

To update the ESP8266 boards’ installation, you just need to go to Tools > Boards > Boards Manager, search for ESP8266, and install the latest version.

Then, you’ll have access to the examples’ latest version. You can check the following examples:

• Basic HTTPS Client using the ESP8266HTTPClient library: File > Examples > ESP8266HTTPClient > BasicHttpsClient
• Basic HTTPS Client using WiFiClientSecure library: File > Examples > ESP8266WiFi > HTTPSRequest

You’ll need to update the certificates and fingerprints to make the examples work. If you can’t make the examples work, don’t worry, we’ll publish some tutorials with examples and instructions soon.

ESP8266 HTTPS Server (Arduino IDE)

The ESP8266 is not optimized for SSL cryptography, so running an HTTPS Server on the ESP8266 is very demanding. You need to set the clock frequency to 160MHz and even so, you might get unexpected resets on the board.

For an ESP8266 HTTPS web server, you can take a look at an example using the ESP8266WebServer library on the following link:

• ESP8266 HTTPS Server (BearSSL)

Wrapping Up

In this tutorial, we’ve taken a look at the HTTPS protocol, SSL/TLS encryption, and SSL certificates. I’m far from being an expert in these subjects, so if anything doesn’t sound right in this article, please let me know in the comments below.

We’ve also taken a quick look at possible ways to secure your ESP32/ESP8266 IoT projects: how to make HTTPS requests and how to set the ESP32/ESP8266 as an HTTPS server with a certificate. We’ll create more tutorials with practical examples about these subjects in the upcoming weeks, so stay tuned.

If you have any examples of HTTPS servers with the ESP32 or are familiar with any other libraries to build an HTTPS server, please share them in the comments below.

Thanks for reading.