Securing ejabberd with TLS encryption

In recent years security and privacy become central focus of users and system administrators. Here is brief guide on securing ejabberd connections and keep them private.

ejabberd have number of options that control security:

certfile: Full path to a file containing the default SSL certificateciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ commandprotocol_options: List of supported SSL protocolsdhfile: Full path to a file containing custom parameters for Diffie-Hellman key exchangestarttls: This option specifies that STARTTLS encryption is available on connections to the portstarttls_required: This option specifies that STARTTLS encryption is required on connections to the port.tls: This option specifies that traffic on the port will be encrypted using SSL immediately after connecting. This method is nowadays deprecated and not recommendedtls_compression: Whether to enable or disable TLS compression.s2s_use_starttls: This option defines if s2s connections are encrypteds2s_certfile: Full path to a file containing a SSL certificates2s_dhfile: Full path to a file containing custom DH parameterss2s_ciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ commands2s_protocol_options: List of supported SSL protocolss2s_tls_compression: Whether to enable or disable TLS compression

For many years security was something that was not primary concern in many cases in internet standards. ProcessOne team stands on the point that security is one of the primary factors thus we will recommend strong settings but also provide compatibility for reference only for those who want and need to retain support for insecure, legacy clients and servers but understand that this settings may jeopardize security and privacy. In below table you can find defaults for legacy and recommended settings:

Note: Clients that can connect to c2s ports need support at last TLS1.0. SSLv2 and SSLv3 have serious security flaws and have to be disabled. Also DH parameter is lowered here to 1024 bit as some older Java do not support higher grades.

Server-to-Server connections

s2s connections are more complex then client connections. If we want to federate with broad spectrum of XMPP servers, we have to allow unencrypted connections to that port. There are still lot of servers that do not support encryption. On the other hand, we have 2016 and it is hard to believe that there are still servers that sends data using plain-text. Choice is always up to server administrators, but ProcessOne strongly recommend to allow only secure, encrypted connections to port s2s:

ejabberd configuration allow to use custom DH parameters, this is important as recent research revealed weakness of widely and common used DH files (seehttps://weakdh.org). We are recommending to use at last 2048-bit DH parameters. To generate DH use openssl command, for example:

openssl dhparam -out /etc/ssl/ejabberd/dh2048.pem 2048

and add proper ejabberd config option (see previous section). If you need to support some old software like Java7, set DH size to 1024.

Appendix: Generating Private Key and Certificate Requests

You can generate self-signed certificates for your connections, however nowadays we strongly recommend that anyone use signed certificates by trusted and known Certificate Authority (CA). You can easily find commercial CA with pricing starting as low as $15 per year. There is also option of using free certificates from https://letsencrypt.org – see their docs for automated process of issuing certificates.

Generate Private Key (PK):

openssl genrsa -out xmpp_example_com.key 2048

this will generate PK – keep it safe, do not share. It is 2048 bit long, if you need bigger key, go for 4096 bits. Now you need to generate Certificate Signing Request (CSR) – that need to be send (usually copy&paste) to CA to generate certificate for you:

you will have to answer range of questions, and most important is: “Common Name (e.g. server FQDN or YOUR name)” this is where you place your domain name, like: xmpp.example.com , you can use wildcard names as well if you use certificate for other sub-domains.
After submitting CSR to CA you will get CRT – file that is actually public part of your key pair. Usually with your CRT, CA also provides certificate chain that need to be included in PEM file (see appendix about creating PEM files).

If you want to generate a self-signed certificate and not yet ask a certificate to a CA, you can use the following command. It is not recommended for production, but can be helpful for testing:

Yes, should be working this way, however I strongly recommend using trusted certificates – like https://letsencrypt.org – they are free and now ejabberd can handle automatically renewal process. See latest ejabberd release.