# What is encryption in transit (TLS)?

> Encryption in transit protects data while it moves between systems, usually with TLS. What TLS guarantees, where it ends, and how it differs from end-to-end.

URL: https://crunu.com/learn/encryption-in-transit
Language: en
Updated: 2026-10-30

Encryption in transit is the encryption of data while it travels over a network, between a browser and a server, between two services or from a CI job to an API, so that anyone who can see or alter the traffic in between can neither read it nor change it without detection; on the web it almost always means TLS, the protocol behind HTTPS.

## What TLS guarantees

RFC 8446, the TLS 1.3 specification, says TLS lets applications "communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery" ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)). It lists three properties of the channel:

- **Authentication.** "The server side of the channel is always authenticated; the client side is optionally authenticated."
- **Confidentiality.** Data sent after the handshake "is only visible to the endpoints." TLS "does not hide the length of the data it transmits", though endpoints can pad records.
- **Integrity.** Data "cannot be modified by attackers without detection."

## Where it ends

TLS protects a hop, and the endpoints of that hop see everything. In a typical deployment, that endpoint is not your application:

- A **load balancer or CDN** often terminates TLS and opens a new connection to the backend. It sees plaintext.
- A **reverse proxy** on the same machine does the same.
- The **server application** receives plaintext once TLS is unwrapped, and decides what to store.

So "encrypted in transit and at rest" can still mean that the service, its proxies and its operators see your data between those two states. That is the difference from [end-to-end encryption](https://crunu.com/learn/end-to-end-encryption), where only the communicating ends hold keys and every hop in between, including the server, sees ciphertext.

## Common mistakes

- **Skipping certificate checks** in scripts and internal tools ("just for staging"). Without authentication, TLS protects against passive listeners only.
- **Plain HTTP behind the edge.** Traffic from the CDN to the origin over the public internet should also be encrypted.
- **Secrets in URLs.** Query strings end up in logs at every endpoint that terminates TLS.
- **Treating TLS as the whole answer** to "who can read it?"

## TLS and Crunu

All traffic to a Crunu server goes over HTTPS. On your own server, the Docker setup puts Caddy in front, which obtains and renews certificates automatically, or uses a Cloudflare Tunnel without open ports; on Cloudflare Workers, Vercel and Google Cloud Run, the platform terminates TLS. The `doctor` diagnostics check TLS, the certificate's expiry and security headers.

Crunu doesn't rely on TLS for confidentiality of values, though. Values are encrypted on your device before they are sent, so whoever terminates TLS, Caddy, a CDN or the server itself, sees ciphertext. Your password and Secret Key aren't sent at all: sign-in works by signing a one-time challenge with a key derived from them on your device. A compromised proxy or TLS connection sees only what the server sees, which is described in [what the server sees](https://crunu.com/docs/security/what-the-server-sees). The broader comparison of models is in [who can decrypt your secrets?](https://crunu.com/guides/who-can-decrypt-your-secrets).

## Sources

- [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446), checked October 30, 2026.