FIPS 140-3 Profiles

rstream provides separate FIPS 140-3 build variants for the Go client and the Enterprise Edition standalone engine. These artifacts embed the NIST CMVP-validated Go Cryptographic Module, certificate 5247, which has Overall Security Level 1. They select one exact module revision at build time and reject startup when the required module, approved mode, or rstream policy profile is not active.

The profile is part of the delivered binary rather than a runtime option for a standard rstream build. Setting an environment variable on a standard binary does not convert it into a FIPS artifact.

Compliance scope

The precise artifact description is FIPS 140-3 Inside — Go Cryptographic Module, Certificate #5247 (Overall Security Level 1). The certificate and security level apply to the embedded Go Cryptographic Module. The complete rstream product has not undergone a separate CMVP module validation.

FIPS 140-3 levels describe the assurance level of a validated cryptographic module; they are not graduated self-attestation levels inherited by an application. NIST permits products that incorporate a validated module to identify that module with the FIPS 140-3 Inside phrase. The operating system, key custody, certificates, external services, deployment controls, and customer configuration remain part of the assessment for the deployed system.

Supported profile

The current profile covers the Go client and one Enterprise Edition engine using in-memory standalone routing. It is designed for private and on-premises deployments with the following network paths:

Community Edition, distributed Redis and inter-engine routing, the Global edge topology, proxied QUIC, generic datagram tunnels, DTLS, ECH, TURN, WebTTY over plain streams or WebSocket, and non-WebTransport Extended CONNECT are outside this profile. Static certificates and standalone file-backed certificate storage are supported; S3 certificate storage is not.

Workspace-managed WebTTY can use PostgreSQL without enabling distributed routing. PostgreSQL, identity providers, certificate authorities, metrics systems, and other external services remain outside the Go Cryptographic Module boundary and require their own deployment assessment.

Raw TCP forwarding does not add encryption to the downstream public connection. The application protocol remains responsible for approved encryption and authentication. With TLS passthrough, cryptography and certificate verification are also performed by the upstream application rather than the engine module.

Compatibility with standard deployments

A FIPS client can connect to a standard rstream cloud Engine for the features allowed by the client profile, including TLS and QUIC transport, supported forwarding, ordinary HTTP/3, SSE events, and WebTTY over WebTransport.

In this mixed deployment, the FIPS 140-3 Inside statement applies only to the client artifact and its embedded module. A client-and-server FIPS deployment uses both a FIPS client and the Enterprise Edition standalone FIPS engine within their documented operating profiles.

Module and build identity

The profile uses Go 1.27 and freezes GOFIPS140 to v1.0.0-c2097c7c, the module revision associated with version v1.0.0 on certificate 5247. The Go FIPS 140-3 documentation defines module selection, approved mode, self-tests, and limitations.

The Go client pins github.com/quic-go/quic-go at v0.60.0 and github.com/quic-go/webtransport-go at v0.11.1. The Enterprise engine pins them at v0.62.0 and v0.13.0. Each artifact verifies its own reviewed versions at startup. A change to Go, the Go Cryptographic Module, quic-go, or webtransport-go requires a new cryptographic-path review and fresh release evidence.

Linux x86_64 and arm64 are the supported binary targets. Version output and Go build metadata identify the Go release, selected module, reviewed dependencies, build tags, rstream version, and source commit.

Go FIPS mode restricts TLS to algorithms permitted by the validated module. The rstream client additionally rejects certificate-verification bypasses, ECH, proxied QUIC, unreviewed custom transports, and incompatible explicit TLS settings. QUIC uses TLS 1.3 and the reviewed AES-GCM path.

WebTTY

WebTransport remains required for terminal traffic. Application E2E is optional unless server or workspace policy requires it. Without application E2E, every endpoint that terminates TLS or WebTransport must use approved cryptography within its documented FIPS deployment boundary; a protocol name or tunnel label is not proof of that deployment.

