<div dir="ltr"><div>Ouch, I only have one server running Apache 2.2 with TLS. All my other stuff is nginx (yay) or Apache 2.4+. My concern with manually compiling Apache is that you have to be on the watch for any new versions and patch manually... :\<br><br></div><div>Regards,<br></div><div><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 25, 2015 at 3:16 AM, Andreas Tauscher via Linux <span dir="ltr"><<a href="mailto:linux@lists.habari.co.tz" target="_blank">linux@lists.habari.co.tz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Logjam is an attack to decrypt recorded traffic after the switch over<br>
from asymmetric to symmetric encryption.<br>
<br>
My personal problem: ssl-labs craped the rating for my https server I am<br>
testing things down from A+ to B. This sucks.<br>
So I was working the last days on a solution to get again a A+ rating.<br>
Updating to Apache 2.4.7 or newer: Not a real solution for now. It is<br>
not a real drop in update. I have some tricky configurations for which I<br>
will need some time to adopt them to 2.4. So I decided to have a closer<br>
look on mod_ssl.<br>
<br>
A little bit a preamble what the problem is:<br>
<br>
When encrypting both sides need a common known secret. This is called<br>
symmetric encryption. Each party knows the secret key, can encrypt and<br>
decrypt with this key. As long there are only a few and each trusts each<br>
other this shared secret is fine. On the internet we have a problem: I<br>
can not create a unique one for each of my (maybe) visitors and when I<br>
share one key with everybody it is not longer a secret. And how do I<br>
share a key with somebody I even don't know?<br>
<br>
Here now comes asymmetric encryption: I have a private key which must be<br>
kept secret and an public key anybody can know. This public key is sent<br>
by the server together with the certificate when a client establishes a<br>
connection. With the public key you can only encrypt but not decrypt.<br>
With this asymmetric encryption client and server can now exchange a<br>
unique, temporary on the fly created and only for this connection used<br>
symmetric key.<br>
So why shifting over to a different encryption when we have already a<br>
encrypted connection? Symmetric encryption has one big advantage: It is<br>
faster and the keys are shorter.<br>
This direct key exchange now has another problem: If the secret key of<br>
the asymmetric encryption is leaked or the public key can be broken the<br>
communication can be decrypted afterwards.<br>
Here now comes Diffie-Hellman key exchange. [1]<br>
A really clever way to exchange secrets over insecure communication<br>
ways. The key is never communicated and out of the information the two<br>
parties exchanging about the key it can not be extracted - in theory.<br>
<br>
The logjam attack described detailed in the paper "Imperfect Forward<br>
Secrecy: How Diffie-Hellman Fails in Practice." [2] is addressing how to<br>
break this key exchange and extract the key.<br>
<br>
For now they broke 512 bit. With optimising they hope to be soon able to<br>
break also key exchange with 768 bit.<br>
The resources of this researchers are limited.<br>
Others having much bigger resources.<br>
And here now starts the real problem:<br>
Many servers are using the same DH parameters.<br>
This is now making it a serious problem. With the pre computed tables<br>
the recorded traffic of thousands of servers can be decrypted in a short<br>
time.<br>
This is now also making it interesting for criminals.<br>
Keep in mind that a bot net with several million infected PCs is a<br>
serious amount of computing power.<br>
<br>
At <a href="https://weakdh.org/logjam.html" target="_blank">https://weakdh.org/logjam.html</a> is also a video demonstrating how<br>
recorded traffic was decrypted.<br>
<br>
512 bit must any way be rated as broken. 768 bit will be broken soon and<br>
1024 bit have to rated as weak.<br>
Luckily the needed computing power to break the DH key exchange is<br>
increasing exponential.<br>
Upgrading to 2048 bit or more and having your own unique DH prime number<br>
will make it safe again.<br>
<br>
Some admins don't know what this parameter is and leave it default (if<br>
you read in a config something with seed, salt or dh- pay attention to<br>
it and change it!) or like in the case of Apache 2.2: DH was patched in<br>
later and there is no configuration option to change this parameters. It<br>
must be changed in the source code. As a result all Apache 2.2 binaries<br>
compiled form one source using the same prime number. And the maximum<br>
length of the DH parameters 2.2 is using is 1024 bit.<br>
With 2.4 a DH parameter can be attached to the certificate file but<br>
nearly nobody knows this so here also the (well known) default value<br>
from the sources is used.<br>
With 2.4.7 it can be configured individual and found it's way into the<br>
documentation. But often it is forgotten to create and so again a well<br>
known default is used.<br>
<br>
But as said in the beginning: Upgrading to 2.4 is for now not something<br>
I want to do.<br>
After doing some changes in mod_ssl I had DH parameters of 2048 and 3072<br>
bit. So far so good. Let's move on with some other enhacements.<br>
I also wanted better support for EC (elliptic curve) ciphers. EC ciphers<br>
having shorter keys. Shorter keys means less CPU cycles for<br>
encryption/decryption.<br>
In general good and really good for mobile devices. The cipher with the<br>
monstrous name TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is using a 256 bit<br>
key but offers the same security as plain RSA with a 3072 bit key.<br>
<br>
I found in 2.2.26 support for ECDH ciphers was added. Why have I not<br>
checked this before?<br>
Downloading the sources for 2.2.29 Adding 2048 and 3072bit. Building:<br>
The build exploded on many ends :(<br>
So I copied my modified mod_ssl into the 2.2.22 source tree of Ubuntu<br>
and: Build succeeded.<br>
But: The bloody module still used 1024 bit. Grrrr...... 2048 was in and<br>
when not asking for a specific length: 3072 bit are delivered. The<br>
problem is libssl Ubuntu 12.04 is using. It is not accepting DH<br>
parameters shorter than 768 bit but never asking for more than 1024 bit.<br>
So the module is working correct. libssl was explicit requesting 1024<br>
bit and the module returned 1024 bit.<br>
But for what libssl is asking what it is getting: Two different things.<br>
So I removed the anyway obsolete 512 bit and the 1024 bit completely.<br>
Now the module is returning always 3072 bit. libssl is not requesting<br>
1024 bit. It is requesting a key not shorter than 1024 bit. So there is<br>
no problem with returning longer keys.<br>
Just for curiosity I will test 8192 bit. openssl is still creating it.<br>
Running now since more than one day on a Xeon E5-2630..... How long will<br>
it need for 16384 bit? weeks? months? longer?<br>
<br>
Some changes in ssl.conf and beside now having a A+ rating again:<br>
Forward secrecy now working with all browsers supporting it somehow.<br>
<br>
If somebody wants to build this also here are the steps how to do it:<br>
<br>
Before you begin check at <a href="https://weakdh.org/sysadmin.html" target="_blank">https://weakdh.org/sysadmin.html</a> if your<br>
server is using short and common known DH parameters.<br>
<br>
1. Update your system: apt-get update && apt-get upgrade<br>
2. apt-get install indent build-essential dpkg-dev<br>
3. create a directory to build, cd there<br>
4. apt-get source apache2<br>
5. cd apache2.2/mod_ssl/<br>
6. Download the patched version:<br>
wget <a href="http://download.ict-pros.co.tz/mod_ssl-apache2.22.tar.bz2" target="_blank">http://download.ict-pros.co.tz/mod_ssl-apache2.22.tar.bz2</a> and<br>
unpack it: tar xfj mod_ssl-apache2.22.tar.bz2<br>
7. cd ssl and creating there new DH parameters: perl ./ssl_engine_dh.c<br>
This will take some time!<br>
8. Return to the root of the source directory and build the packages:<br>
dpkg-buildpackage -b -us<br>
9. After a (hopefully) successful build you will find the new deb<br>
packages one directory above. Otherwise install the missing packages.<br>
10. You can now copy direct the created module from<br>
debian/apache2.2-bin/usr/lib/apache2/modules/mod_ssl.so to<br>
/usr/lib/apache2/modules/mod_ssl.so<br>
Or install the created apache2.2-bin deb package.<br>
11. Apache now understands some new config directives. We do some<br>
modifications on /etc/apache2/modules-enabled/ssl.conf:<br>
<br>
Disabling SSLv2 (broken by design) and SSLv3 (vulnerable to the POODLE<br>
attack)<br>
TSLv1 has also some minor problems, but when we disable this we lock out<br>
the stock browsers of Android up to 4.03<br>
<br>
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2<br>
<br>
Disabling Compression of the encrypted stream to prevent CRIME attack<br>
<br>
SSLCompression Off<br>
<br>
Tell tell the client we have a preferred order of algorithms to use:<br>
<br>
SSLHonorCipherOrder On<br>
<br>
Our preferred ciphers. At the end of the list disabling known to be weak<br>
or already broken ciphers (starting with a !)<br>
The AES128 ciphers are preferred because they are fast and quite robust<br>
against timing attacks. This must give one line.<br>
<br>
SSLCipherSuite<br>
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<br>
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<br>
<br>
11. After restarting apache you can verify the patch at<br>
<a href="https://weakdh.org/sysadmin.html" target="_blank">https://weakdh.org/sysadmin.html</a><br>
Now you should get instead a warning "Good News! This site uses strong<br>
(2048-bit or better) key exchange parameters and is safe from the Logjam<br>
attack."<br>
Beside this now you should get an A rating at <a href="http://www.ssllabs.com/ssltest/" target="_blank">www.ssllabs.com/ssltest/</a><br>
When you add HTTP Strict Transport Security with<br>
Header always set Strict-Transport-Security "max-age=63072000;"<br>
in your ssl vhost config you get an A+ rating.<br>
<br>
Warning at the end: When apache2.2-bin is updated your mod_ssl.so will<br>
be overwritten. As long there is no similar patch apache will then<br>
refuse to start because it does not understand +TLSv1.1 +TLSv1.2. Then<br>
copy simply back the compiled module. As long the minor release number<br>
22 is not changing there should be no problem. Alternative you can edit<br>
the file debian/changelog with dch -i and create your own release. apt<br>
will then give a warning if you want to install a different one or<br>
downgrading.<br>
For security patches: You have to get then the source of the patched<br>
versions, read the changelog and copy in the modified mod_ssl and<br>
recompiling the entire server.<br>
I was testing it with all fairly actual browsers I could get a hand on<br>
without any problems.<br>
If you face a problem with the 3072 bit then change:<br>
else<br>
        dh = get_dh3072();<br>
    return dh;<br>
around line 193 in ssl_engine_dh.c to<br>
else<br>
        dh = get_dh2048();<br>
    return dh;<br>
<br>
Andreas<br>
<br>
[1] <a href="http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange" target="_blank">http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange</a><br>
[2] <a href="https://weakdh.org/imperfect-forward-secrecy.pdf" target="_blank">https://weakdh.org/imperfect-forward-secrecy.pdf</a><br>
<br>
<br>_______________________________________________<br>
The Arusha Linux User Group: <a href="http://unix.or.tz" target="_blank">http://unix.or.tz</a><br>
Linux mailing list<br>
<a href="mailto:Linux@lists.habari.co.tz">Linux@lists.habari.co.tz</a><br>
<a href="http://lists.habari.co.tz/cgi-bin/mailman/listinfo/linux" target="_blank">http://lists.habari.co.tz/cgi-bin/mailman/listinfo/linux</a><br>
<br>
The Arusha LUG mailing list is generously hosted by Habari Node Ltd: <a href="http://www.habari.co.tz/" target="_blank">http://www.habari.co.tz/</a><br>
<br>
The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Alan Orth<br><a href="mailto:alan.orth@gmail.com" target="_blank">alan.orth@gmail.com</a><br><a href="https://alaninkenya.org" target="_blank">https://alaninkenya.org</a><br><a href="https://mjanja.ch" target="_blank">https://mjanja.ch</a><br>"In heaven all the interesting people are missing." -Friedrich Nietzsche<div>GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0<br></div></div></div>
</div>