[ALUG] Logjam and Apache 2.2 in Ubuntu 12.04

Mon May 25 11:44:29 EAT 2015

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... :\

Regards,

Alan

On Mon, May 25, 2015 at 3:16 AM, Andreas Tauscher via Linux <
linux at lists.habari.co.tz> wrote:

> 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
>
>
> _______________________________________________
> The Arusha Linux User Group: http://unix.or.tz
> Linux mailing list
> Linux at lists.habari.co.tz
> http://lists.habari.co.tz/cgi-bin/mailman/listinfo/linux
>
> The Arusha LUG mailing list is generously hosted by Habari Node Ltd:
> http://www.habari.co.tz/
>
> 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.
>

-- 
Alan Orth
alan.orth at gmail.com
https://alaninkenya.org
https://mjanja.ch
"In heaven all the interesting people are missing." -Friedrich Nietzsche
GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.habari.co.tz/pipermail/linux/attachments/20150525/7a29fcbf/attachment-0001.html>