Protect authorization credentials with TLS

[tnull]

Summary

The server binds a plain TcpListener and serves HTTP/1 without TLS. The
shipped Compose configuration publishes port 8080 directly and includes no TLS
terminator. Consequently, JWTs and signature authorization headers traverse
the network in cleartext when operators expose the supplied configuration as
is.

Observed on 88a5703496386465556d920dccf49512296c53d0 (current main).

Impact

An on-path observer can capture authentication material. Signature credentials
are particularly sensitive because the same header is replayable for up to 24
hours and is not request-bound.

External TLS termination is a valid deployment model; the issue is that secure
transport is neither provided nor required/documented by the shipped public
port configuration.

Code evidence

• server/src/main.rs:160-177 uses a plain TCP listener and Hyper HTTP/1.
• docker-compose.yml publishes 8080:8080 without a TLS proxy.
• server/src/vss_service.rs reads the authorization header from that request.

Proof of concept

On a test network, capture traffic while making any authenticated request:

sudo tcpdump -A -s0 'tcp port 8080'
curl -H 'Authorization: TEST_CREDENTIAL' http://SERVER:8080/vss/getObject

The Authorization header is visible in the packet capture.

Suggested remediation

• Document TLS termination as mandatory for production and ship a secure
  deployment example.
• Optionally support native TLS or require an explicit insecure opt-in for
  non-loopback binds.
• Use short-lived, request-bound credentials.

Reported by Bitcoin Red Team.

[TheBlueMatt]

The Docker file should just ship nginx in front or whatever, ideally with whatever settings are required to send the Keep-alive header.