nntp: Add TLS support for the news session - #472
Conversation
NntpClient speaks only cleartext, so a deployment whose news server sits across an untrusted network cannot protect the session. lore.kernel.org offers neither STARTTLS nor a 563 listener, but an internal public-inbox mirror can. Wrap the session in an optional TLS layer. NNTPS is implicit, so the handshake runs before the greeting and every command method is unchanged. Trust anchors come from the host certificate store, which leaves an internal CA a property of the deployment rather than of the config. Walking that store is blocking file I/O, so the load runs off the executor thread. The ingestor continues to connect in the clear. Dropping a TlsStream sends no close_notify, and a session that ends that way is a truncation to a strict peer. quit() shuts the stream down after the 205 so the TLS close is orderly. Both ring and aws-lc-rs reach this binary through reqwest and lettre. rustls cannot choose between them on its own, and neither crate installs a process default, so the config names the provider. Signed-off-by: Chuck Lever <cel@kernel.org>
The NNTP client can wrap its session in TLS, but nothing reaches that path. A deployment whose news server requires NNTPS has no way to ask for it. Add nntp.tls and pass it to both connect sites. It defaults to off, so an existing Settings.toml continues to connect in the clear. The port is left alone. NNTPS listens on 563 rather than 119, and deriving one from the other would silently move a server an operator had pinned. Signed-off-by: Chuck Lever <cel@kernel.org>
|
Rebased onto 54a74ba to clear the merge conflict. The pair Two notes on the rebase. The conflict in src/nntp.rs was mechanical. Your d798e62 adds two NntpClient::connect() call sites, one in the The caveat in the description still holds. None of this has been |
NntpClient speaks only cleartext. lore.kernel.org offers neither
STARTTLS nor a 563 listener, but an internal public-inbox mirror
can require TLS.
NNTPS is implicit TLS. The handshake runs before the greeting, so
every command method is untouched (patch 1). Trust anchors come
from the host certificate store, which retains the local CA as a
property of the deployment rather than of the config. The config
does name the rustls crypto provider: ring and aws-lc-rs both
reach this binary through reqwest and lettre, and neither installs
a process default.
The knob is nntp.tls, default off, so an existing Settings.toml
continues to connect in the clear (patch 2). The port is not
derived from it. NNTPS listens on 563 rather than 119, and
deriving one from the other would silently move a server an
operator had pinned.
Note: I thought our internal security policy might require the use
of NNTPS, so I implemented these patches. But it turns out only port
22 is open between our internal sashiko and public-inbox instances.
So the patches are untested. Feel free to drop them.