Encryption in Transit

This page is written for the security and compliance teams of our enterprise customers. It describes how data is encrypted while it moves between your users and our service — including both web and API traffic, and the real-time voice and video that powers our conferencing and calling features.

This page covers data in transit only. Encryption of stored data, and end-to-end encryption for video conferences, are described on separate pages.

At a glance

• All traffic between your users and our service is encrypted. There is no unencrypted entry point to the platform.
• Web and API traffic is protected by TLS, including the persistent WebSocket connection used to deliver real-time signaling.
• Voice and video media are protected by DTLS-SRTP, the encryption standard mandated by WebRTC and supported by every modern browser.
• Forward secrecy is enforced. Every session negotiates fresh keys; even if a long-term private key were ever compromised, past sessions could not be retroactively decrypted.
• Certificates are managed by AWS. TLS certificates are issued and rotated by AWS Certificate Manager, and the private keys are held inside AWS’s FIPS-validated infrastructure. We never see or handle the raw key material.
• What it does not cover: the public telephone network leg of any voice call that bridges to PSTN is outside our control, and the contents of our servers (where data is in use or at rest) are protected by separate controls described on companion pages.

What “encryption in transit” means

“In transit” refers to data that is travelling between two points: between your browser and our backend, between our servers and another user’s browser, between components of our infrastructure, or to or from a third-party gateway. Encryption in transit ensures that an attacker who can observe the network — at a local Wi-Fi network, on the public internet, or inside a network operator — cannot read the traffic, and cannot modify it without the receiving end detecting the tampering.

It is one layer in a defence-in-depth approach. It complements, but does not replace, encryption at rest, identity and access management, and application-layer protections.

How encryption applies across our platform

The table below summarises which protocol is used on each path through our service. Every path on this list is encrypted; the protocol differs depending on whether the traffic is web/API or real-time media.

The PSTN row is the only one with a caveat. When a user makes or receives a phone call that involves the public telephone network, the leg between our voice infrastructure and the PSTN gateway is encrypted, but the PSTN leg itself is outside the scope of any modern internet encryption. Customers who need end-to-end protection across that path should use the platform’s WebRTC-only calling features rather than the PSTN bridge.

Web and API traffic (TLS)

All traffic between your users and our web application is encrypted using TLS, the standard internet encryption protocol. This applies to:

• Every page loaded from the application.
• Every API call made by our front-end clients or by your own integrations.
• The persistent WebSocket connection that delivers real-time presence, signaling, and in-app notifications.

Current TLS configuration

• Protocols accepted: TLS 1.1 and TLS 1.2. TLS 1.0 and the older SSL protocols are not accepted.
• Forward secrecy: every session uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange. Past sessions cannot be decrypted retroactively even if a long-term private key were later compromised.
• Cipher suites: AES with ECDHE key exchange, including AES-GCM and AES-CBC variants.
• Certificates: RSA 2048 with SHA-256 signatures, issued and renewed automatically by AWS Certificate Manager. AWS holds the private keys inside FIPS-validated infrastructure; we never see or hold the raw key material.
• TLS termination: at our AWS Application Load Balancer. This is the point where the cipher and protocol policy is enforced and where independent scans see our public posture.

Customers can verify our external TLS posture at any time using public tools such as Qualys SSL Labs. We re-scan after any load-balancer configuration change.

On the roadmap

During the current year we are completing a planned upgrade to our public TLS configuration. The changes will be:

• Add support for TLS 1.3.
• Retire TLS 1.1, leaving TLS 1.2 and TLS 1.3 as the only accepted protocols.
• Tighten the cipher-suite list, removing legacy CBC-mode suites in favour of AEAD (AES-GCM) and a ChaCha20-Poly1305 option for mobile clients.
• Enable HTTP Strict Transport Security (HSTS) so that browsers refuse to ever connect over plaintext HTTP.
• Enable OCSP stapling so that certificate revocation checks complete more quickly and privately for users.

These changes are tracked together and will be applied to all of our public endpoints. After they are in place, our external posture will be in line with the strictest enterprise security baselines.

Real-time voice and video media (WebRTC)

Voice and video traffic in our platform uses WebRTC, the browser-native real-time communication standard. WebRTC requires encryption at every step; there is no option to send unencrypted media.

Concretely:

• Key exchange (DTLS). Before any media is sent, the browser and our media server perform a DTLS (Datagram TLS) handshake to negotiate fresh encryption keys for the call.
• Media encryption (SRTP). Every voice and video packet is encrypted using SRTP (Secure Real-time Transport Protocol). The cipher is AES, and the keys come from the DTLS handshake.
• Signaling binding. The DTLS handshake is cryptographically bound to the signaling channel that set up the call, which itself is protected by TLS. An attacker on the media path cannot substitute their own encryption keys without also compromising the signaling channel.
• Fresh keys per call. Every call negotiates its own keys; the keys are discarded when the call ends. There are no long-lived shared secrets.

This protection applies whether the call is a 1:1 voice call, a multi-party video conference, or a screen-share session. For customers who require encryption that even our conferencing infrastructure cannot decrypt, end-to-end encryption is available as an opt-in setting for video conferences — see our companion page on E2EE for details.

What encryption in transit protects

Encryption in transit is specifically designed to address risks that arise from observation of or interference with the network between your users and our service. Concretely, it means the following classes of attack cannot expose your data:

• Eavesdropping. An observer on a local Wi-Fi network, a public hotspot, or anywhere on the path to our service cannot read your traffic.
• Network-operator interception. An ISP or transit provider cannot read or modify the contents of your sessions.
• Tampering. A modified packet fails its integrity check and is dropped. Modifying traffic in flight to inject malicious content is not possible without breaking the encryption.
• Man-in-the-middle impersonation. A server impersonating our service cannot present a valid TLS certificate without the corresponding private key, which is held by AWS inside FIPS-validated infrastructure.

What encryption in transit does not protect

We want to be precise about this. Overstating what encryption in transit protects against would be worse than not offering it.

The public telephone network leg of phone calls

When a call bridges to the public phone network (PSTN), the leg within our infrastructure is encrypted, but the PSTN leg is outside the reach of any modern internet encryption. The encryption applied on the PSTN side, if any, depends on the carrier and the destination network.

Customers who require encryption end to end on a voice call should use the platform’s WebRTC-only calling features, where both endpoints speak WebRTC directly to our service.

Compromised endpoints

Encryption in transit protects data on the wire. It does not protect against a compromised endpoint. If a user’s device or browser is infected with malware, or if a screen recorder is running on it, the contents of the session can be captured at the endpoint regardless of how it is encrypted on the wire.

Traffic metadata

Even though the contents of your traffic are encrypted, observers on the network can still see that a connection is being made, which endpoints are involved, when, and roughly how much data is being sent. This metadata is unavoidable for any service that is reachable over the public internet, and is mitigated rather than eliminated by encryption.

Underlying technology

For security teams that want the specifics:

• TLS protocols: TLS 1.1 and TLS 1.2 accepted today; TLS 1.3 to be added and TLS 1.1 retired during the current year.
• Key exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) on supported elliptic curves including secp256r1, secp384r1, and secp521r1. All sessions are forward-secret.
• Ciphers: AES (in GCM and CBC modes). The cipher list will be tightened to AEAD-only suites as part of the planned roadmap.
• DTLS-SRTP: DTLS 1.2 for the key exchange. SRTP for the media itself, using AES.
• Certificates: RSA 2048 with SHA-256 signatures, managed by AWS Certificate Manager. Renewal is automatic; the private keys are held by AWS inside FIPS-validated infrastructure and are never exposed in plaintext outside the HSM boundary.
• Termination: at our AWS Application Load Balancer for web and API traffic, and at the respective media servers for WebRTC media.

Standards alignment and audit

The cryptographic primitives we rely on — TLS, DTLS-SRTP, AES, and ECDHE — are NIST-approved and form the basis of the encryption used across nearly every modern internet service. The cryptographic implementations are FIPS 140-validated through AWS Certificate Manager and the underlying compute and load-balancer services.

Contact

For deeper technical questions, security questionnaires, or to request a copy of the most recent independent scan of our public TLS posture, contact your account team or our security team directly.