From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: CA and HTTPS usage on *.ipfire.org
Date: Mon, 29 Jan 2018 12:14:09 +0000
Message-ID: <1517228049.2586.42.camel@ipfire.org>
In-Reply-To: <1509115453.4838.221.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8760687507310878863=="
List-Id: <development.lists.ipfire.org>

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

First regression! That was a long time, but someone found something:

iPXE does TLS1.2, but no PFS. Doesn't seem to be implemented at all.

  https://forum.ipfire.org/viewtopic.php?f=3D5&t=3D20232&p=3D113946#p113946

I enabled "AES256-SHA256" for the moment to get it working again, but I suppo=
se
that is not a permanent solution.

What do you guys think about allowing non-PFS cipher suites on
downloads.ipfire.org, boot.ipfire.org and mirror1.ipfire.org?

-Michael

On Fri, 2017-10-27 at 15:44 +0100, Michael Tremer wrote:
> Hi,
>=20
> On Thu, 2017-10-26 at 21:24 +0200, Peter M=C3=BCller wrote:
> > Hello Michael,
> >=20
> > > Thanks for the input. Let's go through it bit by bit...
> > >=20
> > > On Wed, 2017-10-25 at 22:12 +0200, Peter M=C3=BCller wrote:
> > > > Hello Michael,
> > > >  =20
> > > > > Hello altogether,
> > > > >=20
> > > > > to bring some movement into this I went ahead and installed Let's
> > > > > Encrypt
> > > > > certificates pretty much everywhere (with exception of the internal
> > > > > services
> > > > > like LDAP).
> > > > >=20
> > > > > There you have it. I did it. I bit the bullet. =20
> > > >=20
> > > > Thank you very much. :-) I really appreciate this. =20
> > > > >=20
> > > > > It literally took me days since we have so many subdomains and I
> > > > > issued
> > > > > one
> > > > > certificate per domain which makes it easier to renew and revoke th=
em
> > > > > if
> > > > > needed.
> > > > > They also throttled me to only issue a small number of certificates
> > > > > per
> > > > > week.
> > > > >=20
> > > > > But in summary these things have changed (I would like to get some
> > > > > feedback
> > > > > from
> > > > > you since you all have probably a little bit more experience with a
> > > > > few
> > > > > things
> > > > > than I have):
> > > > >=20
> > > > > * LE deployed for all web services with the exception of
> > > > > boot.ipfire.org
> > > > > and
> > > > > fireinfo.
> > > > >=20
> > > > > iPXE doesn't really support HTTPS that well and I shipped a new
> > > > > version
> > > > > of
> > > > > it
> > > > > that at least downloads some certificates (although it cannot really
> > > > > validate
> > > > > them - it can only check than a CA exists I think). =20
> > > >=20
> > > > Hmmm, that is not very good - of course, everything is better than
> > > > plaintext,
> > > > but without validating the certificates...
> > > >=20
> > > > How widely is iPXE used? =20
> > >=20
> > > Loads of people use it. Probably every VM runs it :)
> > >=20
> > > I enabled this: http://ipxe.org/cfg/crosscert
> > >=20
> > > https://cgit.ipfire.org/oddments/ipfire-netboot.git/commit/?id=3D871fc3=
184ad
> > > 5e
> > > ce1633833f169e771629306ed94
> > >=20
> > > I just found out that is has cross-signed all CAs in that folder with
> > > their
> > > own
> > > CA that is baked into the image, so they can verify if the CA they
> > > downloaded is
> > > actually trusted or not. It's not perfect, but I think it is good enoug=
h.
> > >=20
> > > It is possible to bake in a CA into the image, but I didn't want to set=
 it
> > > to LE
> > > and nothing else and there is not enough space in the image to import t=
he
> > > usual
> > > CA bundle. I think the final image cannot be larger than 1M and the
> > > current
> > > IPFire CA bundle that we ship is about 700k.
> >=20
> > That is another item on my list: To check the certificate bundle and throw
> > out
> > outdated and suspicious - such as BlueCoat, CINNIC, etc. - ones. But this
> > requires
> > some spare time, which I lack at the moment. :-)
>=20
> We get it from Mozilla but it hasn't been updated in quite some time now. We
> probably need to do a better job with it and if you would put yourself forw=
ard
> as a maintainer that would be amazing.
>=20
> However, going through this is probably not going to let you sleep well. Th=
ere
> is scary stuff in it, but I do not see that it makes sense to filter this o=
ut
> manually. The chance to miss something is too high.
>=20
> But if you have good ideas, let's talk about them...
>=20
> > >=20
> > > http://ipxe.org/crypto
> > >=20
> > > > >=20
> > > > > Same with fireinfo. I have no idea if the profiles can be sent
> > > > > properly
> > > > > over
> > > > > HTTPS without touching the client first. =20
> > > >=20
> > > > I guess we need to implement that in the clients first. At the moment=
 I
