Why I won’t use Let’s Encrypt(stargrave.org) |
Why I won’t use Let’s Encrypt(stargrave.org) |
Half of it is about not wanting to pay $$$ for certs, which is really irrelevant if the question is why not use lets encrypt,not why not use some other service. The author also seems to be arguing at the same time that the webpki threat model is both too strict and not strict enough, which doesn't make for the most compelling argument (pick a side).
The only reason given for not wanting let's encrypt is that its usa based, and the author doesn't trust the us government. However the author totally ignores the primary control against that - namely certificate transparency, and the idea that even if us government has this capability (big if) they can only use it once and you're probably not valuable enough.
I think this statement does require some support, and the explanation for why the writer can't support it is both intentionally vague and conspiratorial.
However, exposure to certificate misissuance risk, including intentional misissuance demanded by a government, is based on relying parties (users) accepting a particular CA, not based on subscribers (web sites) choosing to use that CA. If your site's users trust signatures chaining up to the Let's Encrypt X1 root, there is nothing you can do to stop those users from accepting any potentially-false certificates for your site issued under that root, even if you had nothing to do with the issuance of those certificates.
A famous example of this is the DigiNotar and Comodo attacks, where someone who wanted to help the Iranian government spy on people caused misissuance of certificates for the domains of some major web sites. Those web sites were not customers of DigiNotar or Comodo, but the attacks worked anyway.
In the NOBUS scenario, some part of the U.S. government decides to exploit its jurisdiction over Let's Encrypt (or one of the dozens of other publicly-trusted CAs located in the United States). (Edit: or, it contrives to get insiders working in those CAs to help it bypass their issuance rules and safeguards.) Just as with the DigiNotar and Comodo attacks, this attack would work regardless of whether the target web site is a Let's Encrypt subscriber or not, as nothing technically prevents Let's Encrypt or other U.S.-based CAs from misissuing certificates for any domain name whatsoever.
CAA doesn't stop this because the CAA standard specifically says that CAs should check it for issuance, but browsers should not check it when accepting a certificate. (One reason for that is that the CAA records could change over time, so a CAA record could have permitted issuance when issuance took place, even if it doesn't permit it now.)
CT makes it possible to detect this, regardless of what jurisdiction the misissuing CA is located in or what the reason for the misissuance is, if the subscriber is monitoring CT. Thanks, CT inventors!
In conclusion, although it's somewhat counterintuitive, even if you fear that the U.S. government will try to attack your users through the PKI system, you could choose to use a U.S.-based CA, without significantly increasing the risk of an attack.
There is also a publicly-trusted CA based in Norway which offers free certificates using the same protocol as Let's Encrypt, so you can use the same client software with it:
https://www.buypass.com/products/tls-ssl-certificates
Their free certificates are more limited in various ways than Let's Encrypt's, but if you're running a single site, they should work great.
I would fully agree with the original author that CAs should be held to more scrutiny, that it's kind of sad that they typically can't provide extremely high-assurance or meaningful verification, that other systems for encryption and authentication are useful for their own purposes, and that it would be good to have more alternatives to Let's Encrypt based in more jurisdictions.
Could the nsa/fbi/cia/etc force lets encrypt to mis-issue a certificate for some domain at the point of a gun? Sure.
Certificate gets logged in cert transparency logs (required for browser to trust it). If someone notices everyone knows, huge outcry. Sure they could do it once, but how would they do it a second time? It would have to be a very high value target to be worth it.
Uh... okay...
The argument that if you create a key and put it on a VPS or shared service is effectively giving it to the service provider is true. But what does it matter. If you don't have an element of trust with your provider than where you hosting with them? And if you're that worried about it why not do full disc encryption on top of it all?
It does not necessarily solve the problem. The provider could steal the keys in memory when the disc is accessed. Anyway, hosting stuff at home does not fully solve the issue: you still have to trust your machine's firmware / hardware. So… HTTPS should never be used?
The only guarantee HTTPS gives is that the communication between the client and the server is encrypted, not that the server is not compromised. HTTPS does not worsen the situation. Nobody should use HTTPS for authentication, that's not what it is for (edit: well, except the bit about domain ownership, agreed)
Compare that to pure optimistic encryption which has very different properties than https.
[P.s. If anyone says OV and EV certs... those haven't been very effective so im ignoring them]
> If I give TLS private keys to the hosting company, then what is the point of using TLS and lying that it can authenticate the endpoint domain?
If your ISP wants to get a TLS certificate for your domain, they can, because they are in the last-mile MITM path against you and can use that to authenticate domain-validated certificates under the Baseline Requirement rules. Your ISP is not part of the threat model that the Web PKI tries to defend against. It doesn't matter if they have theoretical access to your private keys.
> Possibly there is already IPsec transport session, transparently securing the link.
Not unless you set that up with your users. The point of TLS is that it is supported everywhere. IPsec is an explicit protocol (and a bad one at that) that requires a ton of manual configuration and makes no attempt to make anything automatic or to authenticate anything... unless you just use x.509 certificates, and then we're back to the same model as TLS.
> Neither they, nor those CAs really care about security – it is just plain old business.
They care about security because if they fail at security, their roots will be removed, destroying their business. This has already happened multiple times, even for big players (e.g. Symantec). That's the whole point of the BRs.
> Current global-scale PKI system, integrated by default in most software, literally tells that some dozens of CAs, and several hundreds of intermediate CAs can authenticate entities (like Internet domains and so far). There is no reason for me to spend my money paying one of chosen CAs, because any of hundreds CAs beside can issue "valid" certificate for MitM-ing connections.
And that's still better than me being able to MitM your connection without any outside help just because I hopped on the same WiFi as you.
> So paying for the domain’s certificate just gives ability to show some green bars in the browsers, but the whole system does not prevent its MitM-ing by another authorities anyway by design.
It prevents MitM-ing by end-user ISPs, by rogue access points, and much more. It's not perfect. It's a lot better than nothing.
In addition, thanks to Certificate Transparency, you can monitor if one of those CAs has issued a fraudulent certificate in your name. Browsers won't trust certificates that are not publicly logged.
> I can get trust to some authorities, but not the hundreds of them.
Then do what I do and remove the ones you don't. I only have 29 CAs in my /etc/ssl/certs/ and a few more enabled in NSS, and almost everything works fine. Throw in the big players and 99% of the internet works without issue, and you can ignore all those country-specific (or worse, government-affiliated) CAs and lower your attack surface.
> I used to use CAcert because of that. But here comes politics and business again! CAcert is not included in most major operating systems. Who wants to loose their business when someone does it for free? There were other gratis CAs, that also were not included in OSes. Why? US-based software vendor companies will give many reasons, but actually there is only one uniting them all: all of these free CAs are not based in US, so do not obey their jurisdiction.
CAcert had some significant operational issues and could not pass audits. There are free CAs operating outside the US.
> Actually for some time they were indeed included in many trust anchor bundles out-of-box. But soon all of them were removed... and there suddenly appeared Let’s Encrypt (LE), that relatively immediately was praised by all major software and hardware vendors and included everywhere. Just a coincidence? Instead of having certificates spread among many CAs under various jurisdictions, that ingenious move with gratis ultimately trusted CA lead to the world where prevailing majority of all certificates are issued with single CA, based in US (at last).
Or perhaps because LE has vastly better and more secure infra than CAcert ever did.
> LE is clearly a NOBUS project.
Tinfoil hat mode engaged...
> Specifying LE in CAA means that I authorize noone to issue certificates for my domains, except for US-based forces. That is something I will never do, being the citizen of completely independent jurisdiction. I am not a traitor.
Then maybe you'll trust an ACME CA in Austria:
Or one in Norway:
https://www.buypass.com/products/tls-ssl-certificates/go-ssl