I'm always baffled by people arguing that we shouldn't use HTTPS. Have these people forgotten the times when mobile providers would "optimize" images (=compress them to death) or even insert advertisements? Or the times when simply being on the same network as someone with alterior motives could lead to your credentials being stolen?<p>I get it, certificates are hard, but having free certificates by Letsencrypt has probably been one of the most beneficial things that happened to the Internet in the last 10 years. If someone doesn't like it, please put in the work to come up with a better solution, not arguing for an even worse solution.<p>The author of this article doesn't propose anything workable. Mentioning SSH is ridiculous, it's not meant to access servers you don't know. Also, I have seen more than a few sysadmins who would easily be tripped up by a MITM because they'd just wipe their know hosts file at the first sign of trouble. And these are TRAINED people.
TLS solves <i>two</i> problems, but was originally designed to solve <i>three</i>. The author seems to be annoyed that it does not solve the third problem.<p>TLS (or SSL, really) was designed to solve trusted authentication - that you could be sure the website that responded to your request was your bank. The idea was that a manual review from an authority would verify that the owner of certificate x was the "real" y, for some definition of x, y, real and authority.<p>It does not solve that problem, I agree.<p>It does, however, solve two other problems: The problem of message integrity - noone intercepted and changed this message between server and client; and the problem of eavesdropping - noone can read the message by observing the network traffic alone.<p>Now, of course, this all depends on the fact that the connection was setup correctly, and a man-in-the-middle attack that can redirect all the traffic for some domain to their own servers would <i>possibly</i> succeed. But that is quite a high bar! Modifying DNS or shaping network traffic in that way requires deep access, and is much, much harder than attacks with no SSL/TLS.
The author recommends TOFU as an alternative. TOFU is great until it isn't. Web servers do get hacked all the time (mostly thanks to Wordpress), and when they do, rotating any and all private keys is high on your action list (preferably through nuking the machine from the orbit).<p>The short expiration date on the certificate is specifically meant to address this problem. CRLs don't work, not even by principle - how often are you meant to refresh them? Who's volunteering to handle the load?<p>Which circles us back to the underpinning of the fundamental problem: DNS is insecure. If DNSSEC was to be the answer, where is it, 20 years in? Can we pretty please adopt DNSCurve instead already?
> And, as always with the certificate authorities, a thousand murderous theocracies, advertising companies, and international spy organizations are allowed to impersonate you by design.<p>Certificate transparency has been required by chrome for new certificates (and sites that opted in) since 2018, and all older certificates expired by 2021 (because certificates have a maximum allowable lifetime). So this was dubious even at time of writing, and outright false today, for a large majority of users.<p>> Let's Encrypt isn't free to run, either. Their 2019 operating budget is 3.6 million U.S. dollars. Most of that is donated by… guess who? Your competitors.<p>Let's Encrypt has something like 80 sponsors listed. The vast majority of them are not, actually, competing with you. Even if some of them are, the nature of a non-profit funded by a wide range of sponsors just makes it a terrible way to attack someone.
> <i>The certificates provide no security</i><p>Uh... it guarantees that the entity you're communicating with is the one with control over the web server you're trying to access.<p>The points about HTTP are worthless. Everyone's web traffic should be E2EE for everything. I don't understand someone arguing that it should be possible to spy on other people on your network.
While some of this article makes sense, it is full of exaggerations and outright lies.<p>If you want longer-lived certificates manually, don't use Let's Encrypt. Why pretend that no other issuer exists?<p>> You don't have to use certbot (...) you can renew certificates manually<p>Or use a different client? Do we pretend these don't exist, too? <a href="https://letsencrypt.org/docs/client-options/" rel="nofollow noreferrer">https://letsencrypt.org/docs/client-options/</a><p>> If you have a hundred websites, then on average that's four hundred renewals a year—more than one every day. Every single day. For the rest of your life.<p>Right, because you can't renew more than one on the same day? You can't do your 100 renewals and go on vacation for 90 days? Why not? That's just not how averages work.<p>> Normally, when a site changes URLs, you can use a redirect to send visitors to the new address. But, if the old address is HTTPS, that doesn't work: the old address will display a misleading security warning instead of redirecting.<p>That too is an outright fabrication. I just tried a 301 redirect from HTTPS to HTTP and it worked fine, on up-to-date Firefox, no security warning. Maybe the author promised to never get rid of TLS with a `Strict-Transport-Security` header? Don't do that?<p>> When you install a certificate with a three-month expiration date, you're saying “I want my website to break in three months unless I show up and tell it not to.”<p>Is that how you feel about permits, licenses, subscriptions? Fixed-time contractors? A "real engineer" wouldn't use anything time-limited?<p>> save the certificate permanently the first time you connect<p>That's the final recommendation? After the author concluded that "certificates provide no security" in the second paragraph because they might man-in-the-middle the challenge? Are we supposed to ignore that they might man-in-the-middle that first connection?
I think the true problem here is associating the word secure with https. It provides a false sense of security when the site served over https is a scam or phishing site, but very few non-technical users understand the difference.
The really annoying thing is how browsers treat self-signed certificates as some dangerous thing, when it's really much safer (no MITM or eavesdropping) than http.
> The official way to renew Let's Encrypt certificates is automatically, with a tool called certbot. It downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root. If that sounds dumb, then good for you, because it is.<p>I'm a bit confused by this. I use Caddy, and Caddy doesn't run in root – and Caddy is able to handle automatic Let's Encrypt certificate renewal.<p>Why does certbot need root?
The MITM observation isn't any more dangerous than Trust on First Use. The attacker would have to identify you as a target and set up their MITM before you got around to setting up your own cert. Sort of like an attacker compromising your SSH server before the first time you got around to connecting a client and trusting the key.
Thought-provoking. I didn't consider why LE is free (sponsored by Google and AWS) and that it can technically change that at any time. I'm still going to continue using HTTPS for now since it's my status quo, but I guess, for public websites, the choice to use HTTPS or not depends on whether or not one agrees that widespread HTTPS is vital to discourage ISP/government snooping.<p>I disagree with the TOFU recommendation, though. From my knowledge, it kinda works for SSH since you're mainly connecting to servers you control; not so much for the WWW. Anyone remember MonkeySphere? I also disagree with the 3-month criticism. I think LE has a good justification for it: usually, renewal is either automated or forgotten about, so a short timespan forces automation. The bomb analogy doesn't really make sense as certificate expiry serves a practical purpose unlike a bridge-bomb.
Everyone that uses letsencrypt has a cron installed to auto-renew. Certbot needs two permissions to work:<p>1. perform the necessary verification, of which there are many, placing a file on your website is just one possibility.<p>2. place the generated certificates in some location where the webserver can read them.<p>Neither of these steps requires root if you know what youre doing.
Unfortunately by this point is a losing battle, most techies have been conditioned to believe that serving unencrypted raw HTML, HTML which contains no confidential information in it, might as well make the Dark Forces of Evil win. "What if someone MITM-es your recipes blog?".<p>Of course, it just happens that this let's encrypt push puts even more power in the hands of Google, the owner of Chrome. I would have said something about that, too, but yesterday someone re-posted the HN guidelines and I'm not up for another fight with Google engineers comp-ed 600k and up, engineers who are very eager to anonymously defend their employer online.
> The way you verify your identity to Let's Encrypt is the same as with other certificate authorities: you don't really. You place a file somewhere on your website, and they access that file over plain HTTP to verify that you own the website. The one attack that signed certificates are meant to prevent is a man-in-the-middle attack. But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop.<p>Doesn't ssl handshake require knowing the private key?
OP keeps repeating tha Google is making money from certificates. I don't think Google sells certificates, and even if they do the revenue is insignificant for them.
Does anybody know what OP may be referring to?
Can't say I fully agree, but I definitely share the sentiment. Let's Encrypt is a nice hack, not a long-term solution. We need DANE.<p><a href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...</a>
Even worse, HTTP/2 and HTTP/3 (and basically every new web technology) is only usable over HTTPS. I'm seriously starting to question the agenda behind this, this is not beneficial to the users in any way.<p>Self-signed certs should fine (if you validate them initially) but browsers make self-signed sites almost impossible to access, relying on Let's Encrypt or being subject to extortion is a shameful state for the web.<p>Also, what's with the ever-shrinking renewal periods? Why can't a certificate be valid for 10 years? They can revoke it anyway if it's been compromised or whatever.
I'm also not a fan of LE, for some (but not all) of the reasons stated here. I particularly hate the short cert lifetimes (that they intend to make even shorter).
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop.<p>I guess? But they later state that SSH's trust on first use is the solution... which has the same problem. Am I connecting to the real bank website or a fake one? Who knows! But I'm going to trust it forever.<p>Additionally, most man-in-the-middle attacks occur on the client side (ex. some local network is compromised), which is still prevented here. You would need to man-in-the-middle from LE's perspective.<p>> “But you don't have to use certbot,” say the people who haven't thought very hard about it. And they're right: you always have options. You can renew certificates manually, but<p>Why the fuck did they link to the Youtube HQ shooting here? Anyway, they also link to a bunch of clients that don't do manual renewal.<p>> The entire certificate authority system is a for-profit scam. It imparts no security whatsoever. But Google gets its money, so it's happy.<p>I'm sorry, how is Google getting money from PKI? In the previous section they actually implied that Google might drop Let's Encrypt in order to have their own CA make money. So which one is it?<p>I know this was written in 2019, but since then Google has entered the market (<a href="https://pki.goog/" rel="nofollow noreferrer">https://pki.goog/</a>), but they didn't boot Let's Encrypt. In fact, they adopted ACME and provide certificates for free as well. So they're still not making money from it.<p>> what to do about it
> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you connect, and warn if it ever changes) that is optimal in a sense: it works at least as well as any other solution. It's trivial to implement, is completely free, involves no third parties, and lasts forever. To the surprise of absolutely no one, web browsers don't support it.<p>This author has no concept of the real-world. Prompting users to accept a certificate on first use is just going to cause them to always click "trust" since the other option will always break what they're trying to do. A website can then never rotate that certificate without breaking every user that visited their site before. So if the certificate does leak, someone now how boundless ability to MITM everyone that has visited the site, and anyone not MITM'd will now get a security error.<p>Overall this article constantly contradicts itself and merely presents out a poorly thought-out solution as the answer.