When application E2E is enabled, the FIPS-compatible WebTTY profile uses P-256 ECDH and HKDF-SHA256 for session-key envelopes and AES-256-GCM with internally generated random nonces for terminal payloads. Authenticated proofs bind the negotiated suites and endpoint identities to prevent an implicit downgrade.

Standard Go, Engine, and @rstreamlabs/webtty clients accept both the existing X25519 profile and the P-256 profile. Go client and Engine FIPS builds accept only the P-256 profile and require HTTP/3 and WebTransport for live terminal traffic. Existing CLI workspace devices can be replaced with rstream workspace device rotate --crypto-profile=fips-compatible.

The dashboard selects the transport advertised by the server. A server running the restricted FIPS profile advertises WebTransport, whether application E2E is enabled or disabled. Its JavaScript implementation uses browser WebCrypto and is protocol-compatible with the FIPS Go artifacts, but it is not part of the validated Go Cryptographic Module.

Build and delivery evidence

The public Go repository exposes the FIPS test and build targets:

make fips-test
make fips-build

Enterprise standalone engine artifacts and their reference configuration are supplied for contracted private deployments. Unsupported listeners or modules cause configuration validation to fail rather than being ignored.

A release package includes or references the client and engine artifacts and digests, source and build identities, certificate 5247 and its module Security Policy, the supported operating environment and configuration, and standard, strict-profile, and target-environment test evidence. Go's fips140=only mode is used for testing; production artifacts use the normal approved mode selected by the frozen build.

Compatibility matrix

The FIPS column describes the implemented Go profile. A supported client-and-server FIPS deployment requires both the restricted client and the Enterprise standalone Engine inside their documented operating boundaries.

WebTTY can use transport encryption alone or add authenticated application E2E. Without E2E, every endpoint that terminates TLS/WebTransport must use approved cryptography inside its documented FIPS deployment boundary. A protocol name or tunnel label is not proof of that deployment. Server and workspace policies can still require E2E; omitting client E2E options cannot override them.

The C++ SDK has no restricted FIPS build. The JavaScript WebTTY client can interoperate with the P-256 protocol suite over WebTransport, but browser WebCrypto remains outside the Go module boundary. Do not treat protocol interoperability as a FIPS artifact claim.

File sharing and encryption

rstream files and the WebTTY filesystem are outside the current FIPS profile, including the default WebDAV backend. Selecting WebDAV instead of WebRTC does not enable the command in a FIPS CLI. The command fails explicitly; there is no fallback to another backend or to an ordinary binary.

The terminal transport and filesystem backend are separate choices. The current WebTTY server mounts file and WebRTC signaling routes only with its WebSocket terminal transport. It cannot yet combine a WebTransport terminal with either filesystem backend. This implementation limit is separate from WebRTC’s read-only policy and its FIPS qualification. WebDAV itself is not cryptographically prohibited; the complete file-sharing feature remains outside the qualified profile.

In standard builds, WebDAV uses the normal encrypted tunnel path. WebRTC encrypts the peer connection with DTLS and can use TURN. Neither backend adds recipient-key file encryption, and neither can be attached to a WebTTY server using terminal E2E. These properties are independent from the terminal E2E key model.

Connection and deployment boundaries

A FIPS Go client can use a standard or hosted Engine for the features allowed by its client profile. This does not make the standard Engine a FIPS artifact. Community Edition and distributed Redis/inter-engine deployments have no supported server FIPS profile.

Application E2E protects terminal content from an Engine that terminates transport encryption. Transport-only sessions allow that Engine to process the content; managed recording remains encrypted at rest.

The published-endpoint requirement for registered FIPS WebTTY sessions preserves the Engine's policy, live state and encrypted audit recording. With a known HTTPS endpoint, explicit --no-discovery --transport=webtransport, a local bearer-token file and the required CA trust, a client can connect without control-plane discovery. Server admission and workspace policies still apply. In the standard profile, an explicit engine context and locally prepared trust material can support private dialing without control-plane discovery. Workspace setup and policies that require remote resolution still need their documented services.

See the Go SDK and CLI profile and Enterprise Engine profile for the exact module identity, supported environments, build procedure and exclusions.