> > > > am
> > > > quite
> > > > busy reworking some broken patches and other stuff, but will have a l=
ook
> > > > at
> > > > that
> > > > occasionally. =20
> > >=20
> > > That would be cool. It uses the standard python urllib2 module which
> > > supports
> > > SSL. I am just not sure if it would follow the redirect properly. Needs
> > > some
> > > testing.
> > >=20
> > > https://cgit.ipfire.org/oddments/fireinfo.git/tree/src/sendprofile
> > >=20
> > > > Using HTTPS on fireinfo an mirrors might be a good idea since a (even
> > > > passive)
> > > > attacker can see a lot of information by simply looking at the network
> > > > traffic
> > > > (Which version is the firewall running? Which architecture and network
> > > > zones
> > > > are in use? And so on.) =20
> > >=20
> > > Our default mirror only supports HTTPS from now on and will redirect.
> > > However,
> > > the load-balancer will only redirect to HTTP which will then redirect to
> > > HTTPS.
> > > That's not ideal.
> > >=20
> > > I need to add this here:
> > >   https://cgit.ipfire.org/ipfire.org.git/tree/webapp/backend/mirrors.py=
#n4
> > > 18
> > >=20
> > > It's very easy just to flag in the database which mirrors support HTTPS.
> > > But
> > > there will always be a chance that a client is redirected to a mirror t=
hat
> > > only
> > > supports HTTP.
> >=20
> > Maybe the mirror hosters change this if we notify them. (Side question: W=
hat
> > does
> > the '*' at https://mirrors.ipfire.org/ mean? It seems to be somewhat
> > random...)
>=20
> It means that you will be redirected to one of those mirrors. They are "clo=
se"
> to you according to your GeoIP location.
>=20
> Probably this needs some updating since it is quite slow. The Pakfire Build
> Service uses a better and quite simple approach which seems to work well.
>=20
> > We could also ship a pakfire mirror list with information about the HTTPS
> > state
> > of a mirror - and prevent the firewalls being redirected to plaintext if a
> > mirror
> > supports HTTPS.
>=20
> Yes, if you dare to touch the old Pakfire :)
>=20
> > >=20
> > > I already did this for the Pakfire Build Service:
> > >   https://cgit.ipfire.org/pbs.git/commit/?id=3D3163c789758423fad6133599=
5b206
> > > e5
> > > af3a25f4f
> > >=20
> > > > Just as a side note: Validating this traffic against DANE records wou=
ld
> > > > be
> > > > nice. :-) =20
> > >=20
> > > Oh I forgot to say that we have TLSA records for everything in here.
> > > Probably
> > > nobody validates this, but hey :)
> >=20
> > Well, there is a browser plugin for FF, which crashes surprisingly seldom=
 on
