With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself.

Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in front of it.

So I don't really understand what you're talking about, when the price and ongoing maintenance of HTTPS certificates has gone significantly down for hobbyists.

> Let's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider [...] Cloudflare

Those are exactly the kind of third-party services the GP was talking about.

> if you're into managing your own server

One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without any involvement of third-party services. That is not anymore possible. Like, I now need to purchase a domain name and set up infrastructure to fulfill Let's Encrypt's challanges, just so I can serve a page on my LAN.

Not to mention people who can't obtain certs due to geopolitics or the inability to enter a legal agreement with the ISRG.

I understand why letsencrypt is needed and what problem it's trying to solve, but forcing international dependencies on a small number of select entities is not the way to go about solving them.

I can't help but feel saddened when see one of the greatest monuments to human ingenuity, a global decentralized network, get dismantled like this.

You can use HTTP instead of HTTPS or you can use a self-signed cert.

Often, this doesn't even work for small projects:

- HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from all APIs that are being added in the future.

- Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.

In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. That's nothing new (at least to me).

A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle.

I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open.

Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests.

> That's nothing new (at least to me).

It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.

And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)

I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real.

However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies)

I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure.

I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.

Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.

I was replying to someone who was complaining about what to do on "my LAN," no mention was made of clients. HTTPS isn't "security" with sarcasm quotes, it's actual security, it really does what it's supposed to do.

>So I don't really understand what you're talking about,

That's because you didn't finish reading my post.

>Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.

You mean like how it has been for decades ?

You have always needed at minimum hosting, SSL and domain service providers.

You definitely didn’t need, and most sites didn’t use SSL a decade ago.

DNS you always needed.

1) no.

2) There are multiple organizations running DNS and the general consensus is that there shouldn’t be a single organization running it (except ICANN which is generally careful to delegate the root and TLDs to other organizations.)

3) Just because you have one bad thing doesn’t mean it’s ok to have two.

Not strictly necessary, but convenient. All browsers I know of allow you to browse to an IP address.

Well, I tried to respond to GP with a tongue in cheek link of an IP address to lmgtfy or Wikipedia on DNS or something, but every site I tried checked the Host header, (I assume) so it didn't work.

This shouldn't be downvoted. I distinctly remember browsing websites by their addresses.

You mean besides the fact that you need an ISP?

NO! Two big reasons, among many others: 1) These are unnecessary third-party entanglements, allowing anyone to be slienced within a year simply by refusing to renew their certificates. 2) It's the 21st century, very soon, most servers will not have administrators - smart IoT devices, if we want them to use SSL/TLS, need certificates. If you think updating these certs on regular servers is a PITA, try it on a an embedded device that has very limited or intermittent Internet access, if it's even connected to the public internet at all!

It’s not the price that’s concerning; it’s having external dependancies.

> Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.

I mean... How do you expect to have a valid, trusted TLS certificate without a third party? Nobody says it has to be Lets Encrypt or Cloudflare or Amazon load balancers or ... so forth. Some certificate authorities even already have APIs....

No third party is strictly necessary.

You have to know what the servers public key is in a reliable way. That doesn't necessarily mean a third party has to be involved. Maybe you call them on the phone and check the fingerprint. Maybe it's your server and you sneakernet the key to your client. And to appease the dumb protocol you wrap it up as a certificate (self-signed) and accept yourself as trustworthy (what a concept!).

Even if you use a third party, it doesn't have to be some big company that everybody is functionally obligated to trust. It could be a mutual friend making an introduction.

And certificates are not the only or necessarily the right solution to this problem in all domains. For example, if you have to go and check OCSP every time to see if the certificate might have been revoked, then you are relying on an online trusted source; but if you have an online trusted source, why don't they just tell you the current key and dispense with the certificate mechanism altogether?

X.509 was designed for X.500 and concepts that were relevant for X.500 continue to plague us all. I deployed corporate PKIs back in the 1990s for Sun and Pfizer and worked with other clients. What I remember best from those times was how ridiculous the whole thing is, over-engineered by parties who clearly didn't keep focus on the fundemental problem that public key cryptography is meant to solve.

For the more concrete goal of having a valid TLS certificate that is trusted by browsers, you absolutely need a third party however.

My point is that this news item does not change reliance on a third party at all. Not that it’s impossible to exist.

A lot of other apps that use asymmetric crypto to authenticate the other end allow for “trust on first contact” for establishing trust.

It’s a little disappointing that many browsers have no support for this whatsoever and most have very poor support for it.

