Skip to main content

Module tls

Module tls 

Source
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§

ClientTls
How sipx behaves as a TLS client.
Identity
A certificate and key sipx presents.
ServerTls
How sipx behaves as a TLS server.
TrustAnchors
Which certificates to trust.

Enums§

TlsError
What can go wrong establishing TLS.

Functions§

verification_name
The name a certificate is checked against.