> > my
> > machine. :-)
>=20
> I used to use that, but just the icon doesn't really help much. And for
> stability and performance of my system I uninstalled this some time ago.
>=20
> > >=20
> > > [root(a)mail01 ~]# dig TLSA _443._tcp.www.ipfire.org
> > >=20
> > > ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-2.P3.fc26 <<>> TLSA _443._tcp.www.ip=
fir
> > > e.
> > > org
> > > ;; global options: +cmd
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41901
> > > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> > >=20
> > > ;; OPT PSEUDOSECTION:
> > > ; EDNS: version: 0, flags:; udp: 4096
> > > ;; QUESTION SECTION:
> > > ;_443._tcp.www.ipfire.org.      IN      TLSA
> > >=20
> > > ;; ANSWER SECTION:
> > > _443._tcp.www.ipfire.org. 21599
> > > IN      CNAME   _letsencrypt.certs.ipfire.org.
> > > _letsencrypt.certs.ipfire.org. 21599 IN TLSA    2 1 1
> > > 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18
> > >=20
> > > ;; Query time: 99 msec
> > > ;; SERVER: 172.28.1.1#53(172.28.1.1)
> > > ;; WHEN: Thu Oct 26 12:11:06 CEST 2017
> > > ;; MSG SIZE  rcvd: 133
> > >=20
> > > > >=20
> > > > > * LE deployed on mail01.i.ipfire.org (Postfix + Dovecot) =20
> > > >=20
> > > > Yep, seems to work.
> > > >=20
> > > > However, a client certificate in Postfix is still missing:
> > > >=20
> > > > Received: from mail01.ipfire.org (mail01.ipfire.org [81.3.27.42])
> > > > 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
> > > > bits)) =20
> > > > -->	(Client did not present a certificate) <-- =20
> > > > 	[etc.]
> > > >=20
> > > > In your main.cf, it can be enabled by using:
> > > >=20
> > > > smtp_tls_cert_file =3D /Path/to/your/certificate
> > > > smtp_tls_key_file =3D /Path/to/your/private/key
> > > >=20
> > > > You might want not only to query client certificates, but also valida=
te
> > > > them. To do so, use:
> > > >=20
> > > > smtpd_tls_CAfile =3D /Path/to/certificate/block
> > > >=20
> > > > This requires all trusted intermediate certificates to be put together
> > > > in one file, as far as I can remember.
> > > >=20
> > > > (See http://www.postfix.org/postconf.5.html#smtpd_tls_CAfile for
> > > > details) =20
> > >=20
> > > I didn't have that set. Set it to this now:
> > >   smtpd_tls_CAfile =3D /etc/pki/tls/certs/ca-bundle.crt
> >=20
> > Okay, so this mail should have a "(Verified OK)" somewhere at a Received-
> > header...
>=20
> It does when you send an email from gmail.com to your IPFire email address =
for
> example. I think this looks correct now.
>=20
> > >=20
> > > > I did not test the mail server's cipherlist, but I hope it is secure =
for
> > > > both SMTP server and client. :-) =20
> > >=20
> > > Probably not :)
> > >=20
> > > I think we both should walk through the configuration together...
> >=20
> > Okay.
>=20
> Cool.
>=20
> > >=20
> > > > > * LE deployed on im01.i.ipfire.org which runs Prosody, our XMPP ser=
ver
> > > > >=20
> > > > > * I enabled HSTS for all web services since all of them are forcing
> > > > > the
> > > > > browser
> > > > > to use HTTPS. =20
> > > >=20
> > > > How about the IPFire mirrors? If one of them (i.e. "mirror1.ipfire.or=
g")
> > > > supports
> > > > HTTPS, are the systems following the 30x redirects? In the future may=
be
> > > > hardcoding
> > > > the protocol might be a good idea: If a mirror supports HTTPS, we use=
 it
> > > > there. =20
> > >=20
> > > See above. And yes, clients follow a large number of redirects.
> > > Firefox follows 20.
> > >=20
> > > > But that is only a minor thing.
> > > >=20
> > > > In general, HSTS is very nice to have here. :-) =20
> > > > >=20
> > > > > * We only allow TLS 1.2 for web. =20
> > > >=20
> > > > It seems like the key size is 2048 bits. Although this is not critica=
l,
> > > > I
> > > > would
> > > > recommend to move to 4096 bits at the next key rollover. =20
> > >=20
> > > Well, I didn't check. Because security wasn't really what I had in mind
> > > here.
> > > Our old keys were 4096 bits long. I didn't even know this could be
> > > changed.
> > >=20
> > > > Let's Encrypt announced to support ECDSA in early 2018, so at that ti=
me
> > > > we
> > > > could
> > > > also use dual-stack RSA and ECDSA, as we are doing with IPFire in Core
> > > > Update
> > > > 115. =20
> > >=20
> > > They promised a lot. Let's see :)
> > >=20
> > > > > * Since everything is on SSL now, I also enabled HTTP/2.0.
> > > > >=20
> > > > > * I also enabled OCSP stapling. =20
> > > >=20
> > > > Excellent. =20
> > > > >=20
> > > > > The nginx configuration file looks as follows:
> > > > >=20
> > > > >   # Enable TLS 1.2 only
> > > > >   ssl_protocols TLSv1.2;
> > > > >=20
> > > > >   # Enable protection against BEAST attacks
> > > > >   ssl_prefer_server_ciphers on;
> > > > >   ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-
> > > > > SHA384:ECDHE-
> > > > >   ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-
> > > > > AES128-
> > > > > GCM-
> > > > >   SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDH=
E-
> > > > > RSA-
> > > > > AES256-
> > > > >   SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"; =20
> > > >=20
> > > > Apparently there is an issue here: SSL Labs does not display the
> > > > Chacha/Poly
> > > > cipher.
> > > > Perhaps nginx is linked against OpenSSL 1.0.x ? =20
> > >=20
> > > The web server is running openssl 1.0.2k. Unfortunately it is still on
> > > Fedora 24
> > > which I need to update as soon as I can.
> >=20
> > It seems like you have done so meanwhile, since SSLLabs now shows
> > Chacha/Poly,
> > too.
>=20
> Yes, I did. Also manually verified this. We are on OpenSSL 1.1.x now.
>=20
> > >=20
> > > > I am not sure if we should prioritise this cipher suite over AES since
> > > > it
> > > > is
> > > > safe
> > > > too, but seems to faster on devices without AES-NI and a small CPU, s=
uch
> > > > as
> > > > Android smartphones. Decision is up to you. =20
> > >=20
> > > I got this from Mozilla, so I thought they considered this.
> >=20
> > Yes, as far as I can remember, there was a discussion about this on some
> > Mozilla
> > mailing list.
> > >=20
> > > > >   # Enable session caching
> > > > >   ssl_session_cache shared:SSL:50m;
> > > > >   ssl_session_timeout 1d;
> > > > >=20
> > > > >   # Enable Certificate Stapling
> > > > >   ssl_stapling on;
> > > > >   ssl_stapling_verify on;
> > > > >   resolver 172.28.1.1;
> > > > >=20
> > > > >   # HSTS (15768000 seconds =3D 6 months)
> > > > >   add_header Strict-Transport-Security max-age=3D15768000;
> > > > >=20
> > > > > This is inspired by the Mozilla recommendations.
> > > > >=20
> > > > > So please guys, have a test. I am quite sure that although this is
> > > > > quite
> > > > > a
> > > > > "modern" configuration all recent web browsers should work fine. If
> > > > > you
> > > > > are
> > > > > on
> > > > > IE6, you are fucked. Tough luck. =20
> > > >=20
> > > > Yes, I think supporting legacy clients is not a very good idea. Of
> > > > course,
> > > > there
> > > > are some scenarios where you must do so (big company website, or
> > > > anything
> > > > else),
> > > > but for this, I consider it safe.
> > > >=20
> > > > Food for thoughts: Is there anything against updating OpenSSL to 1.1.x
> > > > in
> > > > IPFire?
> > > > That way, we could also use Chacha/Poly there and disable TLS 1.0, bu=
t I
> > > > am
> > > > not
> > > > sure how many clients will be broken by this. =20
> > >=20
> > > I don't think there is nothing that is stopping us any more. For quite
> > > some
> > > time
> > > nothing built against OpenSSL 1.1 since they changed a lot in the API. =
Of
> > > course
> > > we will still need to ship 1.0.1 because loads of things link against i=
t.
> > >=20
> > > Before we also shipped OpenSSL 0.9.8 for quite a while until it was
> > > discontinued:
> > >=20
> > > https://cgit.ipfire.org/ipfire-2.x.git/commit/lfs/openssl-compat?id=3D4=
5ff42
> > > 0e
> > > c7e3
> > > ad522dc6d0e53837a6e1951407fc
> >=20
> > This is my opinion, too. Of couse, shipping to version of one program is
> > ugly,
> > but I consider this safe here if OpenSSL 1.1.x breaks some things entirel=
y.
>=20
> I would prefer to have the entire system to build against the new one, but
> sometime people compile their own software and run it on IPFire. To not bre=
ak
> that, we usually ship the old libraries for quite a while.
>=20
> We removed openssl 0.9.8 because it wasn't patched any more.
>=20
> > >=20
> > > About disabling TLS 1.0. I am all for it, but it needs some good testin=
g.
> > > One
> > > common scenario is that people use Postfix as a mail relay to deliver
> > > emails
> > > to
> > > an internal Exchange server. Those often require RC4 and MD5. I think t=
hat
> > > is
> > > Exchange 2003. This is bad and ugly but this is what people are using in
> > > 2017.
> > > And we need to be able to enable these ciphers optionally when they are
> > > required.
> >=20
> > As far as I am concerned, you have to manually build OpenSSL 1.1.x with R=
C4
> > support,
> > by default it does not support it anymore.
>=20
> My honest opinion here is that this is how it should be.
>=20
> Anyone who relies on it needs to stop using it. Right now. It's not a *nice=
 to
> have*. It's wrong and bad and ugly.
>=20
> But unfortunately I get the phone calls where people complain about this not
> being supported any more. So there has to be some sort of trade-off.
>=20
> I probably exaggerated this example a little bit too much, but there is
> certainly some patches in the system where we had to downgrade security a
> little
> for better compatibility. This is always difficult, but things like RC4 are
> not
> a question for me. I know what I would decide.
>=20
> > TLS with mailservers is always somewhat special since its goal is complet=
ely
> > different from TLS used at web services. Mail servers want to prevent pla=
in
> > text
> > transfer (protection against a passive attacker), and here, a weak
> > encryption
> > is
> > better than none.
>=20
> Maybe, but the question then is: Does RC4 still qualify as "encryption" whe=
re
> a
> passive attack is so simple to perform? It is a way of scrambling the data =
but
> that is about it.
>=20
> > Of course, I would be grateful if these old Exchange instances disappear.=
..
>=20
> Yes, and we have to work towards that by announcing that we are going to
> discontinue support for certain things then.
>=20
> -Michael
>=20
> > >=20
> > > However, we should have strong defaults.
> > >=20
> > > > > But if you find anything that should work, please let me know. You =
can
> > > > > also
> > > > > run
> > > > > some scanners against it and see what happens. I did a few and they
> > > > > show
> > > > > A+
> > > > > rating which is what we are looking for.
> > > > >=20
> > > > > Anything that I have forgotten to enable which could benefit
> > > > > security? =20
> > > >=20
> > > > Not that I am aware of at the moment (besides the stuff mentioned
> > > > above).
> > > > Great job! =20
> > >=20
> > > Cool!
> > >=20
> > > -Michael
> > >=20
> > > >=20
> > > > Best regards,
> > > > Peter M=C3=BCller =20
> > > > >=20
> > > > > Looking for your input :)
> > > > >=20
> > > > > Best,
> > > > > -Michael
> > > > >=20
> > > > > On Mon, 2017-09-25 at 17:48 +0200, Peter M=C3=BCller wrote: =20
> > > > > > Hello Michael,
> > > > > >    =20
> > > > > > > Hi,
> > > > > > >=20
> > > > > > > On Fri, 2017-09-15 at 22:26 +0200, Peter M=C3=BCller wrote:    =

