Expand description
SIP over TLS (RFC 3261 §26, RFC 5922).
A TLS connection differs from a TCP one in its bytes, not in its transaction handling — so
this crate reuses crate::tcp’s framing and pool wholesale and adds only the handshake
and the verification around it.
The verification is the point, and docs/specs/sip-tls.md settles what it is. Two decisions
from there govern this file:
There is no way to turn it off. No insecure flag, no danger_accept_invalid_certs.
Code that needs to trust a fixture CA adds that CA as a trust anchor — a different operation
with a different shape, saying what to trust rather than that anything goes. Every stack
that ships the other kind of flag eventually finds it in production.
The name checked is the one sipx set out to reach, not the name a SRV record led to. Checking the resolved name would let whoever can influence DNS choose which certificate is acceptable, and the verification becomes decorative.
The version floor is the library’s, not ours (§3.5, RFC 8996). Both configurations below
are built from rustls’s default version set, and neither this file nor anything above it
names a version — so 1.0 and 1.1 are excluded because the library has nothing older than 1.2
to select, not because sipx refuses them. That makes the floor a dependency property: a
backend that still spoke 1.0 would move it without a line changing here, which is why RFC
8996’s registry row cites tests/tls_versions.rs — the refusal observed on the wire, plus the
version set asserted — rather than the sentence in the spec.
Structs§
- Client
Tls - How sipx behaves as a TLS client.
- Identity
- A certificate and key sipx presents.
- Server
Tls - How sipx behaves as a TLS server.
- Trust
Anchors - Which certificates to trust.
Enums§
- TlsError
- What can go wrong establishing TLS.
Functions§
- verification_
name - The name a certificate is checked against.