[ALUG] Logjam and Apache 2.2 in Ubuntu 12.04

Mon May 25 03:16:49 EAT 2015

Logjam is an attack to decrypt recorded traffic after the switch over
from asymmetric to symmetric encryption.

My personal problem: ssl-labs craped the rating for my https server I am
testing things down from A+ to B. This sucks.
So I was working the last days on a solution to get again a A+ rating.
Updating to Apache 2.4.7 or newer: Not a real solution for now. It is
not a real drop in update. I have some tricky configurations for which I
will need some time to adopt them to 2.4. So I decided to have a closer
look on mod_ssl.

A little bit a preamble what the problem is:

When encrypting both sides need a common known secret. This is called
symmetric encryption. Each party knows the secret key, can encrypt and
decrypt with this key. As long there are only a few and each trusts each
other this shared secret is fine. On the internet we have a problem: I
can not create a unique one for each of my (maybe) visitors and when I
share one key with everybody it is not longer a secret. And how do I
share a key with somebody I even don't know?

Here now comes asymmetric encryption: I have a private key which must be
kept secret and an public key anybody can know. This public key is sent
by the server together with the certificate when a client establishes a
connection. With the public key you can only encrypt but not decrypt.
With this asymmetric encryption client and server can now exchange a
unique, temporary on the fly created and only for this connection used
symmetric key.
So why shifting over to a different encryption when we have already a
encrypted connection? Symmetric encryption has one big advantage: It is
faster and the keys are shorter.
This direct key exchange now has another problem: If the secret key of
the asymmetric encryption is leaked or the public key can be broken the
communication can be decrypted afterwards.
Here now comes Diffie-Hellman key exchange. [1]
A really clever way to exchange secrets over insecure communication
ways. The key is never communicated and out of the information the two
parties exchanging about the key it can not be extracted - in theory.

The logjam attack described detailed in the paper "Imperfect Forward
Secrecy: How Diffie-Hellman Fails in Practice." [2] is addressing how to
break this key exchange and extract the key.

For now they broke 512 bit. With optimising they hope to be soon able to
break also key exchange with 768 bit.
The resources of this researchers are limited.
Others having much bigger resources.
And here now starts the real problem:
Many servers are using the same DH parameters.
This is now making it a serious problem. With the pre computed tables
the recorded traffic of thousands of servers can be decrypted in a short
time.
This is now also making it interesting for criminals.
Keep in mind that a bot net with several million infected PCs is a
serious amount of computing power.

At https://weakdh.org/logjam.html is also a video demonstrating how
recorded traffic was decrypted.

512 bit must any way be rated as broken. 768 bit will be broken soon and
1024 bit have to rated as weak.
Luckily the needed computing power to break the DH key exchange is
increasing exponential.
Upgrading to 2048 bit or more and having your own unique DH prime number
will make it safe again.

Some admins don't know what this parameter is and leave it default (if
you read in a config something with seed, salt or dh- pay attention to
it and change it!) or like in the case of Apache 2.2: DH was patched in
later and there is no configuration option to change this parameters. It
must be changed in the source code. As a result all Apache 2.2 binaries
compiled form one source using the same prime number. And the maximum
length of the DH parameters 2.2 is using is 1024 bit.
With 2.4 a DH parameter can be attached to the certificate file but
nearly nobody knows this so here also the (well known) default value
from the sources is used.
With 2.4.7 it can be configured individual and found it's way into the
documentation. But often it is forgotten to create and so again a well
known default is used.

But as said in the beginning: Upgrading to 2.4 is for now not something
I want to do.
After doing some changes in mod_ssl I had DH parameters of 2048 and 3072
bit. So far so good. Let's move on with some other enhacements.
I also wanted better support for EC (elliptic curve) ciphers. EC ciphers
having shorter keys. Shorter keys means less CPU cycles for
encryption/decryption.
In general good and really good for mobile devices. The cipher with the
monstrous name TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is using a 256 bit
key but offers the same security as plain RSA with a 3072 bit key.