> > > > > > > > Hello Michael, hello Matthias,
> > > > > > > >=20
> > > > > > > > a few thoughts on this from me:
> > > > > > > >=20
> > > > > > > > (1) @Michael: Thank you for having a look at this. In
> > > > > > > > my opinion, enabling HTTPS on all *.ipfire.org sites by
> > > > > > > > default would be a huge security benefit.
> > > > > > > >=20
> > > > > > > > Of course, this needs time and testing, so no pressure. :-)
> > > > > > > >=20
> > > > > > > > Especially on download sites HTTPS would be nice in
> > > > > > > > case someone verifies the downloaded ISO - when transmitted
> > > > > > > > in plaintext, both image and checksum might be modified
> > > > > > > > by a MITM.
> > > > > > > >=20
> > > > > > > > Further, there is still SHA1 in use on http://download.ipfire=
.or
> > > > > > > > g/
> > > > > > > > ,
> > > > > > > > but that is another issue.     =20
> > > > > > >=20
> > > > > > > Indeed it is. We have ticket for that:
> > > > > > >   https://bugzilla.ipfire.org/show_bug.cgi?id=3D11345=C2=A0=C2=
=A0=C2=A0=20
> > > > > >=20
> > > > > > Thanks for the ticket link.   =20
> > > > > > >    =20
> > > > > > > > (2) Speaking about the CAs: I do not know what opinion
> > > > > > > > to have here.
> > > > > > > >=20
> > > > > > > > On the one hand, using your own project CA is good since
> > > > > > > > nobody except the visitors has to rely on some external
> > > > > > > > certificate signing company.     =20
> > > > > > >=20
> > > > > > > Agreed. I do not trust any of those public CAs - at all. They h=
ave
> > > > > > > a
> > > > > > > commercial interest and that is it.
> > > > > > >    =20
> > > > > > > > Publishing the TLSA-records tells everyone that this CA -
> > > > > > > > which is untrusted by all current browsers - is legitimate
> > > > > > > > on *.ipfire.org.     =20
> > > > > > >=20
> > > > > > > We do this.
> > > > > > >=20
> > > > > > > http://planet.ipfire.org/post/ipfire-org-is-signed-now=C2=A0=C2=
=A0=C2=A0=20
> > > > > >=20
> > > > > > I forgot that. Unfortunately, at the moment, "only" mail servers
> > > > > > benefit from this (see below).   =20
> > > > > > >    =20
> > > > > > > > On the other hand, there are two points against it:
> > > > > > > > (a) Nobody actually uses TLSA/DANE for validating web site
> > > > > > > > certificates (this is different when it comes to SMTP). So,
> > > > > > > > nearly every user will see a certificate warning.     =20
> > > > > > >=20
> > > > > > > Indeed not a single browser is verifying it. There is plugins t=
hat
> > > > > > > can
> > > > > > > show an icon and that's it.
> > > > > > >=20
> > > > > > > We also do this for our mail server which does not have a publi=
cly
> > > > > > > signed certificate.   =20
> > > > > >=20
> > > > > > As far as I am concerned, there are two different approaches to T=
LS:
> > > > > >=20
> > > > > > (a) If you are running a mail server, TLS is mostly used in
> > > > > > opportunistic
> > > > > > mode, and certificates are not that important. The idea behind th=
is
> > > > > > is to prevent plaintext transport of e-mails, that's why so many =
big
> > > > > > MX still support weak ciphers such as 3DES. (Personally, I am not=
 a
> > > > > > fan of opportunistic TLS since it only protects against passive
> > > > > > attackers
> > > > > > and one has to use ancient algorithms. At least RC4-MD5 finally
> > > > > > disappeared...)
> > > > > >=20
> > > > > > So, a self-signed certificate for a MX is no problem - at least, =
not
> > > > > > a big one. Only a few MX actually ask for a client certificate, a=
nd
> > > > > > even
> > > > > > less systems are configured to present any.
> > > > > >=20
> > > > > > (b) Web browsers have a completely different view on this: They
> > > > > > first
> > > > > > check the certificate against the DNS name, and if they match,
> > > > > > encryption
> > > > > > can be started. On the other hand, in case they see an untrusted
> > > > > > certificate
> > > > > > for whatever reason, everything becomes bad very quickly.
> > > > > >=20
> > > > > > Integrity is much more important here in order to protect the use=
rs
> > > > > > against active (MITM) attackers.
> > > > > >=20
> > > > > > Because of this, I would prefer certs signed by well-known CAs for
> > > > > > public
> > > > > > web sites.
> > > > > >    =20
> > > > > > >    =20
> > > > > > > > Personally, i suppose DANE will never be implemented in
> > > > > > > > web browsers. There are too many collisions with the systems
> > > > > > > > DNS service, and network stacks, and the network's firewall
> > > > > > > > rules, and so on. Sad, but that is what we (do not) have.    =
 =20
