Implement TLS transport with custom certificate verifier and fingerprint pinning
Replace the TLS-not-yet-implemented stub in the PwrClient with a working
rustls-based TLS 1.3 connection layer. The connect_tls function builds a
ClientConfig using the dangerous API with a custom certificate verifier
(CertVerifier) that accepts self-signed server certificates — necessary
because pwr-server generates its own ECDSA P-256 certificate during init
rather than obtaining one from a public CA. Authentication is provided by
the PSK handshake running over the encrypted channel, so the TLS layer
provides confidentiality while the application layer handles mutual
authentication.
The verifier supports optional SHA-256 certificate fingerprint pinning.
When a server_fingerprint is present in the client config, the verifier
computes the SHA-256 hash of the server’s end-entity certificate and
compares it against the pinned value, rejecting the connection on
mismatch. When no fingerprint is configured, the verifier accepts any
certificate but logs the observed fingerprint for the user to pin later,
enabling a trust-on-first-use workflow.
Signature verification in the verifier accepts all TLS 1.2 and 1.3
signatures without checking against a root CA. This is intentional: the
security model relies on PSK-based mutual authentication at the
application layer combined with certificate pinning for defense-in-depth,
rather than on the Web PKI trust infrastructure which would reject
self-signed certificates. The supported_verify_schemes list advertises
ECDSA and RSA schemes to maximize compatibility.
Comments 0
No comments yet. Be the first!
Sign in to join the conversation.