I found in 2.2.26 support for ECDH ciphers was added. Why have I not
checked this before?
Downloading the sources for 2.2.29 Adding 2048 and 3072bit. Building:
The build exploded on many ends :(
So I copied my modified mod_ssl into the 2.2.22 source tree of Ubuntu
and: Build succeeded.
But: The bloody module still used 1024 bit. Grrrr...... 2048 was in and
when not asking for a specific length: 3072 bit are delivered. The
problem is libssl Ubuntu 12.04 is using. It is not accepting DH
parameters shorter than 768 bit but never asking for more than 1024 bit.
So the module is working correct. libssl was explicit requesting 1024
bit and the module returned 1024 bit.
But for what libssl is asking what it is getting: Two different things.
So I removed the anyway obsolete 512 bit and the 1024 bit completely.
Now the module is returning always 3072 bit. libssl is not requesting
1024 bit. It is requesting a key not shorter than 1024 bit. So there is
no problem with returning longer keys.
Just for curiosity I will test 8192 bit. openssl is still creating it.
Running now since more than one day on a Xeon E5-2630..... How long will
it need for 16384 bit? weeks? months? longer?

Some changes in ssl.conf and beside now having a A+ rating again:
Forward secrecy now working with all browsers supporting it somehow.

If somebody wants to build this also here are the steps how to do it:

Before you begin check at https://weakdh.org/sysadmin.html if your
server is using short and common known DH parameters.

1. Update your system: apt-get update && apt-get upgrade
2. apt-get install indent build-essential dpkg-dev
3. create a directory to build, cd there
4. apt-get source apache2
5. cd apache2.2/mod_ssl/
6. Download the patched version:
wget http://download.ict-pros.co.tz/mod_ssl-apache2.22.tar.bz2 and
unpack it: tar xfj mod_ssl-apache2.22.tar.bz2
7. cd ssl and creating there new DH parameters: perl ./ssl_engine_dh.c
This will take some time!
8. Return to the root of the source directory and build the packages:
dpkg-buildpackage -b -us
9. After a (hopefully) successful build you will find the new deb
packages one directory above. Otherwise install the missing packages.
10. You can now copy direct the created module from
debian/apache2.2-bin/usr/lib/apache2/modules/mod_ssl.so to
/usr/lib/apache2/modules/mod_ssl.so
Or install the created apache2.2-bin deb package.
11. Apache now understands some new config directives. We do some
modifications on /etc/apache2/modules-enabled/ssl.conf:

Disabling SSLv2 (broken by design) and SSLv3 (vulnerable to the POODLE
attack)
TSLv1 has also some minor problems, but when we disable this we lock out
the stock browsers of Android up to 4.03

SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

Disabling Compression of the encrypted stream to prevent CRIME attack

SSLCompression Off

Tell tell the client we have a preferred order of algorithms to use:

SSLHonorCipherOrder On

Our preferred ciphers. At the end of the list disabling known to be weak
or already broken ciphers (starting with a !)
The AES128 ciphers are preferred because they are fast and quite robust
against timing attacks. This must give one line.

SSLCipherSuite
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES2
56-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

11. After restarting apache you can verify the patch at
https://weakdh.org/sysadmin.html
Now you should get instead a warning "Good News! This site uses strong
(2048-bit or better) key exchange parameters and is safe from the Logjam
attack."
Beside this now you should get an A rating at www.ssllabs.com/ssltest/
When you add HTTP Strict Transport Security with
Header always set Strict-Transport-Security "max-age=63072000;"
in your ssl vhost config you get an A+ rating.

Warning at the end: When apache2.2-bin is updated your mod_ssl.so will
be overwritten. As long there is no similar patch apache will then
refuse to start because it does not understand +TLSv1.1 +TLSv1.2. Then
copy simply back the compiled module. As long the minor release number
22 is not changing there should be no problem. Alternative you can edit
the file debian/changelog with dch -i and create your own release. apt
will then give a warning if you want to install a different one or
downgrading.
For security patches: You have to get then the source of the patched
versions, read the changelog and copy in the modified mod_ssl and
recompiling the entire server.
I was testing it with all fairly actual browsers I could get a hand on
without any problems.
If you face a problem with the 3072 bit then change:
else
        dh = get_dh3072();
    return dh;
around line 193 in ssl_engine_dh.c to
else
        dh = get_dh2048();
    return dh;

Andreas

[1] http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
[2] https://weakdh.org/imperfect-forward-secrecy.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.habari.co.tz/pipermail/linux/attachments/20150525/f6191dcc/attachment.pgp>