Securing XMPP

This page provides instructions for XMPP server administrators to secure XMPP client and server connections.

Current Goals

The information on this page is designed to meet the following goals:

• encrypted connections between clients and servers (a.k.a. "c2s")
• encrypted server to server connections (a.k.a. "s2s")
• encryption working for virtual hosted XMPP environments (more than one domain per server)

Naturally, other goals might be appropriate now and in the future: end-to-end encryption for one-to-one messaging, file transfer, and voice/video (e.g., OTR and ZRTP); encryption of multi-user chatrooms; onion routing (e.g., Tor) for stanza routing; mix networks; password-free authentication; etc.

Background

Although many IM clients can be configured to force encrypted connections for the c2s hop, XMPP does not encrypt connections by default (this is like using telnet instead of ssh to administer remote machines). Also, if you are communicating with someone at another server, there is no way to know if the s2s hop has been encrypted.

This page will show you how to enable encryption for your user's c2s connections and also to encrypt and authenticate s2s connections to remote domains.

Get a server certificate

We will use example.com to illustrate.

• order a certificate for example.com (not servername.example.com) from your preferred CA. For instance, StartSSL offers free certificates.

Configure your DNS

Ensure that the following DNS records are set:

_xmpp-server._tcp.example.com. 18000 IN SRV 0 5 5269 servername.example.com. 
servername.example.com.        18000  A 10.10.10.10 # you must have an A record for your server

You can test your DNS setup at http://protocol.buddycloud.com/

Securing client connections

Unless you have a very good reason, there's really no good reason to have clients connecting in clear text to their XMPP server (remember, this is like using telnet instead of ssh to maintain your server).

The following settings ensure that only encrypted connections are accepted.

eJabberd

% Ordinary client-2-server service
[{5222, ejabberd_c2s, [{access, c2s},
starttls_required, {certfile, "/etc/ssl/certs/ejabberd.pem"},
{shaper, c2s_shaper}]},

Prosody

Ensure mod_tls is enabled (this is the default):

modules_enabled = {
   -- Other modules
   "tls"; -- Enable mod_tls
}

Then look for c2s_require_encryption in your config, and set it to true:

c2s_require_encryption = true

For more information see Prosody's mod_tls 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

Securing connections between XMPP servers

There are two kinds of setups

1. single domain
2. server hosting multiple XMPP domains

Prosody (single domain)

• DNS: nothing to change
• Certificate: ensure that it matches your domain name (eg you should have a valid certificate for example.com)

Configuration

 c2s_require_encryption = true
 s2s_require_encryption = true
 s2s_secure_auth = true
 s2s_insecure_domains = { "gmail.com" }  -- Google doesn't support encrypted connections
 ssl                    = {
                          key         = "/etc/prosody/certs/example.org.pem";
                          certificate = "/etc/prosody/certs/example.org.pem";
                          cafile      = "/etc/prosody/certs/your-ca-cert(s).pem";
                          dhparam     = "/etc/prosody/certs/dh-2048.pem";
                          ciphers     = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH";
                          options     = {"no_sslv2", "no_sslv3", "no_ticket", "no_compression"};
                          }

Prosody (secure delegation with DANE)

• DNS: You need to be working with a registrar that supports DNSSEC
• Certificate: which certificate do we need? - how do we setup DANE in the nameserver?

Configuration

modules_enabled = {
       ...
       "s2s_auth_dnssec_srv";
}

Ejabberd (single domain)

% Use STARTTLS+Dialback for S2S connections
{s2s_use_starttls, true}.
{s2s_certfile, "/etc/ejabberd/ejabberd.pem"}.
% Need a way to whitelist GTalk servers

Ejabberd (secure delegation for running multiple domains)

??? Does Ejabberd support DANE yet? Doesn't look promising.

Tigase (single domain)

• 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 (more information: --s2s-skip-tls-hostnames):

 --s2s-skip-tls-hostnames = domain1,domain2

Tigase (secure delegation for running multiple domains)

• certificate configuration is same as described in section #Securing client connections
• no support for DANE/DNSSEC

Openfire

???