This matches the behaviour of the newer mod_sasl2 implementation. It allows
plugins to observe (and potentially, with caution, modify) the SASL exchange.
As extension point for rate limiting and similar checks, so they can
hook a single event instead of <{sasl1}auth> or stream features, which
might not be fired in case of SASL2 or e.g. HTTP based login.
The default config was updated in this way long ago, but if no option was
present in the config, Prosody would load internal_plain.
This change can result in changes (for the better) for people using very old
configuration files lacking an 'authentication' setting.
These options have been specified (and enabled) in the default config file for
a long time. However if unspecified in the config, they were not enabled. Now
they are.
This may result in a change of behaviour for people using very old config
files that lack the require_encryption options. But that's what we want.
This channel binding method is now enabled when a hash is manually set in the
config, or it attempts to discover the hash automatically if the value is the
special string "auto".
A related change to mod_c2s prevents complicated certificate lookups in the
client connection hot path - this work now happens only when this channel
binding method is used. I'm not aware of anything else that uses ssl_cfg (vs
ssl_ctx).
Rationale for disabling by default:
- Minor performance impact in automatic cert detection
- This method is weak against a leaked/stolen private key (other methods such
as 'tls-exporter' would not be compromised in such a case)
Rationale for keeping the implementation:
- For some deployments, this may be the only method available (e.g. due to
TLS offloading in another process/server).
This originally used a WIP implementation of cert:sigalg(), a method to
retrieve certificate signature algorithm, but it was never submitted
upstream. https://github.com/Zash/luasec/tree/zash/sigalg
cert:getsignaturename() was merged in
de393417b7
XEP-0440 v0.3.0 made implementing tls-server-end-point a MUST
Since this channel binding method is said to enable TLS offloading then
you need tell Prosody the hash (or the full cert), so this seems like a
good start.
Support is RECOMMENDED in XEP-0440 version 0.2
The 'scope' term derives from OAuth, and represents a bundle of permissions.
We're now setting on the term 'role' for a bundle of permissions.
This change does not affect any public modules I'm aware of.
Brings back SCRAM-SHA-*-PLUS from its hiatus brought on by the earlier
channel binding method being undefined for TLS 1.3, and the increasing
deployment of TLS 1.3.
See 1bfd238e05ad and #1542
Requires future version of LuaSec, once support for this key material
export method is merged.
See https://github.com/brunoos/luasec/pull/187
For this, various accessor functions are now provided directly on the
sockets, which reach down into the LuaSec implementation to obtain the
information.
While this may seem of little gain at first, it hides the implementation
detail of the LuaSec+LuaSocket combination that the actual socket and
the TLS layer are separate objects.
The net gain here is that an alternative implementation does not have to
emulate that specific implementation detail and "only" has to expose
LuaSec-compatible data structures on the new functions.
The 'tls-unique' channel binding is undefined in TLS 1.3 according to a
single sentence in parenthesis in Apendix C of RFC 8446
This may trigger downgrade protection in clients that were expecting
channel binding to be available.
Better than the previous string concatenation of SASL failure condition
and optional text sent by the remote server.
Would be nice to have a text per condition, other than the probably most
common 'not-authorized'.
Mistakenly iterates over the set of all supported mechanisms instead of
the one without insecure mechanisms if the connection is insecure.
Not a problem if c2s_require_encryption is true
Introduced in 56a0f68b7797
Kim Alvefur