November 2014 Archives
2014-11-20 23:50:18
jabberd with FS and without SSL3
This post is an update to my post about enabling forward secrecy in jabberd.
If you use a stock Red Hat / Centos 5 OpenSSL package then you will maybe notice that SSL3 is still enabled. This will be "punished" by the IM Observatory. In order to manually disable the ancient SSLv2 and SSLv3 protocols you just need an extra call of SSL_CTX_set_options.
This is included in a new version of the forward secrecy patch. A binary RPM package for RHEL / Centos 5 and a source RPM package are also available.
If you use the additional OpenSSL 1.0.1 package on RHEL / Centos 5 then you should use the special jabberd-openssl1 package (SRPM) which gives you also TLS 1.1 and TLS 1.2 and even more points on the IM Observatory.
Update 2015-08-09: The package is included in the tuxad repo.
Posted by Frank W. Bergmann | Permanent link | File under: c, ssl, encryption, rpm, yum, repository, redhat, openssl, jabber
2014-11-19 23:57:58
OpenSSL updates/enhancements for RHEL / Centos 5
As already mentioned Red Hat's reaction to POODLE was some kind of halfheartedly. They provide "resolutions" how to disable SSLv3 on services like i.e. postfix or apache. Red Hat does not provide a modified OpenSSL package which radically removes the ancient SSLv3 (and SSLv2) protocol code from OpenSSL. This has numerous causes like:
- A rebuild of many dependent packages will maybe necessary.
- Totally disabling SSLv3 may have drawbacks on software which actually needs it (which is against the enterprise philosophy).
- Patching OpenSSL is a nightmare due to countless bugs in this crappy software (see Heartbleed, POODLE, comments of the LibreSSL authors and - of course - the source code).
A switch of OpenSSL 0.9.8 to OpenSSL 1 would have even more impacts. But using OpenSSL 1 as an additional package together with an SSLv3-stripped OpenSSL 0.9.8 is a nice solution to remove unsafe code and to provide modern encryption. This was my way.
openssl-0.9.8e without SSLv3
My openssl-0.9.8e-srvrclnt-no-ssl23.patch does the following modifications:
- Strip SSLv2 and SSLv3 code from client and server.
- Return with UNSUPPORTED_PROTOCOL error when using these ancient protocols
- Set a modern and (for OpenSSL 0.9.8) well balanced SSL_DEFAULT_CIPHER_LIST.
- Remove SSLv2/3 code also from internal test program ssltest used when building OpenSSL.
- Remove SSLv2/3 code also from internal test script testssl used when building OpenSSL.
Instead of using the patch you can also download and rebuild the source rpm package.
Here's some testing output of ssltest.sh:
# ssltest.sh 127.0.0.1 443 Testing protocols: SSLv2: NO SSLv3: NO TLSv1: YES TLSv1.1: NO TLSv1.2: NO Testing ciphers using protocol TLSv1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=... AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=... EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=... AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 # ssltest.sh 127.0.0.1 25 smtp Testing protocols: SSLv2: NO SSLv3: NO TLSv1: YES TLSv1.1: NO TLSv1.2: NO Testing ciphers using protocol TLSv1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=... DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=...
openssl-1.0.1 as additional package
I took the source rpm package openssl-1.0.1e-30 of RHEL / Centos 6 and patched it to compile and install on a RHEL / Centos 5 system besides the OpenSSL base installation 0.9.8.
In opposition to the patch for OpenSSL 0.9.8 I disabled SSLv2 and SSLv3 code by just removing the protocols on every ssl context:
ret->options |= (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
You can test it with the source rpm package or directly with the openssl1 and openssl1-devel packages.
To actually use it you must recompile your applications with openssl1-devel installed (instead of openssl-devel). This can be done with commands like this: ***
# rpm -U openssl1-1.0.1e-30.el5_9.4rh5.i386.rpm # rpm -e openssl-devel # rpm -U openssl1-devel-1.0.1e-30.el5_9.4rh5.i386.rpm # rpmbuild -ba jabberd.spec
Here's some testing output of ssltest.sh:
# ssltest.sh 127.0.0.1 5269 xmpp Testing protocols: SSLv2: NO SSLv3: NO TLSv1: YES TLSv1.1: YES TLSv1.2: YES Testing ciphers using protocol TLSv1.2 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM... DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) ... DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=... DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia... DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM... DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) ... DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=... DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=... DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia...
Update 2015-08-09:
The packages are included in the tuxad repo.
Update 2016-05-21: ***
Well, this "rpmbuild -ba jabberd.spec" is just an example for
compiling/ rpmbuilding an RPM package (in this case "jabberd")
with the openssl1 RPM package.
If you want i.e. dovecot to
use openssl1 package then you must
rebuild it with something like "rpmbuild --rebuild
dovecot.src.rpm".
Please let me explain the RHEL SSL trouble more in detail:
RHEL as "enterprise linux" (CentOS as well) will never do big
changes in their packages. In this case it is OpenSSL 0.98.
RHEL will always stay on this release and will only provide
important security patches.
The reason for that is that all packages with SSL (like
apache, postfix, dovecot) are using this package. Updating
OpenSSL to version 1 would require ALL these packages to be
recompiled.
As a workaround for this trouble I created this RPM package
"openssl1" to be additionally installed beside RHEL's
openssl package. If you have installed the openssl1-devel
package then all C headers and C libs for compiling are
installed and you can recompile/rebuild the software you would
like to have all SSL Ciphers and security and modern
encryption like the RHEL/CentOS 6 packages have.
But please keep in mind that this does not mean that old RPM
packages like RHEL 5's dovecot would get also i.e. ECDH
encryption out of the box. For ECDH support you will mostly
need a small patch. In case of "dovecot" I already did that:
The dovecot-1.0.7-9.el5_11.4.log.dh.i386.rpm in my YUM repo
contains 3 important patches. It logs the cipher/encrpytion
used, it has bigger DH params (2048 bits) and it has EC
cryptography support. Testing it with
ssltest.sh:
$ SSLCipherSuite=ALL ~/ssltest.sh 127.0.0.1 993 Testing: 127.0.0.1 993 ALL Testing protocols: SSLv2: NO SSLv3: NO TLSv1: YES TLSv1.1: YES TLSv1.2: YES Testing ciphers using protocol TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc= \ AESGCM(256) Mac=AEAD TempKey: ECDH, secp521r1, 521 bits ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc= \ AES(256) Mac=SHA384 TempKey: ECDH, secp521r1, 521 bits ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) \ Mac=SHA1 TempKey: ECDH, secp521r1, 521 bits DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc= \ AESGCM(256) Mac=AEAD TempKey: DH, 2048 bits DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) \ Mac=SHA256 TempKey: DH, 2048 bits DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) \ Mac=SHA1 TempKey: DH, 2048 bits DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc= \ Camellia(256) Mac=SHA1 TempKey: DH, 2048 bits ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc= \ AESGCM(128) Mac=AEAD TempKey: ECDH, secp521r1, 521 bits ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc= \ AES(128) Mac=SHA256 TempKey: ECDH, secp521r1, 521 bits ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) \ Mac=SHA1 TempKey: ECDH, secp521r1, 521 bits DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc= \ AESGCM(128) Mac=AEAD TempKey: DH, 2048 bits DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) \ Mac=SHA256 TempKey: DH, 2048 bits DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) \ Mac=SHA1 TempKey: DH, 2048 bits DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) \ Mac=SHA1 TempKey: DH, 2048 bits DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc= \ Camellia(128) Mac=SHA1 TempKey: DH, 2048 bits
Summary:
To benefit from openssl1.rpm you must recompile/rebuild
software with openssl1-devel.rpm installed.
Some packages in my
tuxad YUM repo
are already recompiled and patched RHEL rpm packages.
Posted by Frank W. Bergmann | Permanent link | File under: c, ssl, encryption, rpm, yum, repository, redhat, openssl
2014-11-08 22:09:46
jabberd Forward Secrecy patch
jabberd2 is a widely used XMPP server written in C. Release 2.2.17 is also the base for Apple's ChatServer. This release has support for a custom TLS cipher list but it is hardcoded in source. It does not support DHE ciphers due to missing usage of DH params. The latest release (2.3.2) still lacks this support for Forward Secrecy. There's a commit of 2014-03-17 in its git repository at github. But this commit only uses a fixed / pre-computed set of DH params and does not offer configurable DH param support i.e. by files (maybe cron generated).
This patch makes the cipher list configurable by reading in
/etc/jabberd/SSLCipherSuite
at start time.
DH params for the fixed lengths 512, 1024 and 2048 bits are read from
/etc/jabberd/dh512.pem /etc/jabberd/dh1024.pem /etc/jabberd/dh2048.pem
If these files does not exist then internal defaults will be used. The files may be updated at running time. If a new TLS connections requires reading of the DH parms then the mod time will be checked. If it has changed then the new file(s) will be read and used. To get "real" forward secrecy you should regularly update the DH params with something like
openssl dhparam -out tmp 1024 && mv tmp dh1024.pem
Beside the patch there's also a binary RPM package for RHEL 5 and a Source RPM package available.
(An update of the patch is available.)
Update 2015-08-09: The package is included in the tuxad repo.
Posted by Frank W. Bergmann | Permanent link | File under: c, ssl, encryption, rpm, yum, repository, redhat, openssl, jabber
2014-11-02 23:07:32
Mac OS X 10.4 disable SSL3
This blog post will show you how to disable the SSL3 protocol in the system ssl lib on Mac OS X 10.4 PPC. This is only for educational purposes because it does not protect you against POODLE attacks. It will not turn your OS into a secure OS. You must recompile many other packages like Kerberos Framework, Mail.app and more with special configurations and/or patches to have POODLE protection and (only) Forward Secrecy ciphers.
First you must download the appropriate OpenSSL-38 package from opensource.apple.com. Unpack it and apply the patch to disable SSLv3. Alternatively you can download my patched package.
The patch contains more changes than just calling 'configure' with the no-ssl3 option. You know the OpenSSL guys? Those guys with Heartbleed and the fantastic Debian co-work causing 16 bit entropy? Using the no-ssl3 option causes defining OPENSSL_NO_SSL3 while compile time. But this will also disable SSL3 ciphers because the programmers don't distinguish between ciphers and protocol. The patch removes SSLv2 code in all code parts and removes SSLv3 protocol code in server and client.
Another "feature" of the openssl build system is the include of the system's openssl header. The most simple way to avoid this is to rename it (and our goal is to replace it after successful compiling):
# mv /usr/include/openssl /usr/include/openssl.off
The patched header has a different default cipher list with FS ciphers.
Before compiling we do a test by launching a local server and connecting to it. The local server:
# /usr/bin/openssl s_server -nocert -accept 443 \ -www -cipher ALL Using default temp DH parameters ACCEPT
Client connect with no protocol default:
$ /usr/bin/openssl s_client -connect 127.0.0.1:443 \ -cipher ALL </dev/null ... --- New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA SSL-Session: Protocol : TLSv1 Cipher : ADH-AES256-SHA
Client connect with ssl3 protocol default:
$ /usr/bin/openssl s_client -connect 127.0.0.1:443 \ -cipher ALL -ssl3 </dev/null ... --- New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA SSL-Session: Protocol : SSLv3 Cipher : ADH-AES256-SHA ...
The first connection uses TLSv1 and the second uses SSLv3. The server accepts the connections and doesn't show errors:
ACCEPT ACCEPT
Now we will compile OpenSSL. The build process involves creating a different build directory. Just issue these commands:
$ make CC_Archs="-arch ppc" \ SRCROOT=/tmp/OpenSSL-srcroot install_source $ cd /tmp/OpenSSL-srcroot/ $ make CC_Archs="-arch ppc" $ make CC_Archs="-arch ppc" install
The install target uses /tmp/OpenSSL/Release/ as root directory. Make backups of openssl, c_rehash, libssl and libcrypto. Install the freshly compiled files into /usr/bin and /usr/lib.
Then start the server again and connect to it with default protocol setting:
$ /usr/bin/openssl s_client -connect 127.0.0.1:443 \ -cipher ALL </dev/null ... --- New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA SSL-Session: Protocol : TLSv1 Cipher : ADH-AES256-SHA
Now the interesting part: Client connection with ssl3 protocol default:
$ /usr/bin/openssl s_client -connect 127.0.0.1:443 \ -cipher ALL -ssl3 </dev/null CONNECTED(00000003) 3045:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES: \ ssl handshake failure:s3_pkt.c:529:
Forcing SSLv3 connection causes an error. As a last test we use the original openssl:
$ /usr/bin/openssl.2009-02-16.orig s_client -connect \ 127.0.0.1:443 -cipher ALL -ssl3 </dev/null CONNECTED(00000003) 3055:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES: \ ssl handshake failure:s3_pkt.c:529:
This causes also an error. At the same time the server shows errors about an "unknown" protocol:
3034:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO: \ unknown protocol:s23_srvr.c:534: ACCEPT 3034:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO: \ unknown protocol:s23_srvr.c:534: ACCEPT
This was the goal: SSLv3 protocol is disabled.
Posted by Frank W. Bergmann | Permanent link | File under: c, ssl, encryption, apple, openssl, developer