| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Enabling at least one of the ssl.verifyext modes enables a callback that
collects all the errors, which are used by mod_s2s to report better
problem descriptions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(fixes #1916) (thanks Damian, Zash)
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.
|
|
|
|
| |
Because it makes sense and improves feedback via logging
|
|
|
|
|
|
| |
It is the other end who should request client certificates for these
connections, we only need to send ours. Hopefully this was treated as a
noop, so probably no harm in keeping it. But hey, spring cleaning? :)
|
| |
|
|
|
|
|
|
|
| |
This field can be viewed using s2s:show(nil, "... starttls") even
without any special support in mod_admin_shell, which can be added later
to make it nicer. One can then assume that a TLS connection with an
empty / nil starttls field means Direct TLS.
|
|
|
|
| |
In case the network backend needs it for outgoing SNI or something.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This may be necessary if the session.conn object is not exchanged by the
network backend when establishing TLS. In that case, the starttls method
will always exist and thus that is not a good indicator for offering
TLS.
However, the secure bit already tells us that TLS has been established
or is not to be established on the connection, so we use that instead.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Relevant and sometimes needed for Direct TLS which mod_s2s uses this
context for. Primarily when e.g. mod_net_multiplex or equivalent ALPN
based dispatch is used.
All these contexts should likely move away from mod_tls and into either
mod_s2s or portmanager. The later already duplicates some of this work.
|
|
|
|
|
|
|
|
|
|
| |
So that the same TLS context is used for both Direct TLS and starttls,
since they are supposed to be functionally identical apart from the few
extra round trips.
A new event is added because the 's2s-created' event fires much later,
after a connection has already been established, where we need the TLS
context before that.
|
|
|
|
| |
As suggested by RFC 7590
|
|
|
|
|
| |
Also special thanks to timeless, for wordlessly reminding me to check
for typos.
|
|
|
|
| |
Nicer than the "unsupported stanza type" error we get otherwise.
|
|
|
|
|
| |
Originally added in 5b048ccd106f
Merged wrong in ca01c449357f
|
|
|
|
|
|
|
| |
Can happen in case opportunistic_writes is enabled and the session got
destroyed while writing that tag.
Thanks Ge0rG
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Meant to reduce user confusion over what's reloaded and not.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Creating TLS contexts triggers a lot of messages from certmanager that
don't really describe their purpose. This is meant to provide hints
about that.
|
| |
| |
| |
| |
| | |
The 'ssl_config' setting in the mod_s2s network service is not used.
Only direct TLS ports use this currently.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
starttls over tls (thanks Remko and Tobias)
|
|
|
|
| |
type check
|
|
|
|
| |
was set
|
| |
|
| |
|
| |
|
|
|
|
| |
have ssl options set (thanks 70b1)
|
|
|
|
| |
adds that to the context)
|
|
|
|
| |
(fixes #511)
|
| |
|
| |
|
|
|
|
| |
c6caaa440e74, portmanager assumes non-falsy second return value is an error) (thanks deoren)
|
| |
|
|
|
|
| |
option to s2s_require_encryption so the later overrides the former
|
|
|
|
| |
the newer stanza:get_child APIs and optimize away some table lookups
|
| |
|
|\ |
|
| |
| |
| |
| | |
they differ
|
| | |
|
| | |
|
| | |
|