Secure Your Streams with RTSPS (RTSP over TLS)

Why Use RTSPS?

Standard RTSP transmits data, including credentials and video content, in plain text. This makes it vulnerable to:

Eavesdropping: Attackers on the same network can intercept and view your video streams.
Man-in-the-Middle Attacks: Unauthorized parties can modify stream URLs or redirect connections.
Data Tampering: Video data can be altered in transit.

RTSPS (RTSP over TLS) solves these issues by encrypting the entire communication channel using the Transport Layer Security (TLS) protocol, ensuring confidentiality, integrity, and authenticity of your video streams.

Configuration Guide

To enable RTSPS, modify the mediaserver.cfg configuration file. The server supports both standard RTSP (port 554) and RTSPS (port 322) simultaneously.

Full Configuration Example

Below is a complete example of the <rtsp> section with RTSPS enabled:

mediaserver.cfg - RTSP & RTSPS Settings

<rtsp>
    <enable>1</enable>
    <!-- Optional: Bind to specific IP -->
    <serverip></serverip>
    <rtsp_port>554</rtsp_port>
    <rtsps_enable>1</rtsps_enable>
    <rtsps_port>322</rtsps_port>
    <rtsps_cert>ssl.crt</rtsps_cert>
    <rtsps_key>ssl.key</rtsps_key>
    <!-- Other RTSP settings (timeout, buffer, etc.) -->
</rtsp>

Parameter Explanation

<enable>: Set to 1 to enable the RTSP server.
<serverip>: IP address to bind the server to. Use 0.0.0.0 to listen on all interfaces.
<rtsp_port>: Port for standard (unencrypted) RTSP. Default is 554.
<rtsps_enable>: Set to 1 to enable the RTSPS (TLS) server.
<rtsps_port>: Port for encrypted RTSPS connections. Default is 322.
<rtsps_cert>: Path to the TLS certificate file (PEM format).
<rtsps_key>: Path to the private key file (PEM format) corresponding to the certificate.

Note: On Linux, ports below 1024 (like 554, 322) require root privileges to bind. Consider running the server as root or using port forwarding.

Certificate Management

A valid TLS certificate and private key are required for RTSPS. You have two options:

Option 1: Self-Signed Certificate (For Testing)

The server includes ssl.ca (certificate) and ssl.key (private key) for testing. These are self-signed and will trigger "untrusted certificate" warnings in browsers and some clients.

To generate your own self-signed certificate:

Generate Self-Signed Certificate (OpenSSL)

openssl req -x509 -newkey rsa:4096 -keyout ssl.key -out ssl.crt -days 365 -nodes -subj "/CN=localhost"

Place ssl.crt and ssl.key in your server's working directory and update mediaserver.cfg.

Option 2: CA-Signed Certificate (Production)

For production environments, use a certificate signed by a trusted Certificate Authority (CA) like Let's Encrypt, DigiCert, or Sectigo.

This eliminates security warnings and establishes trust with clients.

Obtain the certificate (.crt or .pem) and private key (.key) from your CA, place them on the server, and update the paths in mediaserver.cfg.

Warning: Self-signed certificates are not suitable for production deployments. They provide encryption but do not verify server identity, leaving systems vulnerable to impersonation attacks.

Testing Your RTSPS Stream

After starting the media server, use the following methods to test your encrypted stream:

Using FFplay (Command Line)

Test with FFplay

ffplay -rtsp_transport tcp rtsps://your-server-ip:322/live/stream1

If the connection is successful, you will see the video playback.

Using Happytime RTSP Client

Open the Happytime RTSP Client, enter the RTSPS URL (rtsps://...), and click "Play".

Security Best Practices

Use CA-Signed Certificates: Always use certificates from a trusted CA in production.
Keep Private Keys Secure: Protect the .key file with strict file permissions (e.g., chmod 600 ssl.key).
Use Strong Ciphers: The server uses modern TLS ciphers by default. Ensure your client software supports them.

Happytimesoft