From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: CA and HTTPS usage on *.ipfire.org Date: Wed, 25 Oct 2017 22:12:00 +0200 Message-ID: <20171025221200.79204c92.peter.mueller@link38.eu> In-Reply-To: <1508941552.4838.143.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2069862570334498913==" List-Id: --===============2069862570334498913== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > 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. Thank you very much. :-) I really appreciate this. >=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 them if ne= eded. > They also throttled me to only issue a small number of certificates per wee= k. >=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 thi= ngs > 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 valida= te > them - it can only check than a CA exists I think). Hmmm, that is not very good - of course, everything is better than plaintext, but without validating the certificates... How widely is iPXE used? >=20 > Same with fireinfo. I have no idea if the profiles can be sent properly over > HTTPS without touching the client first. I guess we need to implement that in the clients first. At the moment I am qu= ite busy reworking some broken patches and other stuff, but will have a look at t= hat occasionally. 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.) Just as a side note: Validating this traffic against DANE records would be ni= ce. :-) >=20 > * LE deployed on mail01.i.ipfire.org (Postfix + Dovecot) Yep, seems to work. However, a client certificate in Postfix is still missing: 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)) --> (Client did not present a certificate) <-- [etc.] In your main.cf, it can be enabled by using: smtp_tls_cert_file =3D /Path/to/your/certificate smtp_tls_key_file =3D /Path/to/your/private/key You might want not only to query client certificates, but also validate them. To do so, use: smtpd_tls_CAfile =3D /Path/to/certificate/block This requires all trusted intermediate certificates to be put together in one file, as far as I can remember. (See http://www.postfix.org/postconf.5.html#smtpd_tls_CAfile for details) I did not test the mail server's cipherlist, but I hope it is secure for both SMTP server and client. :-) >=20 > * LE deployed on im01.i.ipfire.org which runs Prosody, our XMPP server >=20 > * I enabled HSTS for all web services since all of them are forcing the bro= wser > to use HTTPS. How about the IPFire mirrors? If one of them (i.e. "mirror1.ipfire.org") supp= orts HTTPS, are the systems following the 30x redirects? In the future maybe hardc= oding the protocol might be a good idea: If a mirror supports HTTPS, we use it ther= e. But that is only a minor thing. In general, HSTS is very nice to have here. :-) >=20 > * We only allow TLS 1.2 for web. It seems like the key size is 2048 bits. Although this is not critical, I wou= ld recommend to move to 4096 bits at the next key rollover. Let's Encrypt announced to support ECDSA in early 2018, so at that time we co= uld also use dual-stack RSA and ECDSA, as we are doing with IPFire in Core Update= 115. >=20 > * Since everything is on SSL now, I also enabled HTTP/2.0. >=20 > * I also enabled OCSP stapling. Excellent. >=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:EC= DHE- > ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GC= M- > SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AE= S256- > SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"; Apparently there is an issue here: SSL Labs does not display the Chacha/Poly = cipher. Perhaps nginx is linked against OpenSSL 1.0.x ? 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, such as Android smartphones. Decision is up to you. >=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. Yes, I think supporting legacy clients is not a very good idea. Of course, th= ere are some scenarios where you must do so (big company website, or anything els= e), but for this, I consider it safe. Food for thoughts: Is there anything against updating OpenSSL to 1.1.x in IPF= ire? That way, we could also use Chacha/Poly there and disable TLS 1.0, but I am n= ot sure how many clients will be broken by this. >=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? Not that I am aware of at the moment (besides the stuff mentioned above). Gre= at job! Best regards, Peter M=C3=BCller >=20 > Looking for your input :) >=20 > Best, > -Michael >=20 > On Mon, 2017-09-25 at 17:48 +0200, Peter M=C3=BCller wrote: > > Hello Michael, > > =20 > > > Hi, > > >=20 > > > On Fri, 2017-09-15 at 22:26 +0200, Peter M=C3=BCller wrote: =20 > > > > 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.org/, > > > > but that is another issue. =20 > > >=20 > > > Indeed it is. We have ticket for that: > > > https://bugzilla.ipfire.org/show_bug.cgi?id=3D11345 =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 have 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 =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 that can > > > show an icon and that's it. > > >=20 > > > We also do this for our mail server which does not have a publicly > > > signed certificate. =20 > >=20 > > As far as I am concerned, there are two different approaches to TLS: > >=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 this > > 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, and 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 certific= ate > > for whatever reason, everything becomes bad very quickly. > >=20 > > Integrity is much more important here in order to protect the users > > 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 complain= ts > > that their ISPs filter DNS queries to external name servers without > > 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-challeng= e/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 behaviour > > > > (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 make > > > 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 every > > 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 set 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 as: 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 > >=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 --===============2069862570334498913==--