Apache Patches

Apache Patches

[Wolfgang Apolinarski]

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

Hi everyone,

regarding the latest apache patches (sorry, I will discuss several patches in one mail):

"disable obsolete and unused ciphers in Apache SSL configuration"
This looks good to me, but why don't we use a standard configuration, like the one that the Mozilla SSL Configuration Generator outputs (or maybe build on that)?
https://mozilla.github.io/server-side-tls/ssl-config-generator/ 

It could make sense to still support DHE parameters, since they provide PFS - in contrast to the "normal" AES128-GCM-SHA256 parameters. We could pre-generate a 2048 bit DH param and use that, if the user is not re-generating it. This is still a lot better than using the standard Apache DH params. I also discovered while searching for standard DH params that there exist other firewall distributions that do it exactly this way.

"add ECDSA certificate and key files to Apache configuration"
I think that if we add "SSLCertificateFile" twice to the configuration, the first one will just be overwritten. So in this case, the server.crt|key are not used at all.

Another word to the "Require" statements from Apache. As you already noticed, they are ORed, if they are not in a RequireAll|Any|None block. To make this behavior transparent, I would suggest to always use the RequireX block and don't rely on the default (RequireAny->OR), if possible. This is just a note to everyone that updates/creates access control within the Apache configuration.

Best regards,
Wolfgang

Re: Apache Patches

[Michael Tremer]

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

Hi,

On Tue, 2017-10-03 at 15:19 +0200, Wolfgang Apolinarski wrote:
> Hi everyone,
> 
> regarding the latest apache patches (sorry, I will discuss several patches in
> one mail):

Yes, this is indeed not a good idea. I do not understand very well what you are
referring to sometimes. So it would have been better to reply to the original
email and quote that part you are referring too. Leads to more emails, but is
easier to read.

-Michael

> 
> "disable obsolete and unused ciphers in Apache SSL configuration"
> This looks good to me, but why don't we use a standard configuration, like the
> one that the Mozilla SSL Configuration Generator outputs (or maybe build on
> that)?
> https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
> 
> It could make sense to still support DHE parameters, since they provide PFS -
> in contrast to the "normal" AES128-GCM-SHA256 parameters. We could pre-
> generate a 2048 bit DH param and use that, if the user is not re-generating
> it. This is still a lot better than using the standard Apache DH params. I
> also discovered while searching for standard DH params that there exist other
> firewall distributions that do it exactly this way.
> 
> "add ECDSA certificate and key files to Apache configuration"
> I think that if we add "SSLCertificateFile" twice to the configuration, the
> first one will just be overwritten. So in this case, the server.crt|key are
> not used at all.
> 
> Another word to the "Require" statements from Apache. As you already noticed,
> they are ORed, if they are not in a RequireAll|Any|None block. To make this
> behavior transparent, I would suggest to always use the RequireX block and
> don't rely on the default (RequireAny->OR), if possible. This is just a note
> to everyone that updates/creates access control within the Apache
> configuration.
> 
> Best regards,
> Wolfgang
> 

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

Re: Apache Patches

[Peter Müller]

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

Hello Wolfgang,

thanks for your feedback.

> Hi everyone,
> 
> regarding the latest apache patches (sorry, I will discuss several patches in one mail):
> 
> "disable obsolete and unused ciphers in Apache SSL configuration"
> This looks good to me, but why don't we use a standard configuration, like the one that the Mozilla SSL Configuration Generator outputs (or maybe build on that)?
> https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
Well, this is mainly because of the DH issue (see below). Further, I am not a big fan
of standardised SSL cipher configurations, since most people tend to do just copy & paste
- sometimes even including some security issues.

If you build your cipherlist from scratch, there is more "brainware" in it. But actually,
this is a matter of opinion.
> 
> It could make sense to still support DHE parameters, since they provide PFS - in contrast to the "normal" AES128-GCM-SHA256 parameters. We could pre-generate a 2048 bit DH param and use that, if the user is not re-generating it. This is still a lot better than using the standard Apache DH params. I also discovered while searching for standard DH params that there exist other firewall distributions that do it exactly this way.
I disagree with you.

First, it is a crutch and not a fix - every installation would use the same DH parameter,
which is exactly what Apache does. In both cases, you just search in the repository and
extract the file (or let it be hard-coded in source).

A standard DH parameter is simply not a solution, since this is what we actually have
right now - with 1024 bits, of course, but the issue stays the same.

Second, we actually do not need DH anymore. Every modern browser uses ECDHE because of
speed issues, and there are only a few (ancient) user agents which would fall back to
non-PFS ciphers.

Third, there is a difference between TLS on web sites and TLS on mail servers. If we
ran a MX, I'd agree with you (opportunistic TLS, I mentioned that somewhere else). But
on web sites, there are only two scenarios that make sense to me:

Either we use strong and reliable encryption - or we do not use any encryption at all.

Speaking about DH, I think solving the security vulnerabilities is too extensive. If we
use standardised DH params, the problem stays the same. If we generate it on each system,
we will experience users asking "Why is my load average hitting the roof for > 30 minutes?".
> 
> "add ECDSA certificate and key files to Apache configuration"
> I think that if we add "SSLCertificateFile" twice to the configuration, the first one will just be overwritten. So in this case, the server.crt|key are not used at all.
According to Ivan Ristic, "Bulletproof SSL and TLS", p. 386, this is wrong. You can use
multiple keys by simply use a set of "SSLCertificateFile / SSLCertificateKeyFile" directives.

