Ask HN: Is Let's Encrypt the new swiss crypto ag? | Hacker News Reader

Ask HN: Is Let's Encrypt the new swiss crypto ag?

18 pointsCoxa22 comments

Just wondering ... it does seem less far-fetched in the light of the swiss crypto ag revelations.

Are you familiar with how certificates and CAs work in general? You don't receive a certificate from the CA, they just sign and attest that the one you made is owned by you. The ways CAs go bad is not breaking any crypto but by signing a certificate that you don't own. This vulnerability is well known and LE takes industry-leading steps to mitigate it via the certificate transparency program which is a permanent auditable log of all certificates they sign.

From my understanding of the certificate transparency program does not mitigate the threat of them simply not disclosing a certificate they signed. Ultimately this still gives them MitM capabilities as long as they control the traffic or am I mistaken?

When certificates are submitted to CT logs, they are given Signed Certificate Timestamp by the log, which can be attached to the certificate. Chrome and other major browsers require that every certificate has them attached and signed by a trusted log operator, guaranteeing that each certificate is submitted to a CT log.

https://github.com/chromium/ct-policy/blob/master/ct_policy....

Seems like this is currently disabled in Firefox [1]. Do you have any sources for Safari or MS Edge?

[1] https://wiki.mozilla.org/PKI:CT

Yes, this property (CAs are capable of creating and signing near-arbitrary certs) is inherent in the concept of Certificate Authorities in general, and the log doesn't automatically fix that because nothing can. But auditors regularly check served certificates against these logs and report unlogged certificates automatically. This can be verified in your browser with things like OCSP stapling.

You may find this useful: http://www.certificate-transparency.org/how-ct-works

Actually some (popular) CA's can generate the cert on their side and let users download it. Not allowing this insecure practice is one more point in which LE is ahead of the curve.

Why are you specifically targeting LE with this post? Why not other CAs?

Because I want to use LE and not other CAs.

That's misguided (I'm assuming you're the server admin).

Whether you use any specific CA, like LE, or not, has no security impact.

It's about what your users trust and you don't control that.

In an ideal world I would say you're right. In practice they don't even know who they trust.

As a centralized piece of software that has made itself responsible for safely massaging millions of private keys, certbot would certainly be a juicy target for NSA to compromise.

Betteridge's Law says "No" ... and given certificates are generated locally, I don't see how the certificates themselves could be compromised. The trust in a certificate (or trust in a false certificate) could potentially be manipulated in by and upstream party.

The 'law' is more of an observation and generally applies to headlines. I feel you are being overly dismissive, as a question is being asked is in a dedicated section. There have been instances of CA's, most notably Symantec, which have turned out to be bad apples. There is a constant stream of news dispelling myths surrounding seemingly reputable firms regarding encryption/privacy. Whether these incidences are related or not, discussions like these need to be afforded a lot more leeway than most, and fleshed out, rather than being stifled.

I'm not arguing against having the discussion ... my point is that trust in any certificate is reliant on its chain-of-trust and so if Let's Encrypt has this problem, you can't trust other certificates either. But the implication in the head-line is that the NSA/CIA are controlling Let's Encrypt. If that's true, then we've got a real problem ... on the other hand, I think other CAs have shown that, through incompetence or malice, they can't always be trusted either.

> if Let's Encrypt has this problem, you can't trust other certificates either.

To be perfectly honest, I don't really trust the other certs, either. I mean, I pretty much have to, and having a mainstream CA sign a cert does provide a bit of reassurance -- but only a bit. I don't really consider CA signing to mean that the cert is "trustworthy", because I don't really trust those CAs, so if they're the anchor for a chain of trust, then the chain of trust is weak.

HTTPS certs provide extraordinary limited security in any case, there is no need to single out lets encrypt.

If you can receive a http request destined to the target domain (e.g. via MITM near the real target, DNS hijacking, or route hijacking, or MITM near a CA) then you can get a cert issued for that domain by pretty much any popular CA.

With security so limited what would be the purpose of compromising lets encrypt?

Massive downvotes but no responses.

Is it because you accept that the security provided by HTTPS is limited but don't like people calling that out?

It's better than nothing. But it is my perspective that as technical experts any time we are not absolutely frank about the limitations of the current model against powerful MITM attackers we are behaving unethically.

There is absolutely no reason for any major state attacker to compromise letsencrypt. Beyond the weaknesses I enumerated above state actors have their own CAs which are accepted by browsers and pinning is effectively dead ( https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse... ).

What exactly could a state actor hope to accomplish by compromising letsencrypt that they couldn't already do more easily and stealthily?

I suppose it would be trivial for them to issue compromised certificates or record the private key in a targetted attack for a specific domain without anyone noticing.

During normal certificate issuance, they do not generate or see the private key, so they can't compromise the certs they sign for you.

Like any other CA, they do have the technical ability to sign arbitrary other certs, so could issue a cert for MITM. As some other comments show, certificate transparency is starting to reduce this risk.

LE does not see the private key but certbot does. Who audits certbot?

Anyone. It's open source. You can if you'd like.

https://github.com/certbot/certbot

Would be trivial except for the fact that they don't issue certificates.

Reply on news.ycombinator.com