> > > > > > >=20
> > > > > > > I am not convinced that this has technical reasons. It just puts
> > > > > > > some
> > > > > > > big businesses will lose a machine that prints them money.   =20
> > > > > >=20
> > > > > > Partly I think. DANE depends on DNSSEC, and I remember some user
> > > > > > complaints
> > > > > > that their ISPs filter DNS queries to external name servers witho=
ut
> > > > > > using it on their own systems.   =20
> > > > > > >=20
> > > > > > > Nobody there is interested in the security. They are interested=
 in
> > > > > > > the
> > > > > > > money.   =20
> > > > > >=20
> > > > > > Without being very deep into this, I assume you are right.   =20
> > > > > > >    =20
> > > > > > > > So, enabling HTTPS on all or at least some very important
> > > > > > > > IPFire sites will cause more user complaints.     =20
> > > > > > >=20
> > > > > > > Indeed. That is why we don't enforce it.
> > > > > > >    =20
> > > > > > > > Further, and that is a _very_ big problem in my eyes, it
> > > > > > > > actually decreases transport encryption security: Every time
> > > > > > > > a user accesses *.ipfire.org, he/she/it has to bypass a
> > > > > > > > certificate warning - at least in FF, there is no easy way
> > > > > > > > to store the exception permanently.
> > > > > > > >=20
> > > > > > > > In case a MITM injects his own certificate to break TLS,
> > > > > > > > the user will see a certificate warning which is nearly
> > > > > > > > identical to those shown usually for IPFire's CA. And the
> > > > > > > > user will mostly bypass this - very well-known - warning,
> > > > > > > > an the attacker won.
> > > > > > > >=20
> > > > > > > > To prevent this, you MUST check the certificates checksum
> > > > > > > > against the value you know is legitimate. Every time.
> > > > > > > >=20
> > > > > > > > Nobody will do so.     =20
> > > > > > >=20
> > > > > > > Agreed.
> > > > > > >    =20
> > > > > > > > (b) As I mentioned above, I completely understand your point
> > > > > > > > having an own CA. However, I do not think this is so important
> > > > > > > > for public web services:     =20
> > > > > > >=20
> > > > > > > I emphasise here on "web services". I am not even sure if Let's
> > > > > > > Encrypt
> > > > > > > can issue certificates for our internal LDAP server or our mail
> > > > > > > server,
> > > > > > > etc.   =20
> > > > > >=20
> > > > > > This depends on the actual network (especially DNS) configuration.
> > > > > > If the server does not have a public IP, but is configured in the
> > > > > > DNS,
> > > > > > LE can validate it without a direct connection:
> > > > > > - https://community.letsencrypt.org/t/cert-for-intranet/6337/4=20
> > > > > > - https://community.letsencrypt.org/t/on-the-state-of-the-dns-01-=
cha
> > > > > > ll
> > > > > > enge
> > > > > > /480
> > > > > > 5   =20
> > > > > > >    =20
> > > > > > > > As far as I am concerned, there is no "trust" in case of CA
> > > > > > > > companies. Some of them showed a really unprofessional behavi=
our
> > > > > > > > (DigiNotar, WoSign, Symantec, ...) and are/were either kicked
> > > > > > > > off business by their customers or the web browser
> > > > > > > > developers.     =20
> > > > > > >=20
> > > > > > > So why would we assume that Let's Encrypt is doing a better job?
> > > > > > > Just
> > > > > > > because they are sponsored by some of the "good guys"?
> > > > > > >    =20
> > > > > > > > You only "trust" a CA to validate if a certain domain really
> > > > > > > > belongs to the person who claims so.
> > > > > > > >=20
> > > > > > > > In case there is a certificate in use signed by a foreign CA,
> > > > > > > > what should happen? Nobody except the server admin has the
> > > > > > > > private key, and there are many techniques to prevent modern
> > > > > > > > browsers accepting any certificate for your domain, such
> > > > > > > > as:     =20
> > > > > > >=20
> > > > > > > So let's split all of this:
> > > > > > >    =20
> > > > > > > > - DANE/TLSA (specifies which certificate [chain] is valid)   =
  =20
