CA and HTTPS usage on *.ipfire.org

Michael Tremer michael.tremer at ipfire.org
Wed Oct 25 16:25:52 CEST 2017


Hello altogether,

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).

There you have it. I did it. I bit the bullet.

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 needed.
They also throttled me to only issue a small number of certificates per week.

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):

* LE deployed for all web services with the exception of boot.ipfire.org and
fireinfo.

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).

Same with fireinfo. I have no idea if the profiles can be sent properly over
HTTPS without touching the client first.

* LE deployed on mail01.i.ipfire.org (Postfix + Dovecot)

* LE deployed on im01.i.ipfire.org which runs Prosody, our XMPP server

* I enabled HSTS for all web services since all of them are forcing the browser
to use HTTPS.

* We only allow TLS 1.2 for web.

* Since everything is on SSL now, I also enabled HTTP/2.0.

* I also enabled OCSP stapling.

The nginx configuration file looks as follows:

  # Enable TLS 1.2 only
  ssl_protocols TLSv1.2;

  # 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:ECDHE-RSA-AES256-
  SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";

  # Enable session caching
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 1d;

  # Enable Certificate Stapling
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 172.28.1.1;

  # HSTS (15768000 seconds = 6 months)
  add_header Strict-Transport-Security max-age=15768000;

This is inspired by the Mozilla recommendations.

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.

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.

Anything that I have forgotten to enable which could benefit security?

Looking for your input :)

Best,
-Michael

On Mon, 2017-09-25 at 17:48 +0200, Peter Müller wrote:
> Hello Michael,
> 
> > Hi,
> > 
> > On Fri, 2017-09-15 at 22:26 +0200, Peter Müller wrote:
> > > Hello Michael, hello Matthias,
> > > 
> > > a few thoughts on this from me:
> > > 
> > > (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.
> > > 
> > > Of course, this needs time and testing, so no pressure. :-)
> > > 
> > > 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.
> > > 
> > > Further, there is still SHA1 in use on http://download.ipfire.org/,
> > > but that is another issue.  
> > 
> > Indeed it is. We have ticket for that:
> >   https://bugzilla.ipfire.org/show_bug.cgi?id=11345
> 
> Thanks for the ticket link.
> > 
> > > (2) Speaking about the CAs: I do not know what opinion
> > > to have here.
> > > 
> > > 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.  
> > 
> > Agreed. I do not trust any of those public CAs - at all. They have a
> > commercial interest and that is it.
> > 
> > > Publishing the TLSA-records tells everyone that this CA -
> > > which is untrusted by all current browsers - is legitimate
> > > on *.ipfire.org.  
> > 
> > We do this.
> > 
> > http://planet.ipfire.org/post/ipfire-org-is-signed-now
> 
> I forgot that. Unfortunately, at the moment, "only" mail servers
> benefit from this (see below).
> > 
> > > 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.  
> > 
> > Indeed not a single browser is verifying it. There is plugins that can
> > show an icon and that's it.
> > 
> > We also do this for our mail server which does not have a publicly
> > signed certificate.
> 
> As far as I am concerned, there are two different approaches to TLS:
> 
> (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...)
> 
> 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.
> 
> (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.
> 
> Integrity is much more important here in order to protect the users
> against active (MITM) attackers.
> 
> Because of this, I would prefer certs signed by well-known CAs for public
> web sites.
> 
> > 
> > > 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.  
> > 
> > I am not convinced that this has technical reasons. It just puts some
> > big businesses will lose a machine that prints them money.
> 
> Partly I think. DANE depends on DNSSEC, and I remember some user complaints
> that their ISPs filter DNS queries to external name servers without
> using it on their own systems.
> > 
> > Nobody there is interested in the security. They are interested in the
> > money.
> 
> Without being very deep into this, I assume you are right.
> > 
> > > So, enabling HTTPS on all or at least some very important
> > > IPFire sites will cause more user complaints.  
> > 
> > Indeed. That is why we don't enforce it.
> > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > To prevent this, you MUST check the certificates checksum
> > > against the value you know is legitimate. Every time.
> > > 
> > > Nobody will do so.  
> > 
> > Agreed.
> > 
> > > (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:  
> > 
> > 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.
> 
> 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 
> - https://community.letsencrypt.org/t/on-the-state-of-the-dns-01-challenge/480
> 5
> > 
> > > 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.  
> > 
> > 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"?
> > 
> > > You only "trust" a CA to validate if a certain domain really
> > > belongs to the person who claims so.
> > > 
> > > 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:  
> > 
> > So let's split all of this:
> > 
> > > - DANE/TLSA (specifies which certificate [chain] is valid)  
> > 
> > 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.
> 
> 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.
> 
> Can't find the link right now...
> > 
> > > - CAA (DNS record, rather new, specifies which CAs can issue
> > > certificates for this site, might be supported by common browsers
> > > some day)  
> > 
> > I need to implement that in our DNS server software, but that is not a
> > big thing. Will do that soon.
> 
> Thanks.
> > 
> > > - HSTS (preventing a MITM from downgrading to plaintext)  
> > 
> > Who wants to take care of this?
> 
> 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. :-)
> > 
> > > - HPKP (as DANE, but supported by modern browsers, TOFU
> > > [Trust On First Use] = first connection must be clean)  
> > 
> > Same.
> 
> 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.
> > 
> > And who would like to create tickets on BZ for all of this?
> > 
> > > 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.  
> > 
> > LOL, we are not a business. We are an Open Source project.
> 
> "Going out of business" was relating to CAs, not to IPFire. But
> yes, it would be very sad if this project disappears.
> > 
> > > 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.  
> > 
> > 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.
> 
> 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).
> > 
> > > 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.  
> > 
> > Let's do it then.
> 
> All right. :-)
> > 
> > I need some support here, because I am running out of time.
> 
> Which web server are you running? At the moment, I am only using
> Apache and could provide some support here.
> 
> Best regards,
> Peter Müller
> > 
> > > Needless to say, DANE/HSTS/CAA are obligatory.
> > > 
> > > Best regards,
> > > Peter Müller  
> > 
> > -Michael
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ipfire.org/pipermail/development/attachments/20171025/9f20d9f4/attachment-0001.sig>


More information about the Development mailing list