[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfire-development
Subject:    Re: SSL/TLS changes in Apache
From:       Michael Tremer <michael.tremer () ipfire ! org>
Date:       2017-08-31 15:24:35
Message-ID: 1504193075.2584.45.camel () ipfire ! org
[Download RAW message or body]


Hello Peter,

On Tue, 2017-08-29 at 16:23 +0200, Peter Müller wrote:
> Hello development list,
> 
> sorry for dropping in here.

That is what that list is for. Welcome!

> Because I am an absolute newbie, I guess it might
> be better to explain major changes before I submit
> them in a patch.
> 
> The first section affected by this the SSL/TLS
> configuration used by Apache. As far as I am concerned,
> there are these issues at the moment:

There are a few emails here on this list from maybe a year ago or even
longer. We discussed it a few times what would be best to use and one
very commonly occurring obstacle is performance on some systems.

In particular these are the smallest embedded systems that take hours
to generate keys of a good length although that would be no problem at
all for a decent system.

Keep that in mind for my comments below.

> (a) DH cipher suites
> Because of several reasons, I would like to see them
> disabled. First, they are more or less obsolete since
> all modern User Agents (i.e. Web Browsers) does not
> support them, they mostly use ECDHE instead. (Note that
> this is valid for web sites only; other type of servers
> - especially mail servers - are often maintained very
> badly and therefore do not support anything better.)

Last time we had this conversation, we were not sure.

Do you have any evidence?

> Second, DH is much slower and needs more CPU time on
> both server and client than ECDHE. While this not a
> problem on up-to-date hardware, it might be an issue
> for older systems.

CPU time is not a big problem here, but it is true, that ECDHE is
faster.

> Third, DH is vulnerable to LOGJAM, which is the most
> important reason to disable it. Fixing LOGJAM is not
> that easy since it would require
> 	i) Apache 2.4.x, which seems to be in development
> 	since some patches appeared here the other day
> 	ii) an individually created DH prime file, which
> 	takes usually more than 20 minutes and requires
> 	a huge amount of CPU time.
> So, disabling the DH cipher suites would be a relatively
> simple workaround.

Yes, we are probably going to merge the apache update for core update
114. However, nobody else has given feedback on the patches, yet, which
is really not good for such a huge change.

Generating big keys is taking not only 20 minutes. We ran some
benchmarks and came close to 12 hours on some systems.

> (b) Cipher strength 
> Currently, AES128 is preferred over AES265 nearly all the
> time. Since I do not see any reason for this, I would
> suggest to order them by strength.

This is intentional since some researchers are convinced that AES256 is
more likely to suffer from timing attacks.

I cannot find the specific article right now, but it should be either
in the commit logs or in the emails on this list.

There is loads of articles on his blog on attacks on AES, like this
one:

https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html

> (c) Unused ciphers
> Further, there are many unused cipher suites listed (such
> as SRP, DSS and PSK) which are not supported by any
> modern browser - and probably never will. Thereof it might
> make sense to remove them, since they cause the cipherlist
> to be quite complex and hard to understand.

Agreed.

You can send a patch right away on this.

Please base them on the apache 2.4 branch.

> (d) Certificate dual-stack
> At the first boot, IPFire generates an RSA host key for
> Apache with a size of 4096 bits.
> 
> However, there is another key exchange algorithm, called
> ECDSA. It has several advantages over RSA:
> 	i) Compared by key size, it is more secure. An
> 	ECDSA key with 256 bits provides the same strength
> 	as a RSA key with 3072 bits.
> 	ii) Key generation is much faster (384 bits should
> 	be sufficient for most applications, it equals about
> 	9216 bits RSA). Especially on slower hardware or
> 	systems without a HWRNG, this will accelerate the first
> 	boot.
> 	iii) It needs less CPU resources on both server and
> 	client than RSA. Again, this might be relevant for
> 	systems running on legacy hardware.
> Since ECDSA and RSA can be used parallel (clients that do not
> understand one key exchange algorithm use the other), I
> suggest to generate an ECDSA key, too. Most modern User Agents
> even prefer it over RSA.

That sounds good. Let's add it then.

What systems do not support this, yet? I do not care if Windows XP and
even Vista is working any more. We cannot sacrifice the security of the
IPFire systems just because someone could still be using a very
outdated OS somewhere. Those people need to upgrade or find another
device to manage their IPFire box then.

So with what does this leave us then?

> What do you think of those? (If I made a mistake somewhere
> - now or in the future -, I would be frightfully grateful for
> feedback. :-) )

I am really happy to continue this conversation and improve the
security of IPFire together with you.


Best,
-Michael

> 
> Best regards,
> Peter Müller
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]