LibreSSL languishes on Linux

Posted Jan 5, 2021 20:55 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: LibreSSL languishes on Linux by flussence
Parent article: LibreSSL languishes on Linux

Firstly this doesn't seem responsive to the question. I asked for an example, and what I see here is an excuse. I think this is because you do not have such an example, that in fact "most protocols" do not deliver what you claimed after all.

Secondly, RFC 8446 is designed to work fine without certificates. You get a complete working system, including forward secrecy. However in this model you'll need to agree Pre Shared Keys with every single server you want to talk to (and they should agree separate keys with each of their clients). This might be nice for a system that connects speakers in each room of your home over WiFi to a central music playing device for example, but it's not viable for visiting arbitrary web sites.

The need for a PKI (and thus Certificates) happens when you'd like (as we do) to securely authenticate any system connected to the Internet. And this isn't out of some weird fetish for as you say 1960s technology, we simply do not know any alternatives that actually work. The usual claims are either that TOFU is "good enough" (good enough that you'll get exploited and never know it, perhaps) or that the Web of Trust works at scale (it does not).

LibreSSL languishes on Linux

Posted Jan 5, 2021 22:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

PKI is fine, it's just that distributed PKI is not fine. Way too many points of failure.

Instead we should have pushed DNSSEC-based security, this way you only need to trust you domain name registrar instead of ALL three hundred or so certificate issuers in all kinds of jurisdictions.

LibreSSL languishes on Linux

Posted Jan 6, 2021 2:20 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

You don't have to trust the CAs. Certificate Transparency is mandatory for a cert to be accepted by Chrome (at least), and the CA/B will absolutely drop CAs that issue bogus certs. Delisting is an existential risk for a CA, and they are going to fight tooth and nail within whatever process exists in the local jurisdiction to prevent it from happening.

The other problem is that the system you are describing already exists. It's called DANE, and the basic difficulty with it is that a surprisingly large number of users are (or were) using an amazingly bad DNS resolver that can't even look up a simple TXT record, let alone pull down an entire X.509 certificate.[1] Also, there are crypto issues (which I don't pretend to understand).

[1]: https://www.imperialviolet.org/2015/01/17/notdane.html

LibreSSL languishes on Linux

Posted Jan 6, 2021 2:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> You don't have to trust the CAs. Certificate Transparency is mandatory for a cert to be accepted by Chrome (at least), and the CA/B will absolutely drop CAs that issue bogus certs.
You still can work around it by issuing backdated certificates. I think that window is going to close in 2 years, though.

> It's called DANE
I know about DANE, it's not a solution. A more realistic solution is DNS stapling, basically instead of the regular X509 the certificate the server supplies the DNSSEC-signed replies all the way up to the root zone. The client then just validates the signature chain.

LibreSSL languishes on Linux

Posted Jan 6, 2021 8:22 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

> You still can work around it by issuing backdated certificates. I think that window is going to close in 2 years, though.

For Chromium the relevant code is published: https://source.chromium.org/chromium/chromium/src/+/maste... look at lines around 950 or so

There are four epochs we care about:

1. Ancient history, before there were any rules at all, Chromium arbitrarily assumes certificates must not have had lifetimes exceeding ten years. Did any certificates actually do that? Maybe, but they've never worked in Chrome, so we can assume they're not used. This epoch ended in 2019, and so is now irrelevant

2. The original Baseline Requirements began in July 2012 and allow 60 months (which is to say, five years) for grandfathered scenarios. However in April 2015 this rule changed, so the last such certificate expired last year, in April 2020.

3. The "modern" Baseline Requirements from April 2015 allow 39 months in all cases. This regime ended by consent in March 2018. So the last such certificate expires 1188 days after that at the end of May 2021, almost five months from now.

4. The last such consensual BR amendment in March 2018 allows 825 days. This ended de facto in September 2020. So the last such certificate expires 825 days later, in December 2022. _However_ the CT enforcement rules start May 2018. So a "backdated" certificate issued under this regime has to be prior to May 2018, which means it expired during or before August 2020, last year.

Thus, as you can see, the only backdating option that could mechanically work is a certificate which claims it was issued in late 2017 or early 2018 and expires before end of May 2021.

It is extremely unlikely that such certificates have been created after the CT deadline or will be made in the next few months. If detected they would likely result in the issuing CA being distrusted, yet their practical value to a subscriber is minimal compared to just getting a CT logged certificate.

But if you're concerned anyway and can't wait until June this year simply modify Chromium source to always require SCTs. In practice there likely won't be any sites you use that are still relying on this very narrow exclusion window to function, by February 2018 most vendors were giving unsophisticated subscribers certificates with SCTs baked in already and 1188 days is the very maximum allowable, most certificates will have had far shorter lifespans.