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