What is encryption in transit?

Encryption in transit is the protection of data while it moves over a network between a client and a server or between two servers. It uses protocols such as TLS for web and API traffic, WSS for WebSockets and DTLS-SRTP for real-time media, so that anyone intercepting the traffic sees only ciphertext and any tampering is detected. It is distinct from encryption at rest, which protects stored data.

What is the difference between encryption in transit and end-to-end encryption?

Encryption in transit protects data on each network hop, but the server at the end of the hop decrypts it and can read, store and process the content. End-to-end encryption keeps the keys on the users' devices, so the server relays ciphertext it cannot read. E2EE gives stronger privacy against the operator but removes server-side archiving, search, moderation and audit, which regulated deployments usually require.

Is TLS 1.2 still secure?

TLS 1.2 is still considered acceptable when configured with modern cipher suites (AEAD ciphers such as AES-GCM or ChaCha20-Poly1305 with ECDHE key exchange) and with older options disabled. TLS 1.3 is preferred because it removes the weak options entirely, requires forward secrecy and completes the handshake faster. TLS 1.0 and 1.1 are deprecated by RFC 8996 and should be turned off.

Does HIPAA require encryption in transit?

The HIPAA Security Rule lists transmission security as a standard (45 CFR 164.312(e)) with encryption as an addressable implementation specification, meaning a covered entity must implement it or document why an equivalent alternative is reasonable. In practice, sending ePHI over an unencrypted connection is very hard to justify, and HHS guidance treats properly encrypted data as secured for breach purposes. TLS on every connection is the expected baseline.

How are voice and video calls encrypted in transit?

WebRTC requires it. The two peers, or a peer and a media server, run a DTLS handshake to agree keys, then the audio and video packets are carried with SRTP, which encrypts and authenticates each RTP packet. Signaling travels over the app's existing secure channel, such as WSS or XMPP over TLS. Ethora's calls follow this standard design, with an SFU forwarding the encrypted streams.

Glossary

Encryption in Transit

Protecting data while it moves. Every connection a chat app opens, from the WebSocket to the media stream, should be wrapped in a protocol that an eavesdropper on the path cannot read or tamper with.

General definition

Encryption in Transit means that data is encrypted and authenticated while it moves between two endpoints, so the networks in between (Wi-Fi, ISPs, cloud load balancers, hostile middleboxes) see only ciphertext. The standard mechanism is Transport Layer Security. TLS 1.2 (RFC 5246) is still widely deployed; TLS 1.3 (RFC 8446, 2018) removed the weak cipher suites, made forward secrecy mandatory and cut the handshake to one round trip. Older versions and SSL should be disabled. The server proves its identity with an X.509 certificate issued by a certificate authority, and HTTP Strict Transport Security (HSTS, RFC 6797) tells browsers never to fall back to plain HTTP.

A messaging system has several transports, and each needs its own protection:

HTTPS for the REST API, file uploads and downloads
WSS (WebSocket over TLS, RFC 6455) for the real-time WebSocket connection a browser or app keeps open
XMPP client and server-to-server streams, secured either with STARTTLS negotiated inside the stream (RFC 6120) or with direct TLS on a dedicated port (XEP-0368)
DTLS-SRTP for WebRTC calls: DTLS negotiates the keys and SRTP encrypts the audio and video packets, as WebRTC security (RFC 8827) requires
Internal links between the API, the chat server, the database and object storage inside the data centre, which are easy to forget

Encryption in transit is one of three layers. Encryption at rest protects stored data on disks, databases and backups against theft of the storage. End-to-end encryption goes further: only the sender’s and recipient’s devices hold the keys, so the server itself cannot read the content. That last property is a design choice with consequences. It prevents the operator from archiving, searching, moderating or producing messages for an audit, which is why regulated deployments often choose strong transport and storage encryption plus server-side controls instead. HIPAA’s transmission security standard (45 CFR 164.312(e)) requires protecting ePHI in transit; it does not mandate end-to-end encryption.

In the Ethora ecosystem

Ethora encrypts every transport: HTTPS for the API and file storage, WSS for the WebSocket connection, TLS on the XMPP streams into ejabberd, and DTLS-SRTP for voice and video calls through the SFU. Stored data is encrypted at rest on the server, and the React Native SDK adds on-device encryption of its local cache with AES-256 and keeps credentials in the platform Keychain or Keystore. On a dedicated or self-hosted deployment the certificates, cipher configuration and internal network policy are yours to set and audit.

By default Ethora runs a compliance-archive model rather than client-side end-to-end encryption: the server can retain messages under a configurable retention policy, keep an audit trail with immutable log export, run Trust and Safety moderation and erase a user’s data on request. Those capabilities are what healthcare, finance and insurance customers need, and they are incompatible with a server that cannot read content. Since release 2610, end-to-end encrypted rooms are available as an opt-in per app for the conversations where that trade-off is right; an encrypted room gives up server-side moderation, search, export and recovery. Secure messaging in the default model means encrypted transport and storage, access control and auditability, and Ethora says which model a room uses rather than implying E2EE everywhere.

Encryption in Transit

General definition

In the Ethora ecosystem

Chat and AI built for regulated industries

Talk to our team

Pick a time that works for you