> > > > > > >=20
> > > > > > > We can just install that for the Let's Encrypt CA. It doesn't m=
ake
> > > > > > > sense to have TLSA records for each cert because they will be
> > > > > > > replaced
> > > > > > > very very quickly.   =20
> > > > > >=20
> > > > > > I remember a trick here: If you do not rotate the private key eve=
ry
> > > > > > time LE's signature expires, the public one also stays the same -
> > > > > > and the TLSA record does not need to be changed.
> > > > > >=20
> > > > > > Can't find the link right now...   =20
> > > > > > >    =20
> > > > > > > > - CAA (DNS record, rather new, specifies which CAs can issue
> > > > > > > > certificates for this site, might be supported by common
> > > > > > > > browsers
> > > > > > > > some day)     =20
> > > > > > >=20
> > > > > > > I need to implement that in our DNS server software, but that is
> > > > > > > not
> > > > > > > a
> > > > > > > big thing. Will do that soon.   =20
> > > > > >=20
> > > > > > Thanks.   =20
> > > > > > >    =20
> > > > > > > > - HSTS (preventing a MITM from downgrading to plaintext)     =
=20
> > > > > > >=20
> > > > > > > Who wants to take care of this?   =20
> > > > > >=20
> > > > > > Actually, HSTS is quite easy to deploy since it only tells web
> > > > > > browsers
> > > > > > to enforce TLS on a certain site. So, if there are no dependencies
> > > > > > (unencrypted external resources, ad servers, ...), you can just s=
et
> > > > > > it
> > > > > > up and forget it. :-)   =20
> > > > > > >    =20
> > > > > > > > - HPKP (as DANE, but supported by modern browsers, TOFU
> > > > > > > > [Trust On First Use] =3D first connection must be clean)     =
=20
> > > > > > >=20
> > > > > > > Same.   =20
> > > > > >=20
> > > > > > Indeed, HPKP is more complicated, it is like DANE without DNS.
> > > > > > Further, some security experts (such as Ivan Ristic) argue that
> > > > > > it might become dangerous in case of misconfiguration.   =20
> > > > > > >=20
> > > > > > > And who would like to create tickets on BZ for all of this?
> > > > > > >    =20
> > > > > > > > Except from going out of business, I do not see any risk for
> > > > > > > > a web site owner here. That is, in case all or some of the
> > > > > > > > mentioned methods are implemented.     =20
> > > > > > >=20
> > > > > > > LOL, we are not a business. We are an Open Source project.   =20
> > > > > >=20
> > > > > > "Going out of business" was relating to CAs, not to IPFire. But
> > > > > > yes, it would be very sad if this project disappears.   =20
> > > > > > >    =20
> > > > > > > > Let's Encrypt (LE) seems to be different from other CAs since
> > > > > > > > they use standardised methods and act quite transparently.
> > > > > > > > Further, there are some "major players" behind it (Mozilla,
> > > > > > > > EFF, ...) which have a good reputation. This - hopefully -
> > > > > > > > means that there will be no security breaches like in case
> > > > > > > > of DigiNotar.     =20
> > > > > > >=20
> > > > > > > I don't share your hope, but I do not want to fight this. I have
> > > > > > > been
> > > > > > > trialing Let's Encrypt a little bit on some web shops and other
> > > > > > > things
> > > > > > > and it does the job. To be honest I do not see the point in
> > > > > > > spending
> > > > > > > the money on a different vendor of certificates. So take that a=
s:
> > > > > > > They
> > > > > > > are not worse than those.   =20
> > > > > >=20
> > > > > > I don't want to fight either; but I am afraid I did not fully
> > > > > > understand your point concerning the trust/distrust of public CAs
> > > > > > (except for obvious reasons like security breaches).   =20
> > > > > > >    =20
> > > > > > > > To come to an end, using LE as a CA for *.ipfire.org will
> > > > > > > > not harm the security of IPFire significantly. It reduces
> > > > > > > > browser alerts and a possible security threat (see above),
> > > > > > > > making it easier to deploy HTTPS.     =20
> > > > > > >=20
> > > > > > > Let's do it then.   =20
> > > > > >=20
> > > > > > All right. :-)   =20
> > > > > > >=20
> > > > > > > I need some support here, because I am running out of time.    =

> > > > > >=20
> > > > > > Which web server are you running? At the moment, I am only using
> > > > > > Apache and could provide some support here.
> > > > > >=20
> > > > > > Best regards,
> > > > > > Peter M=C3=BCller   =20
> > > > > > >    =20
> > > > > > > > Needless to say, DANE/HSTS/CAA are obligatory.
> > > > > > > >=20
> > > > > > > > Best regards,
> > > > > > > > Peter M=C3=BCller     =20
> > > > > > >=20
> > > > > > > -Michael   =20
> > > > > >=20
> > > > > >    =20
> > > >=20
> > > >  =20

--===============8760687507310878863==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl
Mnlwa3R4Z0hudy8yK1FDUWNGQWxwdkVCRUFDZ2tRZ0hudy8yK1EKQ1FkYWZBLytKdzlTYzVBL3pP
TWR4L3JGSDhEais1dVdicjZGcWVxOVNFWUJOeWJPbzlrb1hjcXpBZnpVektNOAorUUdlL00wQWU1
YjBFUTlXZUNWZHRKYklXOWovQU9WTzY5UGtrYnJzblVqOUJjc3Z0alJQNnplRm9JcFp6KzF0CmtF
eVlCazhLRlF4Qk5KYlFVQURNTVNpeXRQYlNNVGlHUXlEVVdWMGZSVmdkUW9lUEs5Zm9uVjNUM0JZ
WHFJZGMKaWIrSHhxSGh4YUh1MFBjaEVOOXpmM1lTTjJDZ21nU3RYMTdhZ09ZNWdmd3pKSlZ0QW5P
OHVMRFFIUVR1UnJaRwpnWFVLT3RSdEkrb1BGZFdkdlRQWW5iUStBVWlkWnlzaHd2d29RNDhMTkt6
OThVQytOY2ROTUpWbkE3cjBxL1VkCjNUam0zNWc1M2taS2xQZXNSOGgvaEcySHp5eXZnRXF4V2J2
SWtxaU5MRXhPMjZidTdBM0RwRTlMM0x5WXhtcUEKWmFTcENZNFdEVE1maWFXUVo1dnRUZjhDS2Ja
WnhLcGd3SFA1ZEN5bnUxT1FKazRGZUkyK3o2NCtlZ2U3VUZqSwpOUmdtUmRGYmV0S0JTUU1oM0R2
bmIxUjdhTEdXd2l4Y3gyV2ZQVEw1WnRNVzk1RzVqVklIVmdEcjNmUnR0TEJaCnNLck0xcnFQdlgv
c1lzL3liK2o5VnM0YS9zWnFtRm11NXFYbkVBL0JDMW1MYTlRdkhhT0hnNmhHd2xCYXpwUXIKTFhY
ZEV6ZThoa1dmbWN6eUV2Y0EyYmI5b2NzeTlCaDN3R1JNTGgwQ2xtWGtnMHpUbEtpdWFPK1oxMmVz
WU0zNgpVSDB6NXYzdzNEWVpTR1ZPVmpOZ1ZoTGxzZ3lyelluZEl0SE1MQWxCMFBCczk1WW1XWnc9
Cj00SnpsCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

--===============8760687507310878863==--