Topic · Spec-Referenz

TLS Reference — wo TLS in ZeroDDS lebt

Wichtig: Der RTPS-Wire-Hot-Path selbst nutzt kein TLS — DDS-Security verschlüsselt RTPS-Submessages mit AES-GCM/GMAC am Application-Layer (siehe Crypto-Plugin). TLS taucht in ZeroDDS auf drei separaten Wegen auf: in den Bridge-Daemons (CoAP/MQTT/AMQP/WebSocket über TLS), im WebSocket-Browser-Pfad (wss://) und als DTLS in DDS-XRCE. Diese Reference listet alle drei.

TLS-Lib: rustls 0.23 · TLS 1.3 + 1.2 Crates: bridge-security · websocket-bridge · xrce Status: ✓ RC3

Überblick — RTPS vs. TLS

DDS-Security 1.2 spezifiziert die Crypto am RTPS-Submessage-Layer: jedes Sample wird mit AES-GCM verschlüsselt, Headers mit AES-GMAC signiert. Das passiert vor dem UDP-Send, ohne dass der Transport selbst kryptografisch sein muss. Folge: DDS-Security funktioniert über UDP, TCP, Shared-Memory, Unix-Domain-Sockets oder TSN — kein Transport-spezifischer Crypto-Stack nötig.

TLS kommt im ZeroDDS-Stack außerhalb des RTPS-Wire-Pfads ins Spiel — bei den Bridge-Daemons, die Nicht-RTPS-Protokolle terminieren (CoAP, MQTT, AMQP, WebSocket) und deren Standard-Sicherheit TLS ist. Plus bei DDS-XRCE, wo die Spec selbst DTLS als Wire-Security vorsieht (§7.4).

bridge-security TLS-Layer

ServerConfig + Client-Auth rustls 0.23 · TLS 1.2/1.3

Crate: crates/bridge-security/src/tls.rs

Zwei Builder-Funktionen:

  • load_server_config(cert_path, key_path) -> Arc<ServerConfig> — Server-only TLS (Bridge-Daemon präsentiert sich, Client braucht kein Cert).
  • load_server_config_with_client_auth(cert_path, key_path, ca_path) -> Arc<ServerConfig> — mTLS, Client muss ebenfalls Cert vorlegen, das gegen ca_path chainet.

Wer nutzt das:

SIGHUP-Reload: Bridge-Daemons re-lesen die TLS-Files beim SIGHUP-Signal (für Cert-Rotation ohne Process-Restart). Implementation siehe pro Daemon.

ClientConfig (für Bridge-Initiator-Mode) rustls 0.23

Manche Bridges (z.B. MQTT-Outbound zu einem externen Broker) sind TLS-Client. rustls::ClientConfig::builder().with_root_certificates(...).with_no_client_auth() für Standard-CA-Validation; .with_client_auth_cert(...) für mTLS.

Setup-Pattern analog zu Server-Config, aber Client-seitig. Implementation in crates/bridge-security/src/ctx.rs.

DTLS in DDS-XRCE

DDS-XRCE DTLS-Profile OMG DDS-XRCE 1.0 §7.4

Crate: crates/xrce/src/transport_dtls.rs

XRCE (eXtremely Resource-Constrained Environments) ist ein DDS-Profil für MCUs und IoT-Devices, die nicht den vollen DDS-Stack tragen. Die Spec definiert DTLS (Datagram-TLS, RFC 9147) als Wire-Security-Option — passt zu UDP-basierten Constrained-Devices ohne TCP-Handshake-Overhead.

Wann nutzen: XRCE-Client auf einem Cortex-M4/M7 (z.B. ESP32-S3, STM32F7), der via UDP gegen einen XRCE-Agent kommuniziert. DTLS verschlüsselt den Wire-Pfad, ohne dass der Constrained-Device DDS-Security-Crypto selbst implementieren muss.

Spec-Coverage: DDS-XRCE 1.0 Spec-Coverage →

WebSocket Secure (wss://)

WebSocket-Bridge mit TLS-Terminierung RFC 6455 + RFC 8446

Crate: crates/websocket-bridge

Pattern: Browser-Clients (typescript-wasm) können keine UDP-Sockets nutzen — sie sprechen WebSocket gegen einen ZeroDDS-WebSocket-Bridge-Daemon, der UDP-RTPS in beide Richtungen umsetzt. Für Production: TLS terminiert in der Bridge (wss://).

# Bridge mit TLS starten
zerodds-websocket-bridge \
    --listen 0.0.0.0:9001 \
    --domain 0 \
    --tls-cert /etc/zerodds/server.crt \
    --tls-key /etc/zerodds/server.key

Browser-Client: const ws = new WebSocket('wss://bridge.example.com:9001').

Vertrauensmodell: Browser vertraut der Bridge (Standard-CA-Chain). Was zwischen Bridge und DDS-Cluster passiert, ist Server-Side-Setup — typisch DDS-Security mit eigenem PKI-Trust-Anker. Das heisst: TLS terminiert in der Bridge; DDS-Security-Crypto setzt von dort weiter zum Peer ein.

Setup-Rezept: Security Cookbook §1 (PKI-Trust-Anker) für die DDS-Side, plus dieser TLS-Snippet für die Browser-Side.

Cipher-Suites & Versions

ZeroDDS verlässt sich auf rustls für TLS — das heisst: TLS 1.3 voll, TLS 1.2 mit AEAD-only Suiten. Kein TLS 1.0/1.1 (rustls supportet die gar nicht erst).

TLS-VersionStatusCipher-Suiten (rustls-Default)
TLS 1.3✓ bevorzugtTLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256
TLS 1.2✓ FallbackECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-CHACHA20-POLY1305 + RSA-Varianten
TLS 1.1 / 1.0✗ nicht supportedrustls hat das nicht implementiert
SSLv3✗ nicht supported—

Compliance-Nutzen: TLS-1.2-AEAD-only + TLS 1.3 entspricht NIST SP 800-52 Rev. 2, PCI-DSS 3.2.1, FIPS 140-3 Mode (rustls hat eine separate FIPS-validated Variante via aws-lc-rs-Backend, kein Default).

Cert-Bundle-Format

Alle TLS-Funktionen in ZeroDDS akzeptieren PEM-Format:

# Cert-File (cert + intermediate-chain, root NICHT enthalten):
cat server.crt intermediate.crt > cert-bundle.pem

# Key-File (PKCS#8 oder PKCS#1, encrypted oder cleartext):
# encrypted: openssl pkcs8 -in key.pem -topk8 -out key.pk8 -nocrypt

Trust-Anker für Client-Auth-mTLS: separate PEM-Datei mit allen CA-Certs, die als Client-Cert-Issuer akzeptiert werden sollen. Pro Bridge-Daemon konfigurierbar.

Cross-Reference zur DDS-Side: die DDS-Security-PKI nutzt die gleichen PEM-Cert-Files (sieht PKI Governance §1). Das macht es einfach, eine einzige Cert-Hierarchie für RTPS-DDS-Security + Bridge-TLS zu nutzen.

Topic · Spec reference

TLS Reference — where TLS lives in ZeroDDS

Important: the RTPS wire hot path itself uses no TLS — DDS-Security encrypts RTPS submessages with AES-GCM/GMAC at the application layer (see the crypto plugin). TLS shows up in ZeroDDS on three separate paths: in the bridge daemons (CoAP/MQTT/AMQP/WebSocket over TLS), on the WebSocket browser path (wss://) and as DTLS in DDS-XRCE. This reference lists all three.

TLS lib: rustls 0.23 · TLS 1.3 + 1.2 Crates: bridge-security · websocket-bridge · xrce Status: ✓ RC3

Overview — RTPS vs. TLS

DDS-Security 1.2 specifies the crypto at the RTPS submessage layer: each sample is encrypted with AES-GCM, headers signed with AES-GMAC. This happens before the UDP send, without the transport itself having to be cryptographic. Consequence: DDS-Security works over UDP, TCP, shared memory, Unix domain sockets or TSN — no transport-specific crypto stack needed.

TLS comes into play in the ZeroDDS stack outside the RTPS wire path — at the bridge daemons that terminate non-RTPS protocols (CoAP, MQTT, AMQP, WebSocket) whose standard security is TLS. Plus at DDS-XRCE, where the spec itself provides DTLS as wire security (§7.4).

bridge-security TLS layer

ServerConfig + client auth rustls 0.23 · TLS 1.2/1.3

Crate: crates/bridge-security/src/tls.rs

Two builder functions:

  • load_server_config(cert_path, key_path) -> Arc<ServerConfig> — server-only TLS (the bridge daemon presents itself, the client needs no cert).
  • load_server_config_with_client_auth(cert_path, key_path, ca_path) -> Arc<ServerConfig> — mTLS, the client must also present a cert that chains against ca_path.

Who uses it:

SIGHUP reload: bridge daemons re-read the TLS files on the SIGHUP signal (for cert rotation without a process restart). See each daemon for the implementation.

ClientConfig (for bridge initiator mode) rustls 0.23

Some bridges (e.g. MQTT outbound to an external broker) are the TLS client. rustls::ClientConfig::builder().with_root_certificates(...).with_no_client_auth() for standard CA validation; .with_client_auth_cert(...) for mTLS.

Setup pattern analogous to the server config but client-side. Implementation in crates/bridge-security/src/ctx.rs.

DTLS in DDS-XRCE

DDS-XRCE DTLS profile OMG DDS-XRCE 1.0 §7.4

Crate: crates/xrce/src/transport_dtls.rs

XRCE (eXtremely Resource-Constrained Environments) is a DDS profile for MCUs and IoT devices that can't carry the full DDS stack. The spec defines DTLS (datagram TLS, RFC 9147) as a wire-security option — a fit for UDP-based constrained devices without TCP handshake overhead.

When to use: an XRCE client on a Cortex-M4/M7 (e.g. ESP32-S3, STM32F7) talking via UDP to an XRCE agent. DTLS encrypts the wire path without the constrained device having to implement DDS-Security crypto itself.

Spec coverage: DDS-XRCE 1.0 spec coverage →

WebSocket Secure (wss://)

WebSocket bridge with TLS termination RFC 6455 + RFC 8446

Crate: crates/websocket-bridge

Pattern: browser clients (typescript-wasm) can't use UDP sockets — they speak WebSocket to a ZeroDDS WebSocket bridge daemon that translates UDP RTPS in both directions. For production: TLS is terminated in the bridge (wss://).

# start the bridge with TLS
zerodds-websocket-bridge \
    --listen 0.0.0.0:9001 \
    --domain 0 \
    --tls-cert /etc/zerodds/server.crt \
    --tls-key /etc/zerodds/server.key

Browser client: const ws = new WebSocket('wss://bridge.example.com:9001').

Trust model: the browser trusts the bridge (standard CA chain). What happens between the bridge and the DDS cluster is server-side setup — typically DDS-Security with its own PKI trust anchor. That is: TLS terminates in the bridge; DDS-Security crypto takes over from there to the peer.

Setup recipe: Security Cookbook §1 (PKI trust anchor) for the DDS side, plus this TLS snippet for the browser side.

Cipher suites & versions

ZeroDDS relies on rustls for TLS — meaning: TLS 1.3 in full, TLS 1.2 with AEAD-only suites. No TLS 1.0/1.1 (rustls doesn't implement them at all).

TLS versionStatusCipher suites (rustls default)
TLS 1.3✓ preferredTLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256
TLS 1.2✓ fallbackECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-CHACHA20-POLY1305 + RSA variants
TLS 1.1 / 1.0✗ not supportedrustls hasn't implemented them
SSLv3✗ not supported—

Compliance benefit: TLS-1.2-AEAD-only + TLS 1.3 matches NIST SP 800-52 Rev. 2, PCI-DSS 3.2.1, FIPS 140-3 mode (rustls has a separate FIPS-validated variant via the aws-lc-rs backend, not the default).

Cert bundle format

All TLS functions in ZeroDDS accept PEM format:

# Cert file (cert + intermediate chain, root NOT included):
cat server.crt intermediate.crt > cert-bundle.pem

# Key file (PKCS#8 or PKCS#1, encrypted or cleartext):
# encrypted: openssl pkcs8 -in key.pem -topk8 -out key.pk8 -nocrypt

Trust anchor for client-auth mTLS: a separate PEM file with all CA certs to be accepted as client-cert issuers. Configurable per bridge daemon.

Cross-reference to the DDS side: the DDS-Security PKI uses the same PEM cert files (see PKI Governance §1). That makes it easy to use a single cert hierarchy for RTPS DDS-Security + bridge TLS.