SSL/TLS changes in Apache

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

Hello development list,

sorry for dropping in here.

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:

(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.)

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.

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.

(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.

(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.

(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.


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

Best regards,
Peter Müller