prosody
a5d5fefb8b68
INSTALL
Software / code / prosody
File
INSTALL @ 13801:a5d5fefb8b68 13.0
mod_tls: Enable Prosody's certificate checking for incoming s2s connections (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.
| author | Matthew Wild <mwild1@gmail.com> |
|---|---|
| date | Tue, 01 Apr 2025 17:26:56 +0100 |
| parent | 12286:ad88732eea51 |
line wrap: on
line source
(This file was created from https://prosody.im/doc/installing_from_source on 2013-03-31) # Installing from source ## Dependencies There are a couple of development packages which Prosody needs installed before you can build it. These are: - The [Lua](http://lua.org/) library, version 5.4 recommended - [OpenSSL](http://openssl.org/) - String processing library, one of - [ICU](https://icu.unicode.org/) (recommended) - [GNU libidn](http://www.gnu.org/software/libidn/) These can be installed on Debian/Ubuntu by running `apt build-dep prosody` or by installing the packages `liblua5.4-dev`, `libicu-dev` and `libssl-dev`. On Mandriva try: urpmi lua liblua-devel libidn-devel libopenssl-devel On Mac OS X, if you have MacPorts installed, you can try: sudo port install lua lua-luasocket lua-luasec lua-luaexpat On other systems... good luck, but please let us know of the best way of getting the dependencies for your system and we can add it here. ## configure The first step of building is to run the configure script. This creates a file called 'config.unix' which is used by the next step to control aspects of the build process. ./configure All options to configure can be seen by running ./configure --help ## make Once you have run configure successfully, then you can simply run: make Simple? :-) If you do happen to have problems at this stage, it is most likely due to the build process not finding the dependencies. Ensure you have them installed, and in the standard library paths for your system. For more help, just ask ;-) ==== install ==== At this stage you should be able to run Prosody simply with: ./prosody There is no problem with this, it is actually the easiest way to do development, as it doesn't spread parts around your system, and you can keep multiple versions around in their own directories without conflict. Should you wish to install it system-wide however, simply run: sudo make install ...it will install into /usr/local/ by default. To change this you can pass to the initial ./configure using the 'prefix' option, or edit config.unix directly. If the new path doesn't require root permission to write to, you also won't need (or want) to use 'sudo' in front of the 'make install'. Have fun, and see you on Jabber!
