From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Apolinarski To: development@lists.ipfire.org Subject: AW: Apache Patches Date: Wed, 04 Oct 2017 21:59:22 +0200 Message-ID: <003201d33d4b$47922d00$d6b68700$@ipfire.org> In-Reply-To: <20171004210650.4cc6d67f.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5763050396497664699==" List-Id: --===============5763050396497664699== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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, lik= e 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. >=20 > 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 br= ainware is superior to the Mozilla project? I think it might make sense to ad= here to standards in this case, if possible. > > It could make sense to still support DHE parameters, since they provide P= FS - 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. >=20 > 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 act= ually 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 stil= l better than not using any PFS. I would suggest first ECDHE ciphers, then DH= E ciphers, then plain ciphers (no PFS). > Third, there is a difference between TLS on web sites and TLS on mail serve= rs. 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 scenar= ios that make sense to me: > > Either we use strong and reliable encryption - or we do not use any encrypt= ion at all. >=20 > Speaking about DH, I think solving the security vulnerabilities is too exte= nsive. 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 t= o create ciphers. Creating a collision here is by no means easy. These kind o= f defined groups are used all over the world in VPN and IPSEC connections tha= t are considered secure. In general, I think we agree that we should move to ECDHE. But the cipher str= ength is ECDHE > DHE > No PFS. This is why I think that shipping a standard D= H 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 ipfir= e systems which is somehow similar to shipping a DH 2048 parameter with ipfir= e (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, t= he 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. >=20 > Only "SSLCertificateChainFile" cannot be defined multiple times - but we do= not use it on IPFire, anyway. >=20 > @All: Does anybody who tested see the same issue? Ah, I don't have the book, but the documentation confirms your claim: "The di= rective can be used multiple times (...)", this is why I wrote "I think". ;-) Also, the documentation suggests ordering the directives: https://httpd.apach= e.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile > > > > Another word to the "Require" statements from Apache. As you already noti= ced, they are ORed, if they are not in a > RequireAll|Any|None block. To make this behavior transparent, I would sugge= st 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. >=20 > (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 --===============5763050396497664699==--