TOFU has its problems too, but its neither here nor there; CAs have been a part of HTTPS and SSL since the 90s. This news item, to me, does not signify any shift in whether a third party is needed or not.

I am telling you there is a conspiracy going on to end the open and free web.

We should fiercefully start to fight back otherwise those who made the internet great (the open source hackers working on LAMP) will loose everything.

I'll agree that modern mainstream browsers (and devices!) have an increasingly centralized security model that isn't at all conducive to an open web. But given the current state of the FOSS ecosystem, I'm not terribly concerned in the long term so long as the network layer remains open to all.

(Consider: QtWebEngine, PinePhone, SiFive, OpenTitan, IPFS, DAT, Solid, ...)

I think the web is already a lost battle. It'll just take time (a lot of it) for the control to fully sink in. But I think that once this control becomes mainstream then there will be something else with more freedom. Some form of an alternate internet that will have barriers to entry. Something like tor. It'll probably be based on p2p.

Gab's rework of Mastodon is starting to look like this.

How is the network layer open when legit SMTP servers with proper SPF records are blacklisted by Google and Microsoft with no accountability. The internet is owned by these organisations. It's a fait accompli. It's only a matter of time before sites not hosted on cloud platforms become blacklisted due to the pitfalls of self-hosted certification. Jeeezus.

Refusal of large email providers to properly federate is certainly frustrating, but I was actually referring to the network layer in the OSI model. So long as the raw IP traffic isn't subject to broad and pervasive restrictions by the authorities, new software stacks can be freely invented and used on a worldwide basis (IPFS, for example).

(Speaking of other software stacks, a few Gopher servers remain online today [1] and there's even a DECnet in operation! [2])

[1] http://gopher.floodgap.com/gopher/gw?gopher/0/v2/vstat

[2] http://www.update.uu.se/~bqt/hecnet.html

Does apple try to kill the web? Does Google try to take it over?

Why doesn't Apple kill a million sh.tty apps just trying to grab attention doing nothing useful?

It's time to get rid of Apple/Google browsers really

CAs have always been third-party services, though. Their APIs just used to involve humans talking to humans, rather than machines talking to machines. But that's no less of an operational dependency.

In a systems engineering plan (e.g. a NASA long-term project), both kinds of dependencies are considered liabilities that must be engineered for long-term reliability, fault-tolerance, etc.

In the past browsers did not scaremonger so much about self-signed certs and search engines would index sites that were just http and this didn't effect their ranking.

>In the past browsers did not scaremonger so much about self-signed certs

That's necessary because people tend to be fixated on whatever task they're doing, and that causes them to click pass any warnings regardless of risk or comprehension.

I can't tell if you are serious here.

You want self signed certs to be trusted and the web to move back to the days of HTTP where anybody could just intercept your traffic ?

That's not what he said.

Search engines have stopped listing http sites? Since when? I do not have https for my site (unclear if sourcefoge allows https for custom domains)

It's different if you can "buy" a cert and be "safe" for a few years vs needing to renew it every 90 days. If they choose not to renew your cert, you're out after what ever time is left on your cert.

Let's lower that to 60 ... 45 ... 15 .. ah, let's just renew all certs every day, that's the only way to keep control centralized.

You already have to rely on a third party to get a domain (and to get an IP address)

Every additional third party is an extra problem. It's an extra relationship to track.

Sorry if this sounds dumb but this is a non sequitur for me. How does the for-profit web benefit from being able to revoke certificates? And why does revocation not work in practice? I thought all major browsers check their own lists to see if certs are revoked

This paper:

https://cseweb.ucsd.edu/~schulman/docs/imc15-revocation.pdf

is slightly dated but gives a very good rundown of how revocation checks fail in practice along with different attempts to improve them.

Fsck certificates, period. Make an exception for ecommerce and banking sites but leave the rest of us alone. Certificates have become the equivalent of the UK's national policy of building road humps 50 metres apart to thwart speeding drivers.

You can always run your own company-internal or limited-to-your-home CA and add it as custom root CA to every browser in that domain. These maximum certificate validity rules IIRC don't affect custom root CAs you added.

I agree with you that the web is being commercialized, but limiting certificate lifetimes isn't the problem. It's rather stuff like the .org domain sale, google amp, Chrome killing the file:// protocol (after all, html files don't have ads inside them, can't be indexed and they don't make any money for Google), FLOSS projects adopting discord, etc.

What about people who want to share information about things they love with privacy and security? This change seems likely to enhance my privacy and security.