[ejabberd] Authentication and security problems

Adriana Moga adriana.moga at rcs-rds.ro
Fri Apr 15 16:51:34 MSD 2011

On 04/15/2011 11:49 AM, Konstantin Khomoutov wrote:
> 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.
Thanks, I solved this.
> [...]
>>         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.
In another situation: When I configured openldap server, my ldap client 
had a client_certificate from LDAP server in order to use TLS connection 
on 636.
I'm not sure about how the things are with Active Directory (is not on 
my administration). So, I guess that AD should present me a client 
certificate for my ejabberd server. I used the same self-signed one and 
maybe this is the problem when ejabberd fails to verity the certificate.
... need to check more about 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.
Right, it's ok.

Thanks a lot,
Have a nice day!

More information about the ejabberd mailing list