Re: CA and HTTPS usage on *.ipfire.org (was: Re: [PATCH v2] WebUI: print more information on used nameservers)

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6068 bytes --]

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

> (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

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

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

Nobody there is interested in the security. They are interested in the
money.

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

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

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

> - HSTS (preventing a MITM from downgrading to plaintext)

Who wants to take care of this?

> - HPKP (as DANE, but supported by modern browsers, TOFU
> [Trust On First Use] = first connection must be clean)

Same.

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.

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

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

I need some support here, because I am running out of time.

> Needless to say, DANE/HSTS/CAA are obligatory.
> 
> Best regards,
> Peter Müller

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]