Upstream connections are plaintext ws:// only: Server::ws_url() (src/models.rs) hardcodes the ws:// scheme and tokio-tungstenite is pulled without a TLS feature. (The client-facing listener is likewise plaintext + unauthenticated — documented in the README/SECURITY as a deployment constraint: run on a trusted network or behind a TLS-terminating proxy.)
For deployments where upstream SHiP nodes are reached over an untrusted network, native wss:// support would let the router connect securely and verify upstream certificates directly, rather than requiring a sidecar.
Suggested
- Parse the scheme from
servers[].endpoint (accept both ws:// and wss://) instead of hardcoding ws://.
- Enable a
tokio-tungstenite TLS feature (e.g. rustls-tls-webpki-roots) so connect_async_with_config handles wss://.
- Keep
ws:// the default; document wss:// usage and cert expectations.
Severity: medium / enhancement. Documented as a known limitation for the initial release; from the pre-launch readiness audit (no-tls-plaintext-unauth).
Upstream connections are plaintext
ws://only:Server::ws_url()(src/models.rs) hardcodes thews://scheme andtokio-tungsteniteis pulled without a TLS feature. (The client-facing listener is likewise plaintext + unauthenticated — documented in the README/SECURITY as a deployment constraint: run on a trusted network or behind a TLS-terminating proxy.)For deployments where upstream SHiP nodes are reached over an untrusted network, native
wss://support would let the router connect securely and verify upstream certificates directly, rather than requiring a sidecar.Suggested
servers[].endpoint(accept bothws://andwss://) instead of hardcodingws://.tokio-tungsteniteTLS feature (e.g.rustls-tls-webpki-roots) soconnect_async_with_confighandleswss://.ws://the default; documentwss://usage and cert expectations.Severity: medium / enhancement. Documented as a known limitation for the initial release; from the pre-launch readiness audit (
no-tls-plaintext-unauth).