Various options in Prosody allow control over the behaviour of the certificate
verification process For example, some deployments choose to allow falling
back to traditional "dialback" authentication (XEP-0220), while others verify
via DANE, hard-coded fingerprints, or other custom plugins.
Implementing this flexibility requires us to override OpenSSL's default
certificate verification, to allow Prosody to verify the certificate itself,
apply custom policies and make decisions based on the outcome.
To enable our custom logic, we have to suppress OpenSSL's default behaviour of
aborting the connection with a TLS alert message. With LuaSec, this can be
achieved by using the verifyext "lsec_continue" flag.
We also need to use the lsec_ignore_purpose flag, because XMPP s2s uses server
certificates as "client" certificates (for mutual TLS verification in outgoing
s2s connections).
Commit 99d2100d2918 moved these settings out of the defaults and into mod_s2s,
because we only really need these changes for s2s, and they should be opt-in,
rather than automatically applied to all TLS services we offer.
That commit was incomplete, because it only added the flags for incoming
direct TLS connections. StartTLS connections are handled by mod_tls, which was
not applying the lsec_* flags. It previously worked because they were already
in the defaults.
This resulted in incoming s2s connections with "invalid" certificates being
aborted early by OpenSSL, even if settings such as `s2s_secure_auth = false`
or DANE were present in the config.
Outgoing s2s connections inherit verify "none" from the defaults, which means
OpenSSL will receive the cert but will not terminate the connection when it is
deemed invalid. This means we don't need lsec_continue there, and we also
don't need lsec_ignore_purpose (because the remote peer is a "server").
Wondering why we can't just use verify "none" for incoming s2s? It's because
in that mode, OpenSSL won't request a certificate from the peer for incoming
connections. Setting verify "peer" is how you ask OpenSSL to request a
certificate from the client, but also what triggers its built-in verification.
The ! commands have been broken for some time, and we're not going to
implement them right now. If we want fancier editing, we can now do that on
the client side (with readline and stuff).
Also removes mention of telnet!
This should bring some fixes and general robustness that mod_websocket had
missed out on. The duplicated code here is not at all ideal. To prevent this
happening again, we should figure out how to have the common logic in a single
place, while still being able to do the websocket-specific parts that we need.
The main known bug that this fixes is that it's possible for a session to get
into a non-destroyable state. For example, if we try to session:close() a
hibernating session, then session.conn is nil and the function will simply
return without doing anything. In the mod_c2s code we already handle this, and
just destroy the session. But if a hibernating websocket session is never
resumed or becomes non-resumable, it will become immortal!
By merging the fix from mod_c2s, the session should now be correctly
destroyed.
Although we do sometimes use single-line if blocks, I'm expanding this one to
make it easier to compare with the duplicated (but modified) code in
mod_websocket that we plan to de-duplicate one day.
The WIP groups support is not complete yet, and won't work without extra
modules (which are not yet a part of Prosody). For now we hide --group support
unless mod_invites_groups (community module) is specified in modules_enabled.
This allow a shell-command to provide a 'flags' field, which will automatically
cause the parameters to be fed through argparse.
The rationale is to make it easier for more complex commands to be invoked
from the command line (`prosodyctl shell foo bar ...`). Until now they were
limited to accepting a list of strings, and any complex argument processing
was non-standard and awkward to implement.
Changes from community version:
- Add options to allow explicit control over whether BOSH/WS is advertised
- Always serve XML at /host-meta (no guessing based on Accept), least surprising
Secondary roles are an advanced feature without any strong use cases
currently. Having multiple ways to manage roles is confusing.
Now the 'user:role' command will just show the primary role if that is all
there is, but will list secondary roles too if there are any (which in 99.9%
of cases there won't be).
This is similar to mod_lastlog/mod_lastlog2.
Some functionality was dropped, compared to mod_lastlog2. These features
(recording the IP address, or tracking the timestamp of multiple events) are
handled better by the mod_audit family of modules. For example, those
correctly handle multiple logins, IP address truncation, and data retention
policies.
The "registered" timestamp from mod_lastlog2 was also dropped, as this has
been stored in account_details by Prosody itself since at least 0.12 already.
