From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@link38.eu>
To: development@lists.ipfire.org
Subject: Re: Apache Patches
Date: Wed, 04 Oct 2017 21:06:50 +0200
Message-ID: <20171004210650.4cc6d67f.peter.mueller@link38.eu>
In-Reply-To: <000b01d33c4a$4aa12e80$dfe38b80$@googlemail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3670789187909045380=="
List-Id: <development.lists.ipfire.org>

--===============3670789187909045380==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Wolfgang,

thanks for your feedback.

> Hi everyone,
>=20
> regarding the latest apache patches (sorry, I will discuss several patches =
in one mail):
>=20
> "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/=20
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. B=
ut actually,
this is a matter of opinion.
>=20
> 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-gen=
erate 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 d=
iscovered while searching for standard DH params that there exist other firew=
all 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 D=
H parameter,
which is exactly what Apache does. In both cases, you just search in the repo=
sitory 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 actua=
lly 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 b=
ecause 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 e=
lse). 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 encryptio=
n at all.

Speaking about DH, I think solving the security vulnerabilities is too extens=
ive. 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?".
>=20
> "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. Y=
ou can use
multiple keys by simply use a set of "SSLCertificateFile / SSLCertificateKeyF=
ile" directives.

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

@All: Does anybody who tested see the same issue?
>=20
> Another word to the "Require" statements from Apache. As you already notice=
d, they are ORed, if they are not in a RequireAll|Any|None block. To make thi=
s 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 configurati=
on.
ACKed.

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

Best regards,
Peter M=C3=BCller
>=20
> Best regards,
> Wolfgang
>=20



--===============3670789187909045380==--