Lecture 1: TLS for Secure Communication

TLS for secure communication

#

TLS authenticates the remote server and encrypts traffic in transit. Assignment 1 uses the ESP-IDF example https_mbedtls: an HTTPS client on the ESP32-S31-Function-CoreBoard-1 that calls mbedTLS directly (mbedtls_ssl_*, mbedtls_net_*), GETs https://www.howsmyssl.com/a/check, and prints the JSON response.

Other examples wrap the same crypto in ESP-TLS (for example https_request). We use https_mbedtls so the handshake and certificate checks stay visible in one source file.

Learning objectives

#

By the end of this lecture, you should be able to:

• Say what TLS protects on the network path (and what it does not)
• Enable the certificate bundle and explain esp_crt_bundle_attach()
• Outline the flow in https_mbedtls_example_main.c: connect, handshake, verify, HTTP read
• Relate hostname setting and verify mode to Assignment 1 failure tests

Threat model (short)

#

TLS helps when someone on the LAN or path could sniff traffic, run a fake server, or steer the device to the wrong host. Server authentication plus a correct hostname check addresses that for the TLS session.

It does not fix a compromised device, a bad trust store, disabled verification, or missing backend authorization. Wi-Fi credentials only reach the AP; TLS protects the app’s session to the service.

Reference example architecture

#

app_main: NVS, esp_netif, then example_connect() (Wi-Fi from menuconfig in this workshop) and a task that runs the client.

https_get_task: defaults to www.howsmyssl.com:443. In order: attach the cert bundle to the SSL config, set hostname, require peer verification, TCP connect, handshake, check mbedtls_ssl_get_verify_result, send a small HTTP GET, read the response. The task loops after a delay.

What the TLS handshake establishes

#

sequenceDiagram
    participant Device as ESP32-S31
    participant Server as HTTPS server

    Device->>Server: 1. Hello: requested hostname and supported algorithms
    Server-->>Device: 2. Certificate chain and key-exchange data
    Device->>Device: 3. Is the certificate issued by a trusted CA?
    Device->>Device: 4. Does its SAN match the requested hostname?
    Note over Device: Stop if either check fails
    Device->>Server: 5. Complete the key exchange
    Server-->>Device: 6. Confirm the handshake
    Note over Device,Server: Both sides now share temporary session keys
    Device->>Server: 7. Encrypted and authenticated HTTP request
    Server-->>Device: 8. Encrypted and authenticated HTTP response

TLS provides three different properties that must all succeed:

• Server identity: the certificate chain ends at a CA in the bundle, and the certificate’s SAN matches the hostname passed to mbedtls_ssl_set_hostname().
• Confidentiality: the handshake derives symmetric session keys, so observers cannot read the HTTP request or response.
• Integrity: authenticated encryption detects changes to protected records. A modified record is rejected instead of delivered to the application.

The CA bundle does not encrypt traffic by itself. It tells the device which certificate issuers to trust; the handshake authenticates the server and establishes the session keys.

Look for esp-x509-crt-bundle: Certificate validated, Certificate verified, and a cipher suite line in the monitor. Sample output is in the example README.

Network setup (menuconfig)

#

Under Example Connection Configuration, select Wi-Fi and set the lab SSID and password (protocols README).

The network needs outbound TCP 443. The baseline lab uses the public howsmyssl endpoint; no lab TLS server is required.

Trust anchors and the certificate bundle

#

Public HTTPS servers chain to CAs. Enable Component config → mbedTLS → Certificate Bundle (CONFIG_MBEDTLS_CERTIFICATE_BUNDLE). In code, esp_crt_bundle_attach(&conf) supplies the roots.

Optional: CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE_PATH for a private CA or lab server. Products need a plan to update the bundle when CAs change.

Hostname and certificate verification

#

Validation is two parts: the chain must trust a CA in the bundle, and the cert must match the name you meant to reach. mbedtls_ssl_set_hostname() sets that name (SNI and CN/SAN check). Use MBEDTLS_SSL_VERIFY_REQUIRED so an unverified peer cannot pass.

Wrong hostname or missing CA should fail with verify flags and log lines from mbedtls_x509_crt_verify_info. Assignment 1 exercises those cases on purpose; do not disable verification in shipping firmware.

Certificate dates need a sensible clock; use SNTP before optional expiry tests in the assignment.

One-way TLS vs mutual TLS (mTLS)

#

This example is one-way TLS (client verifies the server only). mTLS adds a client certificate and is not in the stock project; Assignment 1 Step 4 is optional. See Mbed TLS and ESP-TLS docs if you extend the lab.

CRA relevance

#

TLS supports protection in transit in a product technical file: trust store policy, success logs, and recorded failure tests (wrong hostname, untrusted cert). That is evidence for gap analysis, not CRA conformity by itself. See the TLS row in the EU CRA overview and the introduction disclaimer.

For production, also plan trust store updates, protected client keys (Lecture 2), and separate handling of Wi-Fi credentials.

After Assignment 1 (instructor demo)

#

When the TLS exercises are complete, the instructor may demonstrate TLS power consumption using a Qoitech Otii Ace Pro Power Profiler. You will observe the supply current during Wi-Fi startup and communication with a server while comparing plain HTTP, a full TLS handshake, and a resumed TLS session. No student wiring is required.

See Power consumption measurement for the measurement setup, results, and instructions for exploring the recordings.

Navigation

#

Previous: Overview of the EU Cyber Resilience Act

Next: Assignment 1: Establish and verify a TLS connection

Return to the workshop main page