Encrypted Video Streaming: Security Layers & Access | Callaba
More live video workflow notes and product updates.
Secure video architecture
An encrypted stream is useful only when identity, playback and stored media are protected too
“We use HTTPS” does not describe a secure video workflow. A real plan names the media hop being encrypted, the person or system allowed to connect, the viewer entitled to play, the keys or secrets being managed, and what happens to recordings. Protect each boundary according to the risk instead of adding one lock icon to the player.
The orbiting marker represents a protected media session crossing several controls; it is illustrative and becomes static when reduced motion is enabled.
Start with the threat, not the protocol
The layers are related, but they are not interchangeable
Transport encryption
Examples include SRT with a passphrase, RTMPS, HTTPS and WebRTC’s encrypted media transport. This protects a connection while media moves between participating endpoints.
Viewer access
Authentication, entitlement, signed URLs, expiry and session policy decide whether a person may reach playback. Encryption alone does not know whether a copied link belongs to a paying viewer.
Content and storage protection
HLS AES-128, SAMPLE-AES or DRM can protect media objects. Storage encryption and restricted service roles protect recordings and packaged assets at rest.
Secure SRT contribution in Callaba
SRT supports passphrase-based AES encryption. The open-source SRT project documents 128-, 192- and 256-bit key lengths and requires both endpoints to agree on encryption settings. A correct passphrase protects the payload, while the connection mode, port, peer identity and firewall still determine who can reach the service.
- Create the Callaba SRT Server on a deliberately exposed UDP port.
- Set a strong passphrase and transmit it separately from the complete connection URL.
- Create explicit publisher and receiver access when the workflow needs controlled identities; use open/guest access only when it is an intentional operating choice.
- Connect the real publisher and verify peer address, region, live bitrate and Network RTT.
- Test the wrong passphrase and an unauthorized stream identity to prove rejection, not only successful access.
The official SRT project and its socket-options reference describe encryption negotiation and failure states. Keep the deployed peer versions in the runbook because supported crypto modes can differ.
Secure RTMP ingest without pretending RTMPS solves playback
RTMPS wraps the publishing connection in TLS. It is appropriate when the encoder and ingest endpoint support it and certificate validation is maintained. It secures that ingest hop; audience playback normally continues through a separate HTTPS player or packaged delivery path.
On the Callaba RTMP Server, control publisher and receiver access, inspect connection addresses, and use guest RTMP only when publishers or receivers are intentionally allowed to create their own stream keys. Revoke or rotate a leaked key instead of treating an obscure URL as a secret forever.
Choose playback protection by the actual rights requirement
- Low-risk public playback: HTTPS delivery and normal application controls may be sufficient.
- Private company event: authenticated access, short-lived links, audience policy and protected recordings are often more important than full DRM.
- Pay-per-view: tie playback to the purchase or entitlement and test expiry, free passes, concurrent use and replay behavior.
- Studio or premium rights: integrate the required packaging and license-backed DRM system, and validate FairPlay, Widevine or PlayReady only on the devices actually supported.
Callaba provides controlled web-player and pay-per-view workflows. When a contract mandates a specific DRM and license-server architecture, treat that as a downstream integration rather than implying that transport encryption alone satisfies it. Apple’s HLS resources include the current encryption formats and authoring references.
A security acceptance test operators can repeat
- Connect one authorized publisher and receiver; record their expected addresses and identities.
- Try a wrong passphrase, stream key or expired viewer session and confirm access is denied.
- Open playback in a clean browser without an existing login or cached entitlement.
- Inspect logs for enough evidence to distinguish bad credentials, unreachable transport and missing media.
- Record a short asset, verify its storage policy, then confirm an unauthorized role cannot fetch it.
- Rotate one non-production secret and document the order that avoids an unnecessary outage.
Frequently asked questions
Is an SRT passphrase the same as viewer authentication?
No. It protects and authenticates the transport peers according to the SRT configuration. It does not create a viewer account or entitlement for browser playback.
Should a key endpoint be cached?
Follow the packager, player and license design. Never let a generic CDN policy accidentally extend the lifetime or audience of a secret-bearing response.
Does a private IP make a stream secure?
No. Network isolation reduces exposure, but the identities, host access, stored media and operator permissions still need explicit controls.
Do thumbnails, captions and manifests matter?
Yes. They may expose private content, titles or timing even when the main video segments are protected. Include every related object in the data inventory.
Secure one complete path, then repeat it
Receive a real encrypted feed, prove access boundaries, observe it in Multiview, record it, and test playback as an authorized and unauthorized user.
