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 (was: Re: [PATCH v2] WebUI: print more information on used nameservers) Date: Sun, 24 Sep 2017 23:00:02 +0100 Message-ID: <1506290402.2813.26.camel@ipfire.org> In-Reply-To: <20170915222637.16f1ec6a.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1167358868571016277==" List-Id: <development.lists.ipfire.org> --===============1167358868571016277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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 --===============1167358868571016277== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxuSUt1SUFDZ2tRZ0hudy8yK1EKQ1FjY3VSQUFxM3FsOFJGNjAw SHYrR1hEWUtkdnVqNkUvQ2ZXZllhbkdMaFY1WHRGYXpWY2h5cGxZK0lBOFR3dApraTNvN0lXMXdq L2cvQVNwalJCeDl5TmhCRVJtUFRhR3ZqZ2JiTFNJL0NkTGx6SVZlWVNvTG5xeldlNllHU1dwCjdI d0pXbElzdG51VFFqNC9Zdk11aDVmUkZndS9ocWhYbW9WMno3R2hIWmVYT2FPKzJnSjg5clV1dmhr YWtBQlkKcFpSY3RNdWt2a2VqL3BWWDRmcUNQbzUyaTFndTBKSmpzY05WWm9nK2VPYVBmTnJQYWNU NW9BRG5Vem54STNZbQpTckFzUnQvRUNHV3hwYU81Wk9kbDZWdlFXUEVvc0Q4ZmpSTVlpbDFuZ0NH RGJnbUo5NUh1OHpXczFLUmRwdU9PCmJVNHNZamdkdlhxcEV2VzZOSWJQUFRBMzAyT2c3YUVaaU1q czZXUEdqSXRTRmQvbTdGV2JhaFNLTGZJSVg5M0EKNmViWUFmVGY5L0dsZmJLU0tmSEkrOHE0NWtx QXlJQVd3S0FkR0FFRHE4QTI0czVGUDBMSTA3a0h6UWl1R3BQNQozTVNrWmFaL2RXOTJTUjZKV1Nw L0hoQUNLRlRQcVVva0dtUXhhUGdsSFhTaHdBeFN0RmN6VXdUTm5WcnY3Z0YwCnVocDgyTVNBd1B6 NmJIODVBOFI4aC9jV0JwWXlNMVJpWkNZNWZtcGl4K0p2ZmJ5WWE0M2U4bGhKYy9WRTJtZEoKZUcx MlY3d3lRck9KYVBZeEVmMjE1TW4rL3U2OXpFK2lId0g3enVKS3RKR0hXWlBuZ2RTTkc5WFM2UFJu VDltYgpsMDJsU3o5RW9ZSnBHWDVhZk9zRDBLQkpNYkZsKzQ4RVlBeXNnVGYrTTYxMWYrK05WcFk9 Cj01OVJECi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============1167358868571016277==--