Only "SSLCertificateChainFile" cannot be defined multiple times - but we do not use it
on IPFire, anyway.

@All: Does anybody who tested see the same issue?
> 
> Another word to the "Require" statements from Apache. As you already noticed, they are ORed, if they are not in a RequireAll|Any|None block. To make this behavior transparent, I would suggest to always use the RequireX block and don't rely on the default (RequireAny->OR), if possible. This is just a note to everyone that updates/creates access control within the Apache configuration.
ACKed.

(Using OR as a default is quite strange in my eyes, but what the hey!)

Best regards,
Peter Müller
> 
> Best regards,
> Wolfgang
> 

AW: Apache Patches

[Wolfgang Apolinarski]

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

Hi Peter,

> >
> > "disable obsolete and unused ciphers in Apache SSL configuration"
> > This looks good to me, but why don't we use a standard configuration, like the one that the Mozilla SSL Configuration Generator
> outputs (or maybe build on that)?
> > https://mozilla.github.io/server-side-tls/ssl-config-generator/
> Well, this is mainly because of the DH issue (see below). Further, I am not a big fan of standardised SSL cipher configurations, since
> most people tend to do just copy & paste
> - sometimes even including some security issues.
> 
> If you build your cipherlist from scratch, there is more "brainware" in it. But actually, this is a matter of opinion.

There might be more "brainware" in it, but are you actually sure that your brainware is superior to the Mozilla project? I think it might make sense to adhere to standards in this case, if possible.

> > It could make sense to still support DHE parameters, since they provide PFS - in contrast to the "normal" AES128-GCM-SHA256
> parameters. We could pre-generate a 2048 bit DH param and use that, if the user is not re-generating it. This is still a lot better than
> using the standard Apache DH params. I also discovered while searching for standard DH params that there exist other firewall
> distributions that do it exactly this way.
> I disagree with you.
> 
> First, it is a crutch and not a fix - every installation would use the same DH parameter, which is exactly what Apache does. In both
> cases, you just search in the repository and extract the file (or let it be hard-coded in source).
>
> A standard DH parameter is simply not a solution, since this is what we actually have right now - with 1024 bits, of course, but the issue
> stays the same.

It is not exactly the same as Apache since Apache was using a (now considered small) 1024 bit DH parameter for years. We would use a 2048 bit DH parameter that would be only in use for Ipfire (smaller attack vector) and could also change it, for example every year.

> Second, we actually do not need DH anymore. Every modern browser uses ECDHE because of speed issues, and there are only a few
> (ancient) user agents which would fall back to non-PFS ciphers.

I agree that we should use ECDHE over DHE, but a PFS cipher using DHE is still better than not using any PFS. I would suggest first ECDHE ciphers, then DHE ciphers, then plain ciphers (no PFS).

> Third, there is a difference between TLS on web sites and TLS on mail servers. If we ran a MX, I'd agree with you (opportunistic TLS, I
> mentioned that somewhere else). But on web sites, there are only two scenarios that make sense to me:
>
> Either we use strong and reliable encryption - or we do not use any encryption at all.
> 
> Speaking about DH, I think solving the security vulnerabilities is too extensive. If we use standardised DH params, the problem stays
> the same. If we generate it on each system, we will experience users asking "Why is my load average hitting the roof for > 30
> minutes?".

DHE is not insecure per se. The parameters define only the set that is used to create ciphers. Creating a collision here is by no means easy. These kind of defined groups are used all over the world in VPN and IPSEC connections that are considered secure.
In general, I think we agree that we should move to ECDHE. But the cipher strength is ECDHE > DHE > No PFS. This is why I think that shipping a standard DH 2048 parameter increases the security for everyone that is not yet able to use ECDHE. Also, for ECDHE, Apache will be using standard curves on all ipfire systems which is somehow similar to shipping a DH 2048 parameter with ipfire (or alternatively, using Apache's standard DH parameters for DHE).

> >
> > "add ECDSA certificate and key files to Apache configuration"
> > I think that if we add "SSLCertificateFile" twice to the configuration, the first one will just be overwritten. So in this case, the
> server.crt|key are not used at all.
> According to Ivan Ristic, "Bulletproof SSL and TLS", p. 386, this is wrong. You can use multiple keys by simply use a set of
> "SSLCertificateFile / SSLCertificateKeyFile" directives.
> 
> Only "SSLCertificateChainFile" cannot be defined multiple times - but we do not use it on IPFire, anyway.
> 
> @All: Does anybody who tested see the same issue?

Ah, I don't have the book, but the documentation confirms your claim: "The directive can be used multiple times (...)", this is why I wrote "I think". ;-)
Also, the documentation suggests ordering the directives: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile

> >
> > Another word to the "Require" statements from Apache. As you already noticed, they are ORed, if they are not in a
> RequireAll|Any|None block. To make this behavior transparent, I would suggest to always use the RequireX block and don't rely on
> the default (RequireAny->OR), if possible. This is just a note to everyone that updates/creates access control within the Apache
> configuration.
> ACKed.
> 
> (Using OR as a default is quite strange in my eyes, but what the hey!)

Yes, I assume it always has been the default - so this is why...

Best regards,
Wolfgang Apolinarski