Re: SSL/TLS changes in Apache

Re: SSL/TLS changes in Apache

[Peter Müller]

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

Hello Michael,

thanks for the reply.

> 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?
As far as I know, the following operating systems or web browsers
do not support ECDHE:
- Android 2.3.7 [will fall back to TLS_RSA_WITH_AES_128_CBC_SHA]
- IE 6 and 8 on XP systems [SSL connection will fail, but does so 
anyway since there is no support for AES]
- Java 6u45 [will fall back to TLS_RSA_WITH_AES_128_CBC_SHA]
- OpenSSL 0.9.8y [will fall back to TLS_RSA_WITH_AES_256_CBC_SHA]

So, most legacy SSL/TLS client will continue working, but fall
back on cipher suites with no PFS (perfect forward secrecy). The
IEs will fail to connect, but there is no difference since this
happens currently, too.

I consider it safe to turn off DH suites.
> 
> > 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.
Unfortunately I have no spare system to test (and don't know how to
apply the changes, see below). Hopefully this will change in the future. :-(
> 
> Generating big keys is taking not only 20 minutes. We ran some
> benchmarks and came close to 12 hours on some systems.
Oh yes, this is an extremely time-consuming procedure.
> 
> > (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
> 
All right, I was not aware of this.
> > (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.
How do I do this? I could neither find any remote branch like "apache-2.4.x" on
the git server nor contains the LFS file in origin/next the new apache version.

Apart from that: Patch is on the way.
> 
> > (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.
Okay, patch is in development. But it might take a while since I am
not familiar with IPFire's internal structure on git, yet.
> 
> 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.
As far as I know, the following operating systems or web browsers do not
support ECDSA:
- Android <= 4.1.1
- IE 8 on XP systems
- Chrome 49 on XP systems with SP3
- Java <= 7u35
- OpenSSL <= 0.9.8
- Safari <= 8
- Bing Preview 2015 [search engine bot]

Some of them are certainly legacy clients (you mentioned the XP issue above),
and the others usually do not appear in internal networks (Bots, ...). Thereof
I think it is safe to set up dual-stack RSA and ECDSA certificate.

If someone really still uses these systems, they will quietly fall back to RSA.
> 
> So with what does this leave us then?
> 
To put it short: Use modern browsers.

In real life, I do not expect big changes. Since every web site ran by
someone with a good reputation has disabled old and broken ciphers such as
RC4, clients like IE 6 are practically unusable. Users have probably switched
to modern software before the SSL settings for IPFire are changed.
> > 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.
Me too. :-)

Best regards,
Peter Müller
> 
> 
> Best,
> -Michael
> 
> > 
> > Best regards,
> > Peter Müller  

Re: SSL/TLS changes in Apache

[Michael Tremer]

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

Hi,

On Sat, 2017-09-02 at 13:54 +0200, Peter Müller wrote:
> Hello Michael,
> 
> thanks for the reply.
> 
> > 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?
> 
> As far as I know, the following operating systems or web browsers
> do not support ECDHE:
> - Android 2.3.7 [will fall back to TLS_RSA_WITH_AES_128_CBC_SHA]
> - IE 6 and 8 on XP systems [SSL connection will fail, but does so 
> anyway since there is no support for AES]
> - Java 6u45 [will fall back to TLS_RSA_WITH_AES_128_CBC_SHA]
> - OpenSSL 0.9.8y [will fall back to TLS_RSA_WITH_AES_256_CBC_SHA]
> 
> So, most legacy SSL/TLS client will continue working, but fall
> back on cipher suites with no PFS (perfect forward secrecy). The
> IEs will fail to connect, but there is no difference since this
> happens currently, too.

I think I could easily live with this. Any further comments from
anyone?

> 
> I consider it safe to turn off DH suites.
> > 
> > > 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.
> 
> Unfortunately I have no spare system to test (and don't know how to
> apply the changes, see below). Hopefully this will change in the future. :-(

Just use a VM. That should do for testing.

> > 
> > Generating big keys is taking not only 20 minutes. We ran some
> > benchmarks and came close to 12 hours on some systems.
> 
> Oh yes, this is an extremely time-consuming procedure.
> > 
> > > (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
> > 
> 
> All right, I was not aware of this.
> > > (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.
> 
> How do I do this? I could neither find any remote branch like "apache-2.4.x" on
> the git server nor contains the LFS file in origin/next the new apache version.

I just merged the apache update in the "next" branch. So please use
that one for any patches.

I think we will keep the merge window open for another week and then we
will close it, build the update and make it available for testing.

> Apart from that: Patch is on the way.
> > 
> > > (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.
> 
> Okay, patch is in development. But it might take a while since I am
> not familiar with IPFire's internal structure on git, yet.

Please ask any questions that you have.

> > 
> > 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.
> 
> As far as I know, the following operating systems or web browsers do not
> support ECDSA:
> - Android <= 4.1.1
> - IE 8 on XP systems
> - Chrome 49 on XP systems with SP3
> - Java <= 7u35
> - OpenSSL <= 0.9.8
> - Safari <= 8
> - Bing Preview 2015 [search engine bot]
> 
> Some of them are certainly legacy clients (you mentioned the XP issue above),
> and the others usually do not appear in internal networks (Bots, ...). Thereof
> I think it is safe to set up dual-stack RSA and ECDSA certificate.
> 
> If someone really still uses these systems, they will quietly fall back to RSA.

This is a bit different than the list from above.

However, we do not deliver any updates from the update accelarator over
HTTPS from our apache. Neither the proxy configuration.

So I think this is fine too and we should rather be too progressive
than too late.

It just doesn't feel too much of an advantage when clients still fall
back to RSA if they don't support it. But nevertheless I am in favour.
So please send patches.

> > 
> > So with what does this leave us then?
> > 
> 
> To put it short: Use modern browsers.
> 
> In real life, I do not expect big changes. Since every web site ran by
> someone with a good reputation has disabled old and broken ciphers such as
> RC4, clients like IE 6 are practically unusable. Users have probably switched
> to modern software before the SSL settings for IPFire are changed.
> > > 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.
> 
> Me too. :-)

Cool.

Best,
-Michael

> 
> Best regards,
> Peter Müller
> > 
> > 
> > Best,
> > -Michael
> > 
> > > 
> > > Best regards,
> > > Peter Müller  
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

SSL/TLS changes in Apache

[Peter Müller]

[-- 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