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