Disable SSLv3, support TLSv1.1 and v1.2, disable weak ciphers

[runcom]

I installed ejabberd 13.10 on an ubuntu 12.04.3 and run the test on http://xmpp.net/result.php?id=6262 to test if my server is complaint against the new xmpp encryption manifesto at https://github.com/stpeter/manifesto/blob/master/manifesto.txt

But the result (for s2s connections) shows my ejabberd still uses SSLv3 and not TLS (both 1.1 and 1.2) and also it makes use of weak ciphers (EDH-RSA-DES-CBC3-SHA, DES-CBC3-SHA)

Is there any way to fix these issues?

Server running ejabberd like this -> http://xmpp.net/result.php?domain=0x90.io&type=server seems to pass the protocols and ciphers test but I suppose it's using a custom ejabberd recompiled

[rraptorr]

ejabberd uses OpenSSL for TLS. In order to support TLS 1.1/1.2 you need to have OpenSSL 1.0.1 on your system. If you don't have one, then ejabberd will not support TLS 1.1/1.2. Please upgrade your OpenSSL.
The same goes for supported cipher suites, you need a recent OpenSSL to support anything decent (from your results it seems that you are still using OpenSSL 0.9.8 which is severely outdated).

[runcom]

Nope, I'm using OpenSSL 1.0.1 on Ubuntu 12.04.3 64bit, how about disabling SSLv3? the p1_tls lib ejabberd is using (at least in the binary version I'm using) will enable it and the whole ciphers suite for sslv2/3 from what I've seen in that source code

[rraptorr]

Unfortunately, it really seems you don't. The set of supported TLS versions and cipher suite clearly indicates that you are not using OpenSSL 1.0.1. Please check exactly with what version your p1_tls driver is linked with (Ubuntu contains both OpenSSL 1.0.1 and 0.9.8).

As for the source code, p1_tls driver will simply use whatever TLS version underlying OpenSSL library supports (the only exception is that SSLv2 is explicitly disabled). If you link it with OpenSSL 1.0.1 you get TLS 1.1/1.2. Please don't be mistaken by the function SSLv23_method(), in OpenSSL it enables all supported TLS versions and is the only usable way to setup a server supporting multiple TLS versions (OpenSSL API and its naming is horrible).

Disabling SSLv3 is pretty simple, you must just add SSL_OP_NO_SSLv3 to the options in the p1_tls source, but this is up to developers. Please note that while you can disable SSL version 3, you cannot disable "SSLv3 cipher suites" as there is no such thing, all SSLv3 cipher suites are used also by all TLS versions (TLS 1.1/1.2 just adds some new ones).

[runcom]

Was just going to send a pull request for SSL_OP_NO_SSLv3, but I can't get
rid of how to link p1_tls becouse I'm running a binary installation of
ejabberd

2013/11/26 Janusz Dziemidowicz notifications@github.com

Unfortunately, it really seems you doesn't. The set of supported TLS
versions and cipher suite clearly indicates that you are not using OpenSSL
1.0.1. Please check exactly with what version your p1_tls driver is linked
with (Ubuntu contains both OpenSSL 1.0.1 and 0.9.8).

As for the source code, p1_tls driver will simply use whatever TLS version
underlying OpenSSL library supports (the only exception is that SSLv2 is
explicitly disabled). If you link it with OpenSSL 1.0.1 you get TLS
1.1/1.2. Please don't be mistaken by the function SSLv23_method(), in
OpenSSL it enables all supported TLS versions and is the only usable
way to setup a server supporting multiple TLS versions (OpenSSL API and its
naming is horrible).

Disabling SSLv3 is pretty simple, you must just add SSL_OP_NO_SSLv3 to the
options in the p1_tls source, but this is up to developers. Please note
that while you can disable SSL version 3, you cannot disable "SSLv3 cipher
suites" as there is no such thing, all SSLv3 cipher suites are used also by
all TLS versions (TLS 1.1/1.2 just adds some new ones).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/113#issuecomment-29279707
.

[rraptorr]

Then your binary was compiled against OpenSSL 0.9.8, please report this issue to the person that created the binary.

[runcom]

To ProcessOne then :/ anyway, will ejabberd may have some config options to enable/disable ciphers/dh like Prosody has? http://prosody.im/doc/advanced_ssl_config

[rraptorr]

Unfortunately I really have no idea;)

[runcom]

That would be great 🎱

[rraptorr]

Just as a side note, please be aware that if you disable 3DES then any XMPP client working on Windows XP won't be able to connect (assuming that the client uses Windows SChanell library for TLS) unless you have RC4 enabled which is considered even more broken.

Obviously this is your call, if you need support for such clients or not.

[alexeyshch]

Does anyone have an idea why DES-CBC3-SHA is considered weak on xmpp.net? It's in "high" cipher suite in openssl.

[rraptorr]

Probably just because it is less than 128 bits;) It even states that "No practical attacks on 3DES exist, but it is recommended to use the faster AES instead.". There is nothing particular against 3DES in https://github.com/stpeter/manifesto/blob/master/manifesto.txt or in http://tools.ietf.org/html/draft-sheffer-tls-bcp-01 3DES is just painfully slow, a lot slower than even unaccelerated AES.

On the other hand, currently RC4 is considered broken more than 3DES (see the above BCP and http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01) but xmpp.net does not mark it as weak. I'd say that the test should be updated:)

[alexeyshch]

openssl ciphers shows this:
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
Isn't 168 the key length?

[rraptorr]

Technically yes, in practice it is lower, see http://en.wikipedia.org/wiki/3des#Security

[alexeyshch]

Ah, thank you :)

[runcom]

@rraptorr I understand I cannot disable "SSLv3 cipher suites" as there is no such thing but then how can someone just select to use only the ones he needs/wants? (like this server http://xmpp.net/result.php?domain=0x90.io&type=server)

[runcom]

Btw, process-one said on Twtter they are going to work on building a binary installer against OpenSSL 1.0.1 and SSLv3 was removed from p1_tls by disabling it with SSL_OP_NO_SSLv3

[runcom]

Here is my new test report for s2s connection http://xmpp.net/result.php?id=6399

It clearly shows many ciphers are "enabled", even weak ones..

[rraptorr]

At the top of p1_tls driver code you can find:

#define CIPHERS "DEFAULT:!EXPORT:!LOW:!SSLv2"

This is the OpenSSL cipher specification, you can change it to suit your needs (see man ciphers for details).
As for your test results, those are now OK. I believe xmpp.net test is a bit inaccurate as there is no indication in current cryptography research that 3DES is "weak". On the other hand, RC4 should probably be disabled as it is now known that it is broken (see discussion above for details). Please remember that to maintain compatibility with Windows XP you must have either 3DES or RC4 enabled (Windows XP does not support AES at all).

[runcom]

Amazing, I was looking for that. Anyway, I'm not a crypto guy and apart from adding !RC4 to that define I wouldn't play around with that. I was thinking if you would recommend/write down a ciphers specification that suits most security "standard" and doesn't include weak ciphers as well as not exluding ciphers needed for OS compatibility. p1_tls would then maybe use that specification (not just me) effectlively "securing/standardazing" how ejabberd should work with this

Thanks a lot btw

[runcom]

I'd say the last 10 entries in this test http://xmpp.net/result.php?id=6399 should be avoided as far as I can tell

Or, I think I wouln't allow ciphers without forward secrecy on my server too (but this only apply to me now :))

[rraptorr]

IMHO you are mistaken, apart from RC4 the current setting is really OK (in fact it was me that contributed it at d2d5138). The point is, you cannot disable cipher suites that do not provide forward secrecy. You will run into many compatibility problems as there are many clients that do not support it. It is desirable, but you have to support clients that can't use it (unless you are sure what kind of clients you use and that they all support forward secrecy and that you do not have s2s connections). Supporting them is also not a vulnerability as such, clients that support forward secrecy will use it, others won't (TLS has builtin protection against downgrade attacks and XMPP clients don't do insecure TLS fallbacks as browsers do).

What I can recommend:

• build p1_tls against OpenSSL 1.0.1
• add SSL_OP_NO_SSLv3
• add !RC4 to the cipher spec

It seems that you already made all of those, so you should be fine.

One more note. There is no "golden" configuration for TLS (in XMPP or not). It all really depends on your needs. Online tests are fine and you can use them to make decisions about your configuration, but you should make conscious decision based on what are you trying to achieve. Are you trying to fight NSA? Do you have a few hundred TLS connections or many thousands? What clients will connect to your server? Do you acccept s2s connections? Do you make s2s connections? Even what kind of hardware do you have? Answers to all of those questions can change what kind of TLS configuration you need.

[rraptorr]

You can also add SSL_OP_CIPHER_SERVER_PREFERENCE option if you want. It will make server enforce its preference about cipher suites, instead of accepting client preference. It can force clients that are not properly configured to use a more secure cipher suite.

[runcom]

It wasn't just about me (yes, I've asked about my server and thanks for the kind replies), I'm trying to figure out a good configuration for most public server so ejabberd will be ok with these. That said, I'll try to pull request to add !RC4 to p1_tls as suggested

[rraptorr]

To be honest, I am not sure that it is a good idea. The point is, p1_tls should rather allow people to easily change supported cipher suites (providing an option to set the ciphers string) depending on their needs. Some people might still need RC4, despite its flaws.

[runcom]

You're right, but setting a default ciphers specification clearly disabling broken ciphers would be a great addition, As you stated above RC4 is broken/has flaws, allowing people to change ciphers suites would be an option and because RC4 is broken people who really need it would change the suites as needed. But you may agree it doesn't sound good to allow ciphers with flaws by default (imho this doesn't make sense to me either)

[alexeyshch]

Now there are options to change that ciphers list in the ejabberd config, and RC4 is disabled by default. So those who really need it can enable it without recompiling.

Thanks for patches and advices :)

[runcom]

Awesome :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.