Crypto Zealots | Hacker News Reader

Crypto Zealots

potaroo.net

132 pointsr4um93 comments

It is worth reading the article this posted one is in response to. (http://www.circleid.com/posts/20180225_humming_an_open_inter...)

It has the kind of inflammatory institutional chauvinism one usually expects from bureaucrats defending their turf and moralizing their powers, but it's important to understand the outcomes the people like them are aiming for.

Additionally, ignoring for a moment the usual appeals for intelligence and law enforcement, the coalition of interests the author is referencing includes those interested in enforcing "societal norms," and "support for persons with disabilities."

The first means censorship and those people never seem to go away. But the second has nothing to do with transport layer encryption and appears to be a dogwhistle offering tacit institutional support to political agitators who want to get onside with adding surveillance levers to the internet.

The article could reasonably be interpreted as a threat that if TLS 1.3 is adopted and imposes further costs on pervasive surveillance apparatuses, they will co-operate to further balkanize the internet.

That article was so hard to read. He jumps to so many conclusions without any logical path like the use of TLS will stress the bandwidth of providers, claiming its like "unauthorized taking of the provider's transport network resources". How will TLS vs not TLS meaningfully impact amount of traffic on a network? He doesn't say, just claims it. I'm guessing he means the provider can't throttle/control traffic based on packet inspection as easily? Regardless, this is like saying everyone in the neighborhood running all of their faucets at the same time is like stealing from the water provider. That's literally their only job, to be a pipe for water. People aren't stealing by stressing the network, if anything the network would be stealing for not running as advertised.

"TLS 1.3 significantly facilitates widespread malware distribution" this guy...has to be getting paid by someone to say this, right? Who is this dude, what is CircleID?

There's throttling to consider, but there's also caching. It's been a long time since I've had conversations with any NetOps folks working for ISPs, but it used to be very important for the health of a network to do considerable caching wherever possible. It's why http includes cache control headers. With TLS, only the browser can now honor this TTL, and an ISP can no longer cache a particularly popular webpage. I've long suspected that caching strategies are no longer very useful given how the internet looks today, but I also understand powerlaws and it wouldn't surprise me if caching is just as useful today as it was 20 years ago.

So many popular webpages these days are dynamically generated that it can't possibly make much of a difference. I suspect the bulk of traffic by weight is video these days.

If my ISP can cache my traffic they can censor it - and do. Every now and again I'm reminded by accident that EE mobile are scanning all my URLs for censorship purposes.

If my ISP can cache my traffic they can censor it - and do.

Only if they can forge a cache-hit, or block a cache-miss from passing through. Something content addressable (like IPFS) would allow an untrusted party to provide useful cache. (doesn't solve the privacy aspect of the untrusted party knowing I accessed the content though).

It would shock me if it was useful at all on today's internet - the caching I imagine is useful are the boxes that large video providers install on ISP networks. But so much of the internet is already encrypted (YouTube, Netflix, Facebook, etc) that any ISP operating a transparent cache probably has a very low hit rate.

One of the problems with http is that nobody bothered to implement some kind of integrity check for http content (and make sure that it got wide deployment). There are too many examples of parties messing with http content.

So if people cared about transparent caching, they should have added integrity checks ages ago.

Now it's too late.

It is interesting to compare with DNS. DNSSEC is basically just an integrity check. These days the lack of privacy is considered a serious issue. And DNS is likely to move to TLS as well.

The case for transparent proxies put in place by consumer side ISPs has largely been nullified by the introduction of elected CDN services like Cloudflare.

The privacy implications aren't really any different, but at least it's the webadmin of the website you're choosing to access that gets to decide. They get to ensure that they elect a company that respects their content and provides value to their visitors.

OK I read the article and obviously lack some context. The author goes on and on about the evils of TLS 1.3 but it wasn't clear why TLS 1.3 would cause the world to end as opposed to say, TLS 1.2. Can't companies that want to monitor their employees just stick a bogus certificate on their computers like they can now?

Edit: deleted an incorrect comment about meta info. That was the other thing...

One big difference between TLS 1.3 and 1.2 is that TLS 1.3 mandates forward security.

So with TLS 1.2 a server can be configured to only allow ciphers without forward security. Then a capture of encrypted traffic can be decoded later. Or a middle box can be provided with the server's private key to analyse traffic.

For TLS 1.3 this has to change. Any capture or monitoring device has to either perform the DH exchange itself, or receive the session keys from the server.

Also, in TLS 1.2, even with Forward Secrecy the focus is on protecting the application data, in TLS 1.3 literally the only things going plaintext are the initial ClientHello and the ServerHello finishing up the key exchange.

Because in TLS 1.3 we know we want DH, they do it right up front. The client is like "OK, here's my DH parameters, also I want to talk to www.yahoo.com" and then the server is like "OK, here are my DH parameters" and here's the trick: The server knows that as soon as the client reads that part it has a working DH key agreement, so without waiting the server switches on encryption and continues (encrypted) with its certificate, the signed transcript (proving it owns the certificate) and any other parameters e.g. "please send me a client X.509 certificate with the following policy OIDs set".

Because the DH happens up front, everything else is opaque, and that means less chance for crappy middleboxes to break it. Middleboxes are how ordinary people became Crypto Zealots, absolutely any harmless parameter, setting, or whatever is another opportunity for idiot middlebox vendors to break things, if we encrypt everything they can't do that, hooray. The Internet works better if we encrypt everything, that shouldn't be true, but because middlebox vendors are universally incompetent morons it is.

The CircleID article is full crazy. There's a whole passage about how the IETF "took over the ITU-T/ISO internet TLS" which turns out to mean basically the words "Transport Layer Security" are also used to name one of the dozens of X series standards. That standard, X.274 also involves er, securing a transport layer, like TLS, and so there are some elements we'd recognise - even Diffie-Hellman key exchange (although it's under a different name and hidden in an appendix) but of course it's not an Internet standard and doesn't use Internet nomenclature.

It's like if midway through a rant on how awful Back to the Future is, the author stopped to complain that Huey Lewis and the News is just covering the 1984 Jennifer Rush song... not _quite_ as crazy as saying it's a cover of Deee-Lite's track but still pretty crazy.

If there's still any doubt that encrypting everything is the right way to go for internet protocols:

Huge: @Citizenlab catches ISPs invisibly redirecting download requests for popular programs, injecting them with government spyware. Unencrypted web traffic is now provably a critical, in-the-wild vulnerability. 20-30% of top internet sites affected.

https://twitter.com/Snowden/status/972110541408952320

The ISP in question is in Turkey, so it should probably be noted that the Turkish government has a root cert trusted by both Mozilla and Microsoft.

https://ccadb-public.secure.force.com/mozilla/IncludedCACert...

https://social.technet.microsoft.com/wiki/contents/articles/...

Pretty sure that such a root cert would be fairly quickly yanked if they got caught using it for MITM attacks. That would cause a lot of trouble for the primary users of such certs. Such attacks are best done with some relatively obscure and unimportant compromised certificate authority.

After reading both the linked article and the original to which this responds, I can say I am one of those Crypto zaelots. And not just because I am developing a protocol that encrypts everything end-to-end.

The original article's claims are ludicrous, stating that TLS 1.3 would be basically unlawful, since the ISPs can not read the data. Than it says that a open internet is bad, citing small, empty pages that go from "there are nazis there" to "this and that political figure is there only thanks to the internet".

The solution is: middleboxes that see all your traffic. ...'cause Trump would not have been elected with your middleboxes or something? That alone is disturbing on many levels.

The author of the linked article points out that it is a bad idea due to what Snowden brought up, but basically stops there.

So please let me say, fuck you and your middleboxes. But not only because of the Snowden revelations.

I have seen middleboxes truncate traffic because they didn't understand a TCP option. Throttle/drop everything because they were way too downsized and could not handle the traffic, some barely able to NAT, let alone do their inspection. Centralized firewalls crashing due to too many packets in memory. Captive portals that spoof dns so that they can display the login page, except that I can't see that, 'cause HSTS and they don't have the certificate, or my device caches the DNS query result and I can't see that site anymore.

So Fuck you and your middleboxes. Especially those that intercept all your TLS traffic, analyze and then pass it through, signed with their CA. Except they didn't really control the original certificate, or you can't control the trusted CAs. Or those that blocked me from updating antiviruses, because guess what, false positives. Or those that MITM your dns queries, to give you your much needed advertisement, when they don't outright MITM your HTTP to add their advertisement.

Are any of those middleboxes ever updated anyway? By the developers, not by the local admins. Those middleboxes that break stuff and make troubleshooting hell. I have seen too many old, never-updated stuff to believe in your middleboxes anymore.

If a company wants/needs to see/modify the traffic, then fine. On their devices. Install a CA there or install a VPN that tunnels the device to your proxy or something. Why does it have to transparent, for everyone?

So really, I'm with the author. Fuck you and your fucking middleboxes.

> I am one of those Crypto zealots

It's an unusual feeling to become a strawman.

Every so often, somebody attacks a point by saying "Why, $foo is absurd! If you did foo, you'd be embracing a world that that looks like $bar!" And I read their piece, and think "Yeah, I'm totally on board with $bar. Sounds good!"

It's a depressing reminder of just how far apart people's goals can be. I don't just disagree with them, I have views so distant that they use my beliefs as a reduction to the absurd.

Fuck that article, and fuck its middleboxes. I accept that I am, by many standards, a crypto zealot. I'm alright with that.

> We’ve seen programs such as Let’s Encrypt that bring the price of domain name public key certificates down to a base of free.

And, interestingly enough, turn the implicit assumptions behind the whole XPKI infrastructure on their head.

CAs built their business on the idea that we needed to know that sears.com is Sears, Roebuck & Co., while sears.net is a family website. But it turns out that we don't really care: we care that google.com is google.com, and that's it.

What we really want is to know that the IP address we're talking to is the IP address we think we're talking to, and that the IP address we're talking to is the one we looked up for a particular DNS name. What we really want is not an identity-authentication certificate, but rather authorisation certificates.

Over twenty years ago, RFCs 2692 & 2693 (and follow-up draft work) identified the issue, and offered a solution — but the industry stuck with identity-authentication certificates. This is kinda crazy when you think of it: knowing who someone is doesn't guarantee that I want to do business with him.

> But it turns out that we don't really care: we care that google.com is google.com, and that's it.

It's worse than that. 9/10 users I observe 'google'* google in order to run a google search. Every single time they go to a website that isn't saved as a bookmark, they search for it instead of typing an address into the address bar. I used to be surprised seeing people google 'gmail' and then click the top ad every morning... But I don't blame the users as much anymore. The companies that makes the browsers and web search know all this too and the UI has actually evolved to further muddy the difference between search and address.

(Increasingly they bing it due to MS defaults in Win 10.)

But your overall point is well taken and very true: having the sears.com domain name might not be as important as having the top google hit for 'sears'.

I used to be like that with real world directions. Constantly referencing maps, people, or (later) smart phone maps. Then I started forcing myself to develop an internal model of the regions I was traveling in, now I only use the smart phone map for ETA and traffic information.

I think most people never really develop that mental model of how the internet is laid out. I would get lost going from A->C or C->A. But I could go A->Town Center->C no problem (and the reverse) but it took twice as long because I was taking a suboptimal route. Everyone knows where Google is, it's the town center of the internet (for them), like the portal sites that MSN, Yahoo!, and others provide. So they go there and use it to make their way to their desired destination.

I turned into the opposite for real world directions. I let google tell me where to go, only rarely deciding a different route on my own. And sometimes that's not exactly a fully formed different route but I want to go via a certain way (e.g. non-freeway) and hope google updates the rest of its directions to accord to that wish. It's taken me on some weird paths but whatever.

My excuse is that I grew up in Utah, which has a fairly consistent and ordered grid system with addresses almost always mapping to grid coordinates, so given an address you don't need any special directions. You might still go to a main road because it's faster, but you could instead optimize the Manhattan distance without effort. Traveling elsewhere with places so fond of nonsensical street names and non-grids, I gave up actively building a mental model (I have an ok spatial model of my surrounding area in Bellevue/Redmond but I've been here almost a decade...I have no idea where most of the street names in Seattle proper fall and haven't bothered to learn any of the mnemonics people have suggested) and let the machine tell me what to do.

This is really apt, people who are not adepts choose reliable routes to success over potentially faster ones, and often reject your "better way" because it requires some subtlety in their mental model or an exception to a rule that didn't already exist.

> CAs built their business on the idea that we needed to know that sears.com is Sears, Roebuck & Co., while sears.net is a family website. But it turns out that we don't really care: we care that google.com is google.com, and that's it.

Perhaps more critically, we've proven that even if we wanted to know that sears.com is Sears, Roebuck & Co., CAs can't be trusted to tell us that reliably.

>"CAs built their business on the idea that we needed to know that sears.com is Sears, Roebuck & Co., while sears.net is a family website. But it turns out that we don't really care: " //

Don't we?

I think people in general do care, but having a cert doesn't show it to be true unless you trust all CAs?

I think in general, no, we don't.

I know this crowd thrives on the non-general, pedantic edge cases, however, so it depends on which "we" we are talking about.

>CAs built their business on the idea that we needed to know that sears.com is Sears, Roebuck & Co., while sears.net is a family website

What do you mean? This is only true for EV certs.

To be fair, CAs are somewhat _older_ than the Web PKI and even the Web PKI starts out with what you'd now think of as the EV model.

In the early 1990s Tim's ludicrous toy hypertext system is suddenly the New Hotness and people who had barely grasped by Email was a good idea are starting to realise that maybe this whole Internet thing might not be a temporary phase before we all settle down to using AOL (yes, AOL used to be its own thing not just an obscure corner of the Internet)

A graphical web browser called Mosaic has been invented by (of all things) the National Centre for Supercomputing to make Tim's crazy toy a riot of pictures as well as text, linked together over the Internet, and some of the people who worked on that, plus a whole lot of other good software engineers hired from other work are now at this startup which is initially also named "Mosaic" but eventually becomes famous to us as "Netscape" before the Microsoft corporation drives it out of business.

Anyway, at Netscape they're more focused on commercially friendly applications of this technology than the academics who've worked on it before, and one thing they realise is that Tim (being a physicist not really a software engineer or computer scientist) hasn't built any workable security into this thing. So they invent a Secure Socket Layer, the idea is to use all the same stuff as the Web except with Cryptography to protect it. Nobody working on this stuff is a serious cryptographer, but they do eventually cobble together something that isn't laughable, on their second attempt, SSLv2. One of the fixes they realise they need is that encrypting data to just some random yahoo on the Internet is pointless - bad guys can just arrange to be Man-in-the-middle and you've got to stop that. So somebody needs to take responsibility for figuring out who is who. If Netscape insists this is them, that's clearly a huge landgrab, nobody will buy it and SSL will be dead. But what if they out-source it to these companies called Certificate Authorities, that do the same sort of thing already for products in the banking and legal industries?

So initially, a CA is a big company like Verisign that already has a business checking people's identities, and this is a new side to it, they don't spin up all new infrastructure, they just make a web page on this new-fangled World Wide Web saying they can offer "SSL certificates". They are verifying real world identities because an "Internet identity" is still a pretty new idea for them.

Now, these certs were expensive, and there was of course a pressure to find a way to make a product that was cheaper - not for customers, who cares what it costs customers? No, cheaper to make, so you could keep more profit. And the solution was "Domain validated" certificates. Gradually CAs began writing "Domain validated" in the slots where it should say e.g. the Organization name of the subject, and just sending an email out to "validate" that they really controlled a domain.

EV as you know it today comes into being much later, only about a decade ago, as the Browser Vendors (by now including Mozilla, the successor to Netscape that was now a not-for-profit and a pretty angry pro-user one) realised that a Wild West of certificates issued by CAs wasn't in their interests.

But it turns out that we don't really care

I care - it's annoying to have to check whether there's a typo in te URL every time I want to trust a website using SSL.

The piece in CircleID to which Geoff Huston is responding is pretty clearly a troll, a bid for attention from someone professionally attached to some pretty marginal "standards" groups. It's incoherent and poorly informed. It's possible to make colorable arguments about the need for security protocols that admit to legitimate monitoring. The CircleID piece didn't make any of those.

It's a little embarrassing to see someone of Geoff Huston's stature responding to what is so clearly a plea for recognition from someone who would otherwise have no impact whatsoever on Internet engineering. It's much more embarrassing for CircleID to have published that piece to begin with, but, what do you expect? CircleID is terrible.

From reading a few of Anthony Rutkowski's other screeds against end-to-end encryption I got the impression he might be a shill for some middlebox vendor. Did some digging and turns out he is an executive at Yaana which is a company that does exactly the kind of work that TLS 1.3 is trying to frustrate (credit to HN user Animats [1]).

>"Yaana is a leading global provider of a wide range of intelligent compliance solutions including lawful interception, accurate data retention, big-data search & disclosure, advanced security and application specific analytics."

That he thinks his unhinged writing style might be persuasive to anyone is baffling to me.

[1] https://news.ycombinator.com/item?id=15586504

> That he thinks his unhinged writing style might be persuasive to anyone is baffling to me.

This is what got me. "humming"! It's classic crank writing; who could possibly imagine that anyone could take this seriously?

Humming, unfortunately, really is an IETF thing.

https://tools.ietf.org/html/rfc7282

For me, a "crypto zealot" is somebody who says we shouldn't use SMS based 2FA because it has some vulnerabilities: people who advocate using only the best crypto, or none at all.

This just sounds like building a universal layer of encryption around all communications. It's not zealotry but common sense.

>some vulnerabilities

lol. I guess that’s one way to put it.

Any 2FA > Any 1FA, for a constant first factor.

> A better position is to use QUIC. Not only is the payload encrypted, but the entire transport flow control is covered by the veil of encryption.

I'm not sure I understand his/her point. Maybe this is pointing to QUIC encrypting part of the handshake?

Not just the handshake. With say HTTPS (HTTP over TLS over TCP) the unencrypted TCP layer is where the flow control is, a bad guy can see and manipulate this flow even though the application data is opaque to them. Every TCP packet is identified as to which session it's part of, and the TCP stack is relying on the flow control to tell it e.g. to slow down because things are congested.

In QUIC all that vanishes inside the encryption. The only things left unencrypted are the source and destination address.

Oh I see what you're saying. Is it really an improvement though? If a bad guy can see and manipulate your TCP flow, he could also just drop packets.

It's an improvement because middleboxes can't mess up your packets when you're using authenticated encryption. Sure, they can still drop all of them, but that's a much easier problem to debug than otherwise.

We have all these problems because a lot of middleboxes crap their pants when they "see" something in the protocol headers that their developers did not consider because it didn't seem to happen on their laptops or whatever.

So you make the protocol headers invisible to the network's middleboxes to prevent the middlebox developer's broken mental model about that protocol from breaking your pipes.

I see your point. Also, they can still "control" the flow of QUIC (to a lesser degree I'd imagine) by dropping some of the packets.

(Surprisingly the fine article is about cryptography, not fake internet money)

Is this really surprising? I'm (still) more surprised when I click on an article with crypto in the title and it's not about cryptography. (There may be some underlying bias as to the links I see/am sent.)

In this particular instance I fully expected an article about cryptocurrencies but I think that's mainly because of the other word in the title. I don't usually associate cryptography with zealotry.

I've seen people use "crypto analysis" to mean "understands the kraken exchange UI better than most people". (A crime for which the only appropriate punishment is immediate banishment, IMO)

It's very disappointing tbh, I love crypto. As in, cryptography.

Good. http://www.metzdowd.com/pipermail/cryptography/2018-February...

> We’ve seen programs such as Let’s Encrypt that bring the price of domain name public key certificates down to a base of free

Only free if you value your time at $0.

Indeed, otherwise they have negative cost. The Let's Encrypt API has saved me so much money by letting me automate certificate generation, it's crazy. No more having to install new certificates by hand every year!

HTTP has a zero ongoing cost, HTTPS has a non-zero ongoing cost.

Not for me. When I set up a new domain & hosting, I checked the box which said "Enable Lets Encrypt" and it was done instantly. I haven't had to manually renew it.

That's nice for you, but that's not how it is for other people.

The tooling around Let's Encrypt is designed to make it possible to do that. If you're not dead set on using a specific web server, there are web servers with Let's Encrypt support out of the box[0].

And if you're using Apache or Nginx, Certbot[1] can configure Let's Encrypt support for them automatically. It's not the "one-click install" you'd get with some other software, but it's pretty close.

[0] https://caddyserver.com/ [1] https://certbot.eff.org/

FWIW I just tried the automatic tooling. First observation is that my email (which was already using LE) still seems to be working, which is honestly surprising but I suppose I should be pleased. My website still seems to redirect a couple of times before ending up back at the unencrypted version. TBF, nothing's conspicuously broken so far so no immediate damage. I'll go back and try to sort it out when I have some more time / enthusiasm.

Update: I got it working. I still maintain that it was largely pointless, not zero-effort, and puts the difficulty of running a webserver further into the domain of stuff that's only likely to be undertaken by professional / commercial entities, and that that's a bit of a pity.

Update2: Shit, I broke some other stuff :-(

Switch to Caddy, then. It becomes mind-numbingly easy to setup.

https://caddyserver.com/

Only if you value the security of your customers at $0.

Isn't it reasonable for me to value the security of my customers at $0? Given that a) I don't have customers as such and b) My website is just a (very out of date) blog with some innocuous nerdy stuff on it.

It's not just security, it is also privacy.

But even if it was just security, it would be irresponsible to offer something (a blog) and knowingly compromise security for anyone who is interested.

How am I compromising anybody's privacy or security by hosting information about my defunct bare metal Raspberry Pi project? What is the threat model?

The traffic can be intercepted and changed. If someone trusts you (say you gave them the link) but the content they are being served is not the content you intended to be shared, is that not a security issue?

ISPs have been known to inject ads for example.

The former is not likely to be an issue for the site I'm talking about. Ad injection is shitty but I don't think it makes my blog "irresponsible".

Meltdown/Spectre kind of vulnerability plus injecting Javascript to anything that is http only by rouge ISP employee or user on open rouge wifi. It is not about targeted attacks it is about low hanging fruit which any http site is and bots, automated hacking/injecting.

Like people saying that changing SSH port on your VPS is not security. Setup one Linux VPS and see how many bots are trying to brute force your password. Just change the port so they stop trying.

Does it have an admin interface? Without encryption, your username / password are broadcast unencrypted; if intercepted by whoever, they can hijack your blog and post spam / spread malware / subtly inject some JS to mine some dank monero.

Nope.

> HTTP has a zero ongoing cost

Only if you value your (and your users/readers) privacy at $0

I set it up, once, it gets automatically renewed indefinitely.

Haven't had to change a CC number, or trip over any of the usual selection of billing and renewal gotchas.

Fits my definition of free, even after valuing my time as non-zero!

Again, HTTP had no ongoing cost, HTTPS has an ongoing cost

What ongoing cost? This is absurd. It’s $0, the automation is free, and the config is free. Stop spreading FUD.

> HTTP had no ongoing cost

If you consider constant warnings from most browsers that annoy your users and coming up with new excuses as to why you haven't moved to HTTPS as not being a cost…

That's an artificially induced cost, though. You are correct that I'm going to have to letsencrypt my blog if I want to people to be able to read it (I might just take it down). But I don't think the people are correct who are saying that a) there's any good inherent reason for me to do that and b) this will cost me no time or effort. I've done the LE thing before and, at least in my case, it's not a zero-effort thing.

In this thread alone you've already expended more energy than it would have taken to just do the right thing with your blog.

This is incorrect - I won't go into details as I'm busy fixing my server and need to go out in a couple of hours.

So I can stop paying those bills the web-hosting company keeps bugging me about?

Yes, you can host your own server and use your home internet connection. This is the whole issue really - the web was designed as a decentralized, anarchistic, read/write thing, and it's subsequently become a thing where it's increasingly difficult to participate unless you're doing so on a professional basis or relying on somebody else's professional services. Maybe this is just how it has to be, but for people who can remember a couple of decades back it's pretty depressing.

(btw I've used LE both in my day jobs and for some personal stuff, and I very much appreciate its existence).

so I can stop paying those home internet connection bills that keep stacking up every month?

If you personally don't want to have an internet connection then I'm afraid it's going to be hard for you to run a webserver for free. I think this would be unusual though.

the point is that http isn't free of ongoing costs.

Are you paying for http on top of your internet connection costs?

Or I might get free access from my library and they don't permit me to run a web-server.

I'd probably get a more expensive plan that had good upload speeds.

HTTP has an enormous ongoing cost in the form of loss of security and privacy.

I don't really see the difference between it and other certification. Surely I need to configure my servers regardless.

Also, sometimes doing a bit of server work is rewarding on its own.

The main difference in my experience is that LE's short certificate expiry dates force you to automate certificate renewal, while traditional certificates usually don't even offer automation and so require you to take time to explicitly renew them.

My problem is with the crusade to make everything HTTPS - normal HTTP involved no ongoing setup, and didn't put the ongoing functionality of your website in someone else's hands. As I've said above, LetsEncrypt is sponsored by corporations and could disappear tomorrow.

Do you live in some parallel universe where we do not have mass surveillance, nation states or internet providers modifying traffic or unencrypted wifi at coffee shops?

Your attitude is irresponsible. HTTPS is not a luxury, it is a requirement.

Let's Encrypt is currently sponsored by 53 different corporations and organizations, including Google, Facebook and Cisco. I'm not seeing it disappearing anytime soon.

My HTTPS web server requires no on-going setup. And the on-going functionality is in a lot of people's hands, since I don't host the server in my own house with my own fixed Internet connection.

I'm pretty confident your services will disappear long before LetsEncrypt does.

It took me 10 minutes to setup Let’s Encrypt on my web server. It was the first and only time I’ve had to do it. I’m pretty sure I spent more time setting up Apache’s configuration than I did Let’s Encrypt’s.

It is very easy to set up in a permanent fashion.

Your definition of permanent is different to mine. LetsEncrypt relies on corporate sponsorship that could disappear at any time, then where would you be? Back to jumping through the same hoops you had to jump through before

Nah, there are two things going on here, and they're separate

1. The Let's Encrypt service from ISRG, which is a charity and so obviously if the donations dried up and somehow we didn't fix that then eventually (maybe a year or more) it would go away. This is also true for Wikipedia and the EFF in the most obvious direct sense, but it's true for all commercial services you rely on too, Youtube, Facebook, Hacker News, all could go away if their owners decide there isn't enough money any more.

2. ACME and other certificate automation. These are protocols, in ACME's case IETF Standards Track protocols, for how we can validate control over a name and issue certificates to an applicant. These don't vanish if ISRG goes away. For example loads of cPanel users already don't use Let's Encrypt, they have a single button "Yes, I want free certificates" feature, and Comodo (the root CA behind that) is taking a slice out of the cPanel license fees.

Your worst case scernaio is so mild: nothing lost.

Why not use LetsEncrypt until it’s no longer available?

> Your worst case scernaio is so mild: nothing lost.

Not really. With Let's Encrypt available, the browser makers are now talking about penalising all HTTP sites. Next year, or the year after that, they could decommission Let's Encrypt (or start charging), and suddenly we'd all see what had been lost: it'd no longer be possible to set up an unpenalised site for free.

Personally, I believe that an IP cert should be issued along with one's IP address, and a hostname cert should be issued along with one's domain name.

If LE goes down, your cert expires and doesn't update, then your website visitors get the "unsafe site banner" and have to navigate instigation of an override to even see your pages.

My small business page's cert got messed up (by Plesk, or the hosting provider I suspect) and the page went offline.

If your site being essentially unavailable to customers isn't a major consequence I don't know what is.

Reply on news.ycombinator.com