[ejabberd] Authentication and security problems

Konstantin Khomoutov flatworm at users.sourceforge.net
Fri Apr 15 12:49:09 MSD 2011


On Wed, 13 Apr 2011 15:49:10 +0300
Adriana Moga <adriana.moga at rcs-rds.ro> wrote:

[...]
> >> I'm fighting with ejabberd (2.1.5, 2.1.6) on security side.
> >> Even I have enabled SSL/TLS and a valid certificate the
> >> communication per c2s and s2s is not crypted.
> > Enabling STARTTLS does not, by itself, mean c2s communications will
> > be encrypted because clients are not required to actually use this
> > feature. If you want to *force* usage of STARTTLS, look at
> > "starttls_required" option for the ejabberd_c2s listener [1] and
> > the "s2s_use_starttls" global/host option which can be set to
> > "required" etc [2].
> I enabled "starttls_required" for ejabberd_c2s listener. Could I have 
> problems with a self-signed certificate?
Self-signed certificate, in itself, cannot be a problem; it might cause
problem if an entitiy participating in the TLS handshake opts to verify
the trust path of the certificate presented by the server and refuses
to accept it if it finds a self-signed certificate in its chain.
But this is usually controlled by the settings of a particular
piece of software (I assume this software is XMPP clients in your case).
And all XMPP clients I happened to run merely warn the user about such a
certificate and ask if they should proceed with the handshake or not.
Some of them even allow the user to "accept" the presented certificate
permanently and never ask again--this is done by remembering the
certificate's "fingerprint" (read: a cryptographic hash calculated on
its data).
Also, no one prevents you from deploying your own private CA, install
its certificate to all client machines and then use that CA to issue a
certificate for the server.  Such server's certificate will be then
happily accepted by the clients because they will trust your CA's cert.

[...]
> > Also keep in mind, that if you really
> > need privacy and integrity for certain communications over XMPP,
> > consider using GPG -- this helps maintain the required security
> > properties with regard to individual conversations even over
> > insecure links.
> Do you mean GPG plugin for ejabber clients, right?
Yes.

[...]
> > Note also that if you're using LDAP authentication (seems to be
> > true), there's no way to not transfer passwords in clear
> > text--ejabberd will use SASL PLAIN mech to carry out
> > authentication.  On the other hand, it will not make this mech
> > available to the client unless the STARTTLS has been successfully
> > used and an encrypted link has been established. In the light of
> > this, I fail to see how the first point of your message does apply
> > to the situation: using authentication against LDAP effectively
> > forces clients to use TLS.
>        There is a method to find if STARTTLS isn't successfully used?
> My doubts are when I have enabled "{ldap_tls_verify, hard}" I got
> "LDAP connection failed" and Active Directory authentication didn't
> work. Should be a problem with my self-signed certificate?
I don't know, but let's quote the manual: "This option specifies
whether to verify LDAP server certificate or not when TLS is enabled.
When hard is enabled ejabberd doesn’t proceed if a certificate is
invalid."--this basically means that LDAPS will fail if ejabberd fails
to verify the certificate presented by your LDAP server.  Now its your
turn to figure out why ejabberd fails to verify it.

> When I have enabled only "{ldap_encrypt, tls}", "{ldap_port, 636}"
> authentication against LDAP is working but I'm not sure if it's
> working with TLS .
I'm quite sure the answer is yes, but this can be trivially figured out
using tcpdump, wireshark, tcpflow or a similar traffic dumping/analysis
tool.


More information about the ejabberd mailing list