Hacker News Reader

Comment by glofish | Hacker News Reader

I shudder to think about what will happen if they go down for whatever reason. Or get compromised, or the renewal gets bugged etc.

It is all cool and great, but is it sustainable long term, who guarantees that everything will work in 10 years? Monocultures are not desirable.

A ray of hope - you can get a two-year certificate for 10 bucks - so right there, another major benefit of Let's Encrypt, they makes for better competition. (ok I know Apple will stop honoring these starting in the Fall, but I still got two years since the expiration will be for new certificates)

View on HN

The nice thing about ACME is that it's a standardized protocol, so its really easy to configure most clients to use a different provider. All we need is a few more CAs supporting the ACME protocol, and it'd be trivial to switch over to them if Let's Encrypt ever had a problem. (Come to think of it, automatic failover would be a pretty interesting feature to include in an ACME client.)

This should be a state provided service. Or provided by the UN. Essential stuff like this or root DNS should be a planetary responsibility.

In a lot of countries, giving the government the ability to issue SSL certificates would be a catastrophe in terms of surveillance and censorship.

Didn't think of that.

It doesn't have to be just the state or the UN though. It's not about removing all the other actors on the market.

But if I make a website on Python programming in french, I'm quite ok using the french gov as a CA provider.

I mean, I trust mozilla because it's mozilla. But I wouldn't trust most companies.

There was an incident just last year with Kazakhstan:

https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

Not exactly the same as for-website certificates but in the same realm of government certificate issuance.

The problem is, there’s no way to enforce this. If you are a CA, there is nothing technically stopping you from issuing a certificate for google.com. There’s no infrastructure for the ability to say “this CA is valid only for sites that agree with the risks involved in using it”.

Actually, I believe there are. IIRC it's possible for a CA's root cert to be limited to only a certain TLD. There's an extension called "Name Constraints" that limits a Root SSL Cert, and I believe it is honored by chrome.

https://security.stackexchange.com/questions/31376/can-i-res...

It's an optional extension, so a client may ignore it without failing the connection. It needs a lot more adoption. I could, for example, instead of getting a wildcard cert, get LE to sign a CA valid for my domain. That way I can issue certs for my domain myself and put load off of LE.

Actually Firefox for example carries around code to arbitrarily set any restrictions on any of the root CAs in Mozilla's trust store.

These are documented, on a best effort basis, at:

https://wiki.mozilla.org/CA/Additional_Trust_Changes

It is true, however, that no equivalent rules are enforced in most generic TLS clients (e.g. using OpenSSL directly or something like Python).

Protocols allow for namespace restrictions on CA certificates. There could, in concept, be something stopping you from spoofing google.

https://www.ietf.org/rfc/rfc2459.txt - section 4.2.1.11, Name Constraints

Given that I don't think you can actually buy that kind of cert, and the term "CA" is accepted to imply "universal CA", you're correct.

I'm by no means an expert, but I believe Certificate Transparency provides a way to catch that rogue CA after the fact.

Only if the certificate authority doesn't implement a way of not submitting their cert to the CT log servers. Of course, eventually someone might notice (if the certificate is used widely enough - if it's used to attack specific known people, maybe not) and realise that a certificate is being served that doesn't have corresponding CT info, but browsers don't check that.

Browser can check that a cert has an equivalent CT Log entry. Chrome does since 2018. https://tools.ietf.org/html/rfc6962#section-3.3 https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...

The ct-policy link you gave and that section of RFC 6962 are about SCTs. The existence of the Signed Certificate Timestamp does not prove the certificate was actually logged, it just proves that the Log promises to log this certificate within the Maximum Merge Delay (24 hours in the case of the Web PKI). A log might in fact be lying or have suffered a grave technical problem.

Figuring out how best to have browsers check the logs are truly accurate while preserving user privacy (e.g. obviously if you call a log to ask "Did you log this certificate for clown-porn.example ?" it gives them a good idea about your taste in circus-related adult content which you probably don't want them to have) is an ongoing topic of research.

With SCT checks you're in very good shape already today - bad guys would need to compromise several distinct entities to successfully pull this off. It's just not quite "Fire and forget" safe yet.

If the certificate wasn't submitted to an otherwise trustworthy CT log server then there's no way to provide an SCT ("Signed Certificate Timestamp") for a qualified CT log server. Some browsers (including Chrome and Safari) expect to be shown qualified SCTs for certificates issued after a certain date.

The SCT is signed by the log, so if you want them to lie you'd need to control enough logs to get enough qualified SCTs. Bad news, for Chrome that means it must include a Google log, which means now you're asking Google to conspire against themselves.

For now you could sidestep this by issuing bogus certificates with back-dated issuance dates. But that will stop working once those dates are too long ago for a certificate to still be valid. I think that happens some point later this year or in 2021 maybe? If you show Chrome (perhaps other browsers but I've read the code in Chrome) a certificate in which the lifespan (between NotBefore and NotAfter) exceeds the maximum permissible lifespan at that issuance date, it treats the certificate as invalid anyway.

This Mozilla isn’t the Mozilla from back in day.

It’s hard to imagine the old Mozilla enabling DNS over HTTPS by default to Cloudflare, with DoH’s tracking issues: https://labs.ripe.net/Members/bert_hubert/centralised-doh-is...

In all countries, giving the government the ability to issue SSL certificates would be a catastrophe in terms of surveillance and censorship.

FTFY

By the way, there have been a number of openly government-operated root CAs in numerous countries for decades. Before I got involved with Let's Encrypt, I was very nervous about government influence in PKI and thought this was quite concerning. (That was also before Certificate Transparency.)

A quick look at a root store turns up

subject=C = CN, O = China Financial Certification Authority, CN = CFCA EV ROOT

subject=C = HK, O = Hongkong Post, CN = Hongkong Post Root CA 1

subject=C = NL, O = Staat der Nederlanden, CN = Staat der Nederlanden EV Root CA [and other roots with the same organization]

subject=C = TW, O = Government Root Certification Authority

I think there are several others, probably especially at the intermediate level.

Just what we need is to get politicians involved in this.

One benefit thought would be they could more easily block access to sites they don't want folks visiting by just denying a CA cert (which would then generate warnings / blocking in many browsers).

One benefit? Did you mean to say "the most obvious downside" instead?

Ok, the more I read answers to my comment, the less I think it's a good idea.

Looks like your browser didn't render the <sarcasm> tags.

> planetary responsibility.

I would like to hear from the planetary president to see what he has to say about that.

Seriously this is all great but unfortunately with all the mess going on with "the big powers" I'm not sure you want to give them that. I wished we lived in a world where we could tho.

Oh, you mean like the state provided service that is trying to sell off the .org domain registry right now?

LetsEncrypt have a backup CA for emergencies such as this: https://letsencrypt.org/certificates/

Here's the best guess what I think would happen:

Some large player - today it'd probably be Google, in the future maybe some other company - or a collection of players would decide that it's in their best business interest not to let half of the open Internet go down. And they'd come to the conclusion that providing a replacement that's basically just "change this url in your ACME software and you can continue do things as before" doesn't cost them too much (Google already runs a CA, as do many other large IT corps) and they should do it.

Oh yeah, it'd be great if Google could MITM half the SSL on the internet...

As I understand it, a CA doesn't have a way of MITMing connections just by virtue of them being the one validating the cert for a certain website. You don't share the private keys of your certs when you generate them[0], you just need for a CA to attest that yes, this certificate's public key is allowed to be used for whatever use you're applying for. ACME doesn't change that, it just allows this verification to be done automatically.

Let's Encrypt doesn't have any more ways of MITMing people using their certs than any other CA - that is, they _could_ do it by generating rogue certs, but that's no different than what Google can already do since they're a CA as well. Plus, certificate transparency logs should make it visible if they ever do so.

0: Barring weird cases I've seen of some companies letting you generate a cert entirely on their website, letting you download the private key once it's done. Which is bad practice for the reason you're talking about right now, since by then you have no assurance that they haven't kept a copy of that private key for later use.

Any CA can sign any certificate they want, including ones they generate themselves. If a bad actor got control of, or even could coerce, a CA, and could do the same for DNS, the end users would be hard pressed to know.

It's a very valid attack, although minimal. To say they don't have any way of MITM'ing a connection is wrong even if it's unlikely.

This is what certificate transparency logs are designed to solve.

Chrome and Safari currently validates that a certificate has been published in the publicly available transparency logs as part of considering it valid.

Either Google doesn't publish the certificate in the logs and it's not valid, or they publish it and people are able to see the misissuance.

It's not foolproof, but it makes the attack even less likely.

> To say they don't have any way of MITM'ing a connection is wrong even if it's unlikely.

I totally agree, it's why I qualified it with "just by virtue of them being the one validating the cert for a certain website" and later on adding that they could do so in other ways, like the one you're suggesting. Reading it again makes me realize that it could be understood that way, though, sorry if I wasn't clear enough. Sometimes not being a native English speaker betrays me a little bit. =)

Wouldn't it be equally easy for a CA to MITM a site that got it's real cert from them vs from a different CA?

CAA DNS records aim to make that more difficult, actually, but otherwise AFAIK you're right. =)

https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...

CAA is for telling competent CAs that you don't want to use their service, so as to avoid them being fooled by bad guys who pretend to be you. If you think their methods are dubious or just won't be effective due to how your names are managed, CAA lets you flag that they shouldn't issue for your names at all.

If a CA is incompetent or malevolent it would just ignore CAA records or not check them at all.

It would be a serious bug if a web browser for example went "Hey this site has a cert from Bob's CA but the CAA records for the domain say only Alice's CA is to issue" and rejected the certificate from Bob's CA. The CAA notice is about allowing new issuances right now but maybe last week when I got this certificate from Bob's CA I didn't set that CAA record so that was fine.

It would be valid (maybe not a brilliant idea, but valid) to set CAA to refuse all issuance, changing it only for a few minutes once a week while you do all your certificate changes.

Oh wow, and here I thought having clients check that record was the whole point, as a layer of defense against rogue CAs. Thank you so much, I hadn't realized. =)

> and could do the same for DNS

Google also controls a major public DNS resolver (8.8.8.8) and the most popular browser.

But hey, y'know, they're the good guys or whatever so I'm sure it's fine. (Probably. Right up until the moment when it's not.)

This is absolutly not how a certificate signing request work at all. Please don't say something so wrong just to scare people, you cannot read encrypted packets just because you signed a certificate.

Cloudflare already MITMs like 2/3 of the traffic on the internet. Personally I'd trust Google more than them. Google may be evil but at least their motives are clear.

> Cloudflare already MITMs like 2/3 of the traffic on the internet.

Cloudflare (MiTM [0] or not) is on record that 10% (and not 66%) of the all internet traffic now flows through their networks.

Ref: https://news.ycombinator.com/item?id=19204085

[0] https://blog.cloudflare.com/keyless-delegation/

Yo, learn how cert signing works. That's not it.

Counterpoint to what you're saying: Any trusted CA can MITM almost any site on the internet (ignoring CA extensions like Name Restrictions, pinned certs, etc). Google has a trusted CA, so while the OP is wrong it's not something they can't do.

That's not how CAs work.

> Oh yeah, it'd be great if Google could MITM half the SSL on the internet...

How exactly would Google MITM half the SSL on the internet by virtue of issuing certificates via ACME?

The private key never leaves the subject's system (the system hosting a website for example). Google would never have access to the private key for which it would issue the public key certificate.

Further, if Google abuses its power by issuing a fake certificate for another website and uses that to MITM all traffic to that website, all browsers and systems would remove the offending CA certificates from their trust store immediately. Look what happened to DigiNotar.

Not that I expect Google to issue fake certs, but DigiNotar also doesn't command 80%+ browser marketshare to soften the blowback.

> Not that I expect Google to issue fake certs, but DigiNotar also doesn't command 80%+ browser marketshare to soften the blowback.

Not sure how that is relevant. DigiNotar was a trusted root CA in all major browsers. So if an attacker managed to get a fake certificate issued by DigiNotar, they could attack 100% of the users visiting the website for which the fake certificate was issued.

In fact, they did issue fake certificates by accident due to a security breach. As soon as the error was caught, their CA certificates were removed from all browsers. They went bankrupt! That's how serious this business of issuing certificates is.

It's relevant because Google isn't likely to remove _themselves_ from their browser, which is currently the most popular web browser on the planet.

For this reason alone, having a major browser dev as a CA is not a good idea, regardless of how much or little you trust google.

Google is already a CA.

https://pki.google.com

These points could be stated for any major certificate issuer. They could encounter an availability issue, bugs, vulnerabilities, etc. The funding model doesn't change these risks.

Are any of the other providers this big? 10% of all websites and growing. If the NSA get hold of the keys then it's just like the old days, or am I missing something?

> If the NSA get hold of the keys

In X.509, the CA never sees the private key associated with a certificate. So while a state actor could always manufacture a “legitimate CA-signed” replacement cert and MITM you with it, they can’t do anything about modern defense-in-depth security approaches like certificate pinning, since it’s the particular public key of the original cert being pinned, not the CA’s authority + CN.

Pinning can be used with anything in the chain not just your leaf.

Some pinning strategies assume a particular CA is trustworthy and pin the public key for that CA, so that they don't need to update with new pins just because they got a new certificate. Obviously you do need to stay on your toes (if you pinned Symantec and then it got distrusted... need to get new pins pronto) but that's true for any pinning strategy. Laziness plus pinning is a bad combination. Like er... keeping tigers as pets and having a toddler maybe?

Considering 90% of websites aren't served by LE certificates, I wouldn't be surprised to hear if one of the legacy issuers had a larger market share.

> https://www.netcraft.com/images/2015/11/certauth_all.png

(January 2015)

It would not work for mass data collection, maybe only on targeted attacks.

> ok I know Apple will stop honoring these starting in the Fall ...

Do you mind expanding on this? It’s not clear to me what status quo Apple will stop maintaining.

Starting September 1, Safari will not honor new certificates that have validity periods longer than one year. I don't have a link to their documentation because the announcement was reportedly made at a face-to-face meeting at the CA/Browser Forum in February. https://www.thesslstore.com/blog/ssl-certificate-validity-wi...

Safari will will no longer be honoring certificates valid for more than 13 months starting September [0]

[0]: https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_...

> I shudder to think about what will happen if they go down for whatever reason.

We would quickly see article and reminder that free means you are not the client :)

Just recently I had issues with Lets Encrypt bot. Apparently on new version of Centos it craps out with some incompatible python libraries. Once I fixed it it turned out I am blacklisted from requesting new certs for 7 days, per their rate limits. That made me come back to drawing board for 60-some domains I ran and just purchase the damn certs. They so cheap these days unless you ran a hobby website its just not worth the savings.

> it turned out I am blacklisted from requesting new certs for 7 days, per their rate limits

The rate limit for failed issuance is one hour, not 7 days. The 7 day rate limit applies when you successfully issue 5 identical certificates; then you have to wait 7 days more to issue a new identical certificate.

https://letsencrypt.org/docs/rate-limits/

It's unlikely that you would be subject to the 7 day duplicate certificate limit due to a Certbot dependency problem, because the dependency problem would have to allow Certbot to obtain the certificates correctly but fail to save them properly.

(Source: I'm a Certbot developer.)

I should also add that I'm really sorry that you experienced an installation problem on CentOS. Dependency and packaging problems continue to be a challenge for Certbot and our colleagues are still trying to find a more universal solution to them (probably involving snaps).

I had similar problems with that bot recently (i.e. the python bot "certbot"), so I looked around and found a very nice alternative named PJAC[0]. I have now switched a bunch of my domains to use PJAC, and so far it works like a charm. Its only dependency is Java (version 8 or higher). Everything else is bundled in the downloaded artifact, just as it should be.

[0] https://github.com/porunov/acme_client

I’m a fan of acme.sh [1]. It’s a battle-tested Bash script that handles many different use cases, including many DNS providers if dns-01 is how you roll.

I run my own DNS server using Knot and acme.sh supports it.

[1]: https://github.com/acmesh-official/acme.sh

The worst thing that could happen is a concern taking them over with select malicious intent.

There's nothing a malicious actor could do by taking over LE that they couldn't do by buying a lower-profile trusted CA more cheaply. LE does not have access to sites' private keys, for example.

The same rule as for any critical system applies: Make sure your site uses 2 ACME providers and implement fallback on failure.

The default setup is to renew 30 days before expiry. If it fails at that point, you still have 30 days for your "fallback" to kick in.

I'm not sure it's worthwhile that your fallback is either ACME or automated. In fact, the failure isn't even one that should page anyone in the middle of the night; 30 days gives enough time to manually sort things out during regular work hours.

Sure. However, it costs nothing to have multiple providers with automated retries and fallbacks.

I like my automated functions to stay that way as long as possible!

Redundancy of suppliers (of anything) is a general good practice.

Who else provides free ACME other than let's encrypt?

Buypass does ACME—https://www.buypass.com/ssl/products/acme

Reply on news.ycombinator.com