Difference between revisions of "Securing XMPP"
(Use YAML syntax for the ejabberd configuration file snippet.) |
Neustradamus (talk | contribs) m |
||
(11 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
== | == Clients == | ||
need to add something... | |||
== Servers == | |||
* | An XMPP Server is considered secure when the following (minimum) items are present: | ||
* | * The server is running with a server certificate | ||
* The server is configured to not allow any cleartext communications - S2S and C2S | |||
* The server supports XEP-198 | |||
* ... | |||
== Step1: Get a server certificate== | === Step1: Get a server certificate=== | ||
Let's say you run an XMPP service for <code> | Let's say you run an XMPP service for <code>domain.tld</code> (jids of user@domain.tld), you will need to order a certificate for with a subject or alt-name of <code>domain.tld</code> (not <code>server.domain.tld</code>) from your preferred cert provider. The certificate should also include alt-names for subomains such as <code>conference.domain.tld</code>, at least for services that should be accessible to remote users. | ||
== Step 2: Disable cleartext connections == | === Step 2: Disable cleartext connections === | ||
These instructions will disable any cleartext communication between servers and client connections. | These instructions will disable any cleartext communication between servers and client connections. | ||
=== ejabberd === | ==== ejabberd ==== | ||
Make sure that your ''ejabberd.yml'' contains the [http:// | Make sure that your ''ejabberd.yml'' contains the [http://docs.ejabberd.im/admin/guide/configuration/#listening-ports following settings]. | ||
* For client- | * For ejabberd >= 17.12 list all available PEM files in this top-level option | ||
certfiles: | |||
- "/etc/ejabberd/*.pem" | |||
* For client-to-server connections: | |||
listen: | listen: | ||
- | - | ||
Line 27: | Line 28: | ||
module: ejabberd_c2s | module: ejabberd_c2s | ||
starttls_required: true | starttls_required: true | ||
certfile: "/etc/ejabberd/certificate.pem" | # For ejabberd < 17.12 | ||
# certfile: "/etc/ejabberd/certificate.pem" | |||
* For server- | * For server-to-server connections: | ||
s2s_use_starttls: required | s2s_use_starttls: required | ||
s2s_certfile: "/etc/ejabberd/certificate.pem" | # For ejabberd < 17.12 | ||
# s2s_certfile: "/etc/ejabberd/certificate.pem" | |||
Further help: | Further help: | ||
* Homepage: [https://ejabberd.im/ ejabberd | * Homepage: [https://www.ejabberd.im/ ejabberd IM] | ||
* Chatroom: [xmpp:ejabberd@conference. | * Chatroom: [xmpp:ejabberd@conference.process-one.net?join ejabberd@conference.process-one.net] | ||
* Documentation: [ | * Documentation: [http://docs.ejabberd.im/admin/guide/ ejabberd Installation and Operation Guide] | ||
=== Prosody === | ==== Prosody ==== | ||
Prosody is aiming to be secure by default, as of version 0.12.x no changes to the default configuration is required to enable or enforce encrypted connections. | |||
Further help: | Further help: | ||
Line 48: | Line 49: | ||
* Documentation: [https://prosody.im/doc/security Prosody.IM: Security] | * Documentation: [https://prosody.im/doc/security Prosody.IM: Security] | ||
=== Metronome === | ==== Metronome ==== | ||
In Metronome's latest development tip, encryption requirement is the default setting, as long as TLS capability | In Metronome's latest development tip, encryption requirement is the default setting, as long as TLS capability | ||
is available, and no configuration change is needed. Otherwise ensure that ''metronome.cfg.lua'' contains the | is available, and no configuration change is needed. Otherwise ensure that ''metronome.cfg.lua'' contains the | ||
Line 56: | Line 57: | ||
Further help: | Further help: | ||
* Homepage: [ | * Homepage: [https://metronome.im Metronome IM] | ||
* Chatroom: [xmpp:grimoire@muc.metronome.im?join grimoire@muc.metronome.im] | * Chatroom: [xmpp:grimoire@muc.metronome.im?join grimoire@muc.metronome.im] | ||
* Documentation: [ | * Documentation: [https://metronome.im/documentation metronome.im/documentation] | ||
=== Tigase === | ==== Tigase ==== | ||
See http://www.tigase.org/content/vhost-tls-required for more details: | See http://www.tigase.org/content/vhost-tls-required for more details: | ||
--vhost-tls-required = true | --vhost-tls-required = true | ||
Line 77: | Line 78: | ||
* Documentation: [http://www.tigase.org/admin-guide Admin guide] | * Documentation: [http://www.tigase.org/admin-guide Admin guide] | ||
=== Openfire === | ==== Openfire ==== | ||
# Open the Openfire administration console | # Open the Openfire administration console | ||
# Go to '''Server Settings''' under '''Server''' | # Go to '''Server Settings''' under '''Server''' | ||
Line 90: | Line 91: | ||
* Documentation: [http://igniterealtime.org/projects/openfire/documentation.jsp Openfire documentation] | * Documentation: [http://igniterealtime.org/projects/openfire/documentation.jsp Openfire documentation] | ||
== Step 3: Check your XMPP Security == | === Step 3: Check your XMPP Server Security === | ||
[http://xmpp.net/ Test your XMPP security] to be sure. | [http://xmpp.net/ Test your XMPP security] to be sure. | ||
= Encryption Manifesto (archived) = | |||
== Aim: Encrypt All XMPP Connections == | |||
This page provides instructions for XMPP server administrators to secure XMPP client and server connections ready for the following [https://github.com/stpeter/manifesto/blob/master/manifesto.txt ubiquitous encryption manifesto] test days: | |||
* January 4, 2014 - first test day requiring encryption | |||
* February 22, 2014 - second test day | |||
* March 22, 2014 - third test day | |||
* April 19, 2014 - fourth test day | |||
* May 19, 2014 - '''permanent upgrade''' to encrypted network | |||
To achieve this, we need to: | |||
* Encrypt connections between clients and servers (C2S) | |||
* Encrypt server to server connections (S2S) |
Latest revision as of 16:51, 26 December 2023
Clients
need to add something...
Servers
An XMPP Server is considered secure when the following (minimum) items are present:
- The server is running with a server certificate
- The server is configured to not allow any cleartext communications - S2S and C2S
- The server supports XEP-198
- ...
Step1: Get a server certificate
Let's say you run an XMPP service for domain.tld
(jids of user@domain.tld), you will need to order a certificate for with a subject or alt-name of domain.tld
(not server.domain.tld
) from your preferred cert provider. The certificate should also include alt-names for subomains such as conference.domain.tld
, at least for services that should be accessible to remote users.
Step 2: Disable cleartext connections
These instructions will disable any cleartext communication between servers and client connections.
ejabberd
Make sure that your ejabberd.yml contains the following settings.
- For ejabberd >= 17.12 list all available PEM files in this top-level option
certfiles: - "/etc/ejabberd/*.pem"
- For client-to-server connections:
listen: - port: 5222 module: ejabberd_c2s starttls_required: true # For ejabberd < 17.12 # certfile: "/etc/ejabberd/certificate.pem"
- For server-to-server connections:
s2s_use_starttls: required # For ejabberd < 17.12 # s2s_certfile: "/etc/ejabberd/certificate.pem"
Further help:
- Homepage: ejabberd IM
- Chatroom: ejabberd@conference.process-one.net
- Documentation: ejabberd Installation and Operation Guide
Prosody
Prosody is aiming to be secure by default, as of version 0.12.x no changes to the default configuration is required to enable or enforce encrypted connections.
Further help:
- Homepage: Prosody IM
- Chatroom: prosody@conference.prosody.im
- Documentation: Prosody.IM: Security
Metronome
In Metronome's latest development tip, encryption requirement is the default setting, as long as TLS capability is available, and no configuration change is needed. Otherwise ensure that metronome.cfg.lua contains the following settings in the global section of your configuration:
c2s_require_encryption = true s2s_require_encryption = true
Further help:
- Homepage: Metronome IM
- Chatroom: grimoire@muc.metronome.im
- Documentation: metronome.im/documentation
Tigase
See http://www.tigase.org/content/vhost-tls-required for more details:
--vhost-tls-required = true
By default Tigase will read VHosts certificates from certs/ subdirectory match domain name against .pem filename of the certificate. Alternatively configuration for particular vhost certificate could be specified explicitly in init.properties:
basic-conf/virt-hosts-cert-<domain>=path/to/cert.pem
TLS for s2s connection is enabled by default; no option to configure it as required (certain domains can be configured to skip TLS for s2s with following configuration. For more information: --s2s-skip-tls-hostnames):
--s2s-skip-tls-hostnames = domain1,domain2
In order to have improved security Tigase features "hardened mode" which turns off workaround for SSL issues, turns off SSLv2, forces enabling more secure ciphers suites and also forces requirement of StartTLS.
--hardened-mode=true
Further help:
- Homepage: Tigase.org
- Documentation: Admin guide
Openfire
- Open the Openfire administration console
- Go to Server Settings under Server
- Then open Security Settings in the list to the left
- Check both radiobuttons labeled Required
- Check the checkbox marked Accept self-signed certificates
- Done!
Further help:
- Homepage: Openfire
- Chatroom: open_chat@conference.igniterealtime.org
- Documentation: Openfire documentation
Step 3: Check your XMPP Server Security
Test your XMPP security to be sure.
Encryption Manifesto (archived)
Aim: Encrypt All XMPP Connections
This page provides instructions for XMPP server administrators to secure XMPP client and server connections ready for the following ubiquitous encryption manifesto test days:
- January 4, 2014 - first test day requiring encryption
- February 22, 2014 - second test day
- March 22, 2014 - third test day
- April 19, 2014 - fourth test day
- May 19, 2014 - permanent upgrade to encrypted network
To achieve this, we need to:
- Encrypt connections between clients and servers (C2S)
- Encrypt server to server connections (S2S)