Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I love the creativity and historical value of the open web, but I don’t get this anti-HTTPS stance. These days, it is easy for site administrators to upgrade to HTTPS without modifying their content.

Get a free certificate from Let’s Encrypt, set up redirects, and then add the Strict-Transport-Security header to further secure the site and reduce network traffic from the redirects.

Your only new external dependency there is Let’s Encrypt, which is run by a non-profit. And if you’re ever unhappy with them, you can always switch to another provider and most people won’t even notice.



> Get a free certificate from Let’s Encrypt, set up redirects, and then add the Strict-Transport-Security header to further secure the site and reduce network traffic from the redirects.

If you want to be inclusive of old clients that may not be able to do modern TLS, you can serve the same content on http and https, but reference your favicon on https and serve a STS header with it. Clients that understand STS, will internally redirect to https, clients that do, but can't reach your https for whatever reason, will be able to continue with HTTP.


I'm sympathetic & way more agree than disagree. But DNS doesn't fill me with joy. It's quite centralized, quite a huge organizational vulnerability.

If we had some alternate addressing schemes in the browser that could do trust, I'd be much happier. Like, can dat protocol be a secure origin? Or like, if the goal really is just to secure users, maybe we need to let opportunistic encryption be something users can opt in as secure (even though it can be mitm'ed at the start).

Let's Encrypt has changed the game. It's great that https has so very very suddenly gone from frustrating & business class only to something even the casuals can easily do. But still, I'd love some less centralized systems for trust to be available, some visible known alternative paths demonstrating that there are diverse options at these lower transport/security layers of the network stack.


Let's Encrypt doesn't work with cPanel shared hosting. A lot of cPanel providers have free certs thanks to AutoSSL but many do not (such as Namecheap). A lot of the obscure web runs on shared hosting.


> Let's Encrypt doesn't work with cPanel shared hosting.

Yes it does: https://blog.cpanel.com/how-to-configure-and-manage-lets-enc...


No, it does not, when the cPanel provider disables AutoSSL and doesn't install the Let's Encrypt plugin, which is a lot of them, including Namecheap.


That's like saying "Linux doesn't support GUI programs." and when someone says yes it does, saying "No it does not, when the admin sets it up without X or Wayland installed."


The Let's Encrypt extension is not installed by default and needs to be explicitly installed, and I've never seen a cPanel provider that has it.

You can't use ACME to get a cert without said extension.

Perhaps it would be more accurate to say that in practice in general Let's Encrypt is not usable with cPanel providers.

In the context of this conversation, people were talking about how Let's Encrypt certs can easily be used to enable HTTPS, and my point is that that's rarely possible with cPanel hosts.


Will that “non-profit” be ok with my site raving about Russia’s involvment in Ukraine? What about a fan website for the Iranian Ayatollah? Or a website describing in detail Taiwan’s vulnerable targets just as China is about to attack them?

Chances are that the answer to all those questions is “no, the Western-run Let’s Encrypt will not be ok with all that” and if it were for the push to come to the shove (or whatever the expression is) they’ll be more than glad to invalidate that certificate (or worse, to compromise it without letting you know).

Granted, the same thing will most probably happen with one’s DNS provider and with his/her ISP, but why have another dependency if one can avoid it?


Let’s Encrypt was created in part to take humans out of the loop where possible. LE does not review your site and that is made obvious by the speed of getting a certificate and the automated renewals, etc. They aren’t aware of you unless there’s a technical error or you’ve made headline news.

That said, I agree with you that there is some level of risk here, even if it is small. That’s why your ability to switch is so important. Even if they became aware of you and they decided to revoke your certificate, you would just switch providers. Because of that, they have no meaningful power over you. If it ever becomes difficult to switch, then things are getting bad.

> or worse, to compromise it without letting you know

What does that mean? The certificate either passes validation or it doesn’t. They aren’t able to change the content on your site or anything like that.


>What does that mean? The certificate either passes validation or it doesn’t. They aren’t able to change the content on your site or anything like that.

They could say that your certificate passes validation while, in fact, said security has been already tampered with on your side, giving your website's visitors a sense of false security.


> They could say that your certificate passes validation while, in fact, said security has been already tampered with on your side, giving your website's visitors a sense of false security.

This isn't how the Web PKI works. In order to tamper with your site's traffic, Let's Encrypt (or another CA) would need to issue another certificate for your site with a key that they (rather than you) control. This would be detected via CT[1], which your browser (unless it's Firefox) is already using.

And note: by design, any CA in the trusted set can already do this, regardless of whether you use them or not. The things that are stopping them are that it's (1) not in their interest to do so, (2) it's detectable due to CT, and (3) would result in their root being hell-banned by the browsers.

[1]: https://certificate.transparency.dev/


I was thinking of actions taken by state actors in the context of the current geo-political climate. As such (1) can be easily brushed-off if a national security letter from a 3-letter agency is in the mailbox, (2) is debatable, but looking at that "transparency list" I mostly see Western companies, companies which I suppose are also subject to that kind of correspondence, as for (3), afaik two of the biggest browsers now on the market are controlled by companies actively working with the US defence apparatus, including Google [1].

[1] https://www.nytimes.com/2021/11/15/technology/google-ai-pent...


Again: this has nothing to do with LE; any CA can issue any certificate at any time by design, and it's the responsibility of the CT scheme to detect misissuances and malevolent behavior.

A NSL sent to the operators of a CT log cannot stop the log operators from logging inauthentic certificates: each CT log is a timely and append-only signed ledger of all certificates issued, meaning that any deviation between logs would also be detected and treated as a sign of mis-issuance or compromise by the larger Web PKI. What's more, certificates need to be logged as a matter of validity: an order compelling log operators to refuse a certificate would effectively ensure that the certificate never becomes valid. That's what makes CT nice: anybody who wants to create a malicious certificate needs to do so in a way that's globally detectable.

It can be fun to play mind games about shadowy agencies, but that's not really how these things work: if you're of sufficient interest to a country's intelligence service, then they're going to spearphish you, exploit your phone, steal your TLS session keys, your cookies, or do any number of other much less visible things to get the access they want. And, if they're competent, they will get it[1].

[1]: https://www.usenix.org/system/files/1401_08-12_mickens.pdf


Has Let's Encrypt ever shut down someone's ability to get a certificate over independent editorial concerns?



Being designated on the SDN list is not an "independent editorial concern." It basically makes the entity toxic to any US-based business or service.

A full explanation is available on LE's forum[1].

[1]: https://community.letsencrypt.org/t/according-to-mcclatchydc...


IIRC they either outright refused to provide a certificate to KiwiFarms, or have close enough ties to ISPs who cut them off that applying seemed like a non-starter.


Do you have a source? Some quick searching only brought up cloudflare dropping them.


Not to hand, and if I did it would probably be a post on the forum itself, which, well, you see the problem.


I would go ahead and hazard that “major DV CA refuses to validate controversial site” would be major news.

There’s no evidence that LE has ever done this, much less ever considered it, much less even has the basic technical ability to manually intervene in the DV process.


Hardcoding a check for whether the domain is a particular fixed string is trivial. Any competent technical organisation can do that in less than a day. Yes it wouldn't be principled or elegant, but it would work.

Currently LE looks like neutral infrastructure that would never do such a thing. But so did CloudFlare, right up until the point where they suddenly weren't.


I don’t think it makes sense to compare a for-profit content delivery product with a non-profit CA. They fill different purposes, and exist under different regulatory and incentive models. They don’t do remotely the same things, and don’t even have the same basic “profile” (one being an active network participant, and the other being a static participant in the PKI).

Again: this entire thread exists because you (baselessly and incorrectly) speculated that LE has censored people. We’ve now moved on to baselessly speculating about what LE could do, which is approximately as useful. Which is to say: not.


I made it clear from the start that a) this was a partial recollection b) it was entirely possible that it hadn't got to the point of physically attempting to issue a certificate. It was definitely a topic that was dicussed on KF, and a part that I do remember clearly is that LE's terms permit them to choose to refuse service to entities based on the content of what those entities are serving. And it's very obvious that it would be technically possible for them to do so, contrary to what you ("baselessly and incorrectly", if we're going there) suggested in your last reply.

If LE wanted to make a clear committment to content-neutral operation it could do so. It has taken a different tack in its ToS, even if it hasn't been pushed to the point of applying that in practice yet.


CloudFlare never looked like neutral infra, since they control the traffic so they need to (from a legal standpoint at least) block certain things. There has always been things cloudflare would not host.

CA:s do not control the traffic, they just say if a key is associated with a domain.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: