Difference between revisions of "Securing XMPP"

From XMPP WIKI
Jump to navigation Jump to search
(→‎Prosody: Add some text and a link to Prosody docs for more info)
 
Line 1: Line 1:
=Security and Encryption in XMPP=
=Security and Encryption in XMPP=


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


==Aim==
==Current Goals==


* encrypted connections between clients and servers
* encrypted connections between clients and servers (a.k.a. "c2s")
* encrypted server to server connections
* encrypted server to server connections (a.k.a. "s2s")
* encryption working for virtual hosted XMPP environments (more than one domain per server)
* 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==
==Background==


XMPP does not encrypt connections by default (like maintaining your server using telnet instead of ssh). This page will show you how to enable encryption for your user's connections. This page covers using SSL certificates to encrypt and identify remote domains.
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 identify "s2s" connections to remote domains.


===Get a server certificate===
===Get a server certificate===

Revision as of 22:50, 10 September 2013

Security and Encryption in XMPP

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

Current 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 identify "s2s" connections to remote domains.

Get a server certificate

we will use example.com for this example

  • order a certificate for example.com (not servername.example.com) from your CA. StartCom 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 (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

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

s2s_secure_auth = true
s2s_insecure_domains = { "gmail.com" } -- Google doesn't support encrypted connections

Prosody (secure delegation for running multiple domains)

  • 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)

???

Tigase (secure delegation for running multiple domains)

???

Openfire

???