> HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE.

Well where are all the other free SSL/TLS certificate providers, then?

ZeroSSL sometimes gets mentioned, though they are also pretty keen to charge you, which is the exact reason why many go for Let's Encrypt: https://zerossl.com/pricing/ (admittedly, they're much cheaper than most alternatives, but you can't beat free)

Most of the other paid providers out there do see like they're just running a racket in comparison:

  https://www.ssl.com/certificates/basicssl/
  https://www.digicert.com/tls-ssl/basic-tls-ssl-certificates
  https://www.godaddy.com/en-uk/web-security/ssl-certificate

It's an order of magnitude more expensive than just getting a domain, my expenses would be in the hundreds of dollars per year if I wanted to get the certificates from them, which I can't really afford while working in Latvia and having 30+ sites to manage across different domains.

Let's Encrypt works and once it stops working (should that ever happen, which you kind of need to include in your risk analysis), I'm kind of screwed.

well, to be fair, https://zerossl.com/pricing/ has a "free" column :)

On the other page, https://zerossl.com/features/acme/ it looks like free acme certificates can have a wildcard records (*.example.com).

https://www.sslforfree.com/ claims they use zerossl and support wildcard records.

Also, one of others you mentioned also has a free acme option, but without mentioning wildcards: https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certifi...

Upon a closer look, it indeed seems that the certificate count limitations apply to the manually requisitioned certificates, not the ACME ones:

> By using ZeroSSL's ACME feature, you will be able to generate an unlimited amount of 90-day SSL certificates at no charge, also supporting multi-domain certificates and wildcards. Each certificate you create will be stored in your ZeroSSL account.

So I guess that's a viable option.

I may be wrong, but as I understand it HTTPS connections typically use an ephemeral key with the certificate used to authenticate the servers identity.

So simply having the certificate does not mean one can read the traffic without conducting a man-in-the-middle attack.

This means that anyone who could read traffic from a HTTPS connection could read it from a HTTP connection just as easy.

The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why?

Not just typically. All the uses, even with older protocols, use ephemeral keys to secure the HTTP transaction.

Even the most awful RSA kex (using the RSA algorithm to just encrypt a random key and send it to the other party, rather than doing a Diffie-Hellman key exchange of any kind) is still ephemeral keys and still cannot be decrypted by a CA. It's terrible because it has no Forward Secrecy, but it would not fall to this imaginary attack.

With Forward Secrecy (always in TLS 1.3 and if you didn't deliberately choose insecure options in TLS 1.2 and earlier) even if your adversary kept a transcript of the encrypted transaction and they later obtain your actual private key, that's still no enough to decrypt the transaction because the transaction key was ephemeral.

In fact the CA deliberately by policy must not have the private key needed to do more. If anybody has evidence of a present day Certificate Authority either asking for their private key [other than for a "Key compromise" type event where the certificate gets invalidated] or of them providing a mechanism by which they "randomly" choose your key and would have an opportunity to just remember it - tell m.d.s.policy https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Your processes shouldn't open you to such an attack (private keys should ideally never leave the machines using them) but it's also policy that the CA shouldn't want to ever know these keys. Not least because this would make them a target.

Just to be complete: it’s not that the key is ephemeral, it’s the way it’s agreed upon. The symmetric key is never in the communication stream.

> The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why?

In fairness it should be more of "everyone uses a master lock, some people can open master locks, please consider not making master locks own 90% of the locks"

I believe there's three or four well accepted ACME providers now, which is why a lot of tools now support or even default to alternative vendors, partly to mitigate this concern. e.g. acme.sh will try ZeroSSL first, Caddy will rotate between ZeroSSL and Let's Encrypt.

acme.sh moving to ZeroSSL has nothing to do with increasing variety.

acme.sh moved to ZeroSSL as default due to being sponsored by them.

my primary reason for avoiding ZeroSSL is the requirement of providing an email address to them that can be abused.

Caddy doesn't require an email address for ZeroSSL (but we still strongly recommend that for troubleshooting sake).

Yes, there is a certain measure of trust going into parties like Let’s Encrypt, but I don’t think it’s as bad as you are saying.

• A CA can’t intercept anything based on your using them.

• A CA can refuse to issue a certificate for your site, but if this got out (which it would), it would significantly damage their reputation and I don’t think it will ever make sense for them to unless legally compelled. In that case, there are other providers, unless legal compulsion has removed them too, in which case the world wide web is dead anyway, so this is not worth worrying about.

• A CA can issue a false certificate for your site. There is, however, a non-trivial risk of them being detected in doing this (much smaller for small sites, but the system is set up in such a way that almost anyone can check and detect most instances, and I think you can be reasonably sure Let’s Encrypt specifically is being monitored for suspicious patterns by multiple parties that have vested interests in the system running smoothly), and if it did get detected, they would certainly be subjected to extreme scrutiny, so that any more instances would be very likely to be detected, and if a good explanation was not provided in short order (and even then it wouldn’t be too easy to recover), they would be dead, though it would certainly be a period of great pain for the web. In other words, not only does the potential upside of cheating go up, but also the downside.

I don’t think your conclusion that you should support HTTP is reasonable.

Even better, maybe add TLSA records too! TLSA when combined with DNSSEC can replace the need for Certificate authorities. If you want to show independence from CAs, that's one way to do it.

TLSA replaces certificate authorities like LetsEncrypt with DNS registrars, and, in the process, gives up certificate transparency and the rest of WebPKI surveillance; WebPKI surveillance has resulted in the termination of some of the largest certificate authorities, for misissuance; meanwhile, your browser can't terminate the TLD operators. It's not a good tradeoff.