The modern HTTPS world has no place for old web servers

Unsecure http is essential to the free flow of information.

Let's get the right solution before we force everyone to use it.

The only workaround is to use a VPN since so many servers still have not moved from HTTP to HTTPS.

Tech support states unless I accept the agreement this will not stop and may connection will be disconnected which is complete BS since HTTPS prevents this from working properly!

So yes, even ISPs are bad actors when it comes to HTTP.

That site requires exactly TLS 1.2 (not newer or older)

So an HTTPS implementation like Mountain Lion that only speaks TLS 1.1 or earlier will begin by saying it can do TLS 1.1 and the server says too bad, go away.

TLS 1.2 was defined in about 2008 but despite that a lot of products shipped without TLS 1.2 implemented for the next several years, because backwards compatibility meant they still worked, and it didn't seem like a priority, while forward compatibility had frequently proved problematic. Why ship something "more secure" that breaks for 1% of your users?

For example Firefox only added TLS 1.2 by default in 2014, after Mountain Lion was shipped (but before it ceased to be supported).

If your Worker code hardcodes the Dark Sky domain, the worst an attacker could do is either use up your free worker quota from Cloudflare, or hammer Dark Sky at the Worker ratelimit (1,000/minute, which Dark Sky should easily handle).

AWS, Azure, GCP all also have free tiers for their serverless services. RunKit (http://runkit.com) might also work.

These are all likely to be HTTPS-only, but hopefully at least one of them supports TLS v1.1, rather than being 1.2-only like apparently is the problem with Dark Sky.

That's well and good, but who are those Letsencrypt guys, anyway? That's why there is a chain of trust and Certificate Authorities.

You, and your browser, cannot know everyone out there so you pick a few 'authorities' that are well-known and deemed serious enough to be trusted and go from there.

DNSSEC operates on the same principle of a chain of trust from root.

Hasn't really gone anywhere of importance.

I personally think there's been a few factors as to why:

* Distrust of DNSSEC and centralized authority.

* Lagging DNSSEC deployment, not just in DNS but also in clients and applications.

* Needs another DNS lookup on connection to validate certs, adding lag. I think it probably needs stapling support in some form just like cert validity checking.

There's also been follow up RFC detailing it's use for SMTP, SRV records and PGP.

Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), despite almost the exact same reasons holding up with middle-boxes, proxies and the like.

Now that there is an alternate, much simpler HTTPS-solution everyone is "oh noes that would break corporate environments". What's different this time around? Why is breaking things bad this time?

If we could just sit down, and all agree that the only reason we "need" HTTPS everywhere is because running JavaScript in a browser represents a security-issue, the quicker we can start solving the real problem: JavaScript as a default-permission.

The quicker we can phase that out from web-pages (which honestly more often than not, simply represents documents), the better.

So I guess I'm confused how

  DNS records hold a public key rather than _acme-challenge

Once in Python

https://github.com/smutt/danish

And again in Rust.

https://github.com/smutt/danish-rust

An old explanation can be found here.

https://www.middlebox-dane.org/

Both middlebox-dane.org and metafarce.com have DNS TLSA records that match their certificate from Let's Encrypt. You can do this, but almost no one is.

There is some pickup in The Netherlands where I live. For example, www.digid.nl has delpoyed DANE for HTTPS.

Since "DANE for e-mail" is still relatively new / obscure, for the uninitiated, RFC7672 [0] describes "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", which requires DNSSEC -- and, as a result, comes with all of its associated disadvantages / trade-offs.

An alternative, more recent method of providing authenticated and encrypted delivery of e-mail is described in RFC8461 [1], "SMTP MTA Strict Transport Security (MTA-STS)", which uses DNS and HTTPS -- and, thus, relies on CAs / PKIX. MTA-STS doesn't require DNSSEC but it is then susceptible to "malicious downgrades".

Although we're not going to see all e-mail being encrypted in transit anytime soon (if we ever do), it's good to know that there are folks working on solutions, including at some of the largest e-mail providers.

---

[0]: https://tools.ietf.org/html/rfc7672

[1]: https://tools.ietf.org/html/rfc8461

The answer is in the question: they're building _browsers_, to consume content but certainly not to create it or spread it. The last mainstream browser that did that (Opera) vanished a few years ago.

In fact, thinking about the problem a little bit more I realized that the heart of the article is kind of true but isn't articulated to show it clearly: Internet, while it was still young, was pretty symmetric because every node could be a producer and/or a consumer, and it seems everyone was. Today things are really different, because while there still are producers, the important gap is that they're not distributors anymore, and they're far fewer than consumers anyway.

The article states that the switch to HTTPS has somehow "changed" things, because you can't start a super basic HTTP process and expect it to run for a long time. This conversation has shown that while it's technically true it's very easy today to run an HTTPS reverse proxy to mitigate the situation, so from the point of view of TLS the point is mostly theoretical. However there's something that is very important today, it's that people who want to produce mostly can't also be distributors: NATs and firewalls and the complexity of configuration has in practice prevented everyone but the most tech-savvy of us from self-hosting. I think this point is more detrimental to the initial promise of the WWW than the technicalities of the encryption that has allowed us to make this protocol more viable at the scale we're at right now.

The answer is, as I've said before, the decentralized web: I personally believe that dat is the right model, but I might be wrong and the details don't matter that much because the important point is that they all allow us to get past connectivity issues and be both a producer _and_ a distributor. Hopefully that's where we're going to be headed in the coming years.

Regarding adobe, there's no question it _can_ be used if we just want to; what I had in mind (and I did not express it, my bad) is that this kind of material usually comes with the associated manual process that's so prevalent in the communities working with it. Scaling it to 10 billion people, all using this method, will definitely change the way our societies are built: tall buildings aren't possible anymore, at least not the way we're used to. Structures take decades, not years or months to be built. I doubt this can scale to 10 billion people.

LE and other certificate authorities* at least prove that your data wasn't tampered with in transit, or wasn't decrypted, read and reencrypted without any way for you to find out.

* as long as you trust those authorities

They could use something like VLAN to isolate that physical server on its own network, put the VLAN behind a firewall, and have an HTTPS reverse proxy that goes through that firewall.

Depending on how their network is built, it might even be possible to make this self-service where you enable a setting in your account and your physical server gets wrapped in this additional layer.

The world is far bigger than cloud computing and IoT devices. There must be millions of little in-house web applications someone wrote long ago that are still useful, probably running on some 10-year-old PC in the corner, with some sort of scheduled back-ups if you're lucky. There is also no guarantee that even a high-value, long-lived engineering device manufactured a decade or more ago and still in perfect working order also still has ongoing software support. There is a huge amount of value locked into these old systems, and arbitrarily dismissing their relevance if they don't meet modern security standards that may or may not even be relevant in all the circumstances is like designing a building with such robust security that no-one can get inside, even the owners.

These are just the general (and unsolved, or perhaps even unsolvable) problems associated with PKI. I think there’s a solid argument to be made about separating the encryption of communication from the authentication of server identity. That would solve one problem, but it would also just take an existing bad problem and (arguably) make it a lot worse. Given all of its horrendous shortcomings, the CA system is still the most successful PKI ever created, by quite a large margin.

Would you trust the authenticity of content that originated from a site signed with such a CA? If so, why?

PKI is just a technology for verifying trust over untrusted channels. But that trust is created in and remains rooted in the real world, and is itself built on societal chains of trust.

No technology, centralized or decentralized, will replace real world trust in human societies any time soon. Trustless tech only works if it's based on a society with trust. Otherwise the tech is meaningless.

Look at how many useful but Java-based demonstrations on academics' websites became inaccessible when the browsers decided Java plug-ins were evil and should be removed. What happened was not that people who had voluntarily spent considerable time over the course of possibly several years developing useful little bits of software suddenly dropped everything to redo all of that work again in a different language just because the browser developers had decided that other language was now flavour of the month. Instead, lots of valuable work was effectively lost.

(1) The poster arguing this was 10 minutes was being dishonest.

(2) As the original article said, it's a different internet if the only way to get something up is to go through Square Space or Github pages. It's much less decentralized, and much more corporate.

Yes, I do think the internet could have evolved to where a tech-illiterate mum could host her own web page from her router at home. It didn't, and we lost something in that process.

Frankly, that's impossible in any reasonable timeframe compared to just not allowing unsafe "huts".

If you don’t keep up the repairs, eventually the roof fails, rain gets in & then it’s a relatively quick slide into total ruin.

Obviously forget about any security.

When you're running a server, TLS is not the only service you are dependent on; you're also dependent on security updates. If they're not backported, you'll need to make version upgrades.

Arguably it's better to think of every piece of software running on a server like it's a service, to maintain security and performance in an Internet full of hostile actors.

I don't even understand the mindset of wanting to run a live server on ancient software, aside from doing it as a hobby. In which case, it's pretty typical for such hobbies to require extra work and care. Driving around in a car from 1940s takes more maintenance work, and is less safe, than a modern car, and everyone gets that.

Could have been yours ;)

If so they are only insecure because malicious JS can be MITMed into them, and realistically speaking browsers can’t defend against malicious JS.

> Modern computer security is about removing as many known possible attack vectors as possible.

So let’s remove enabled-by-default JS permissions instead of removing HTTP-content. Most old websites don’t depend on JS and would in fact be just fine.

Even better: make JS opt-in only for HTTP websites, and let users like me refuse the “upgrade” to HTTPS.

No it doesn't. HTTPS ensures that the data is not spied on or tampered with by those in the middle (so it does protect against what Comcast does), but does not prevent any other sorts of attacks (e.g. the server operator adding malicious files into their own server).

I should add a script to detect such things then, and if it finds one, display its own message to the user, to tell the user to disable JavaScript, with instructions about how to do so.

The Arc Language app that this forum runs on doesn't support HTTPS, so wherever the cert comes from, accessing the site is through a reverse proxy.

Yep, I live and work in one too! That's why I asked what it was. This is an edge case where I agree, it would add little utility. However, like you said, there are a lot of cases where there should be this sort of compliance but is not.

I actually thought you were referring to PLCs for public infrastructure or something similar to that. Sadly, I have gotten in arguments for people who do not want to even add encryption to talking to a PLC on the public internet.

Oh! That's actually a great little encapsulation of the larger problem here.

Before COVID hit, I was a volunteer teacher at a Girls Who Code class at a library. Most of the library's computers were running Windows 7, which of course lost security updates in January.

One of the other volunteers remarked: "Someone needs to update those to Windows 10."

I answered: "Someone should update them, yes. But no one is going to."

I don't even know if those old laptops could run Windows 10. Should the library really spend money on replacing all of them? As opposed to buying books, or teaching more students?

---

There was an article on Hacker News some time back about how the NYC subway system runs OS/2. A lot commenters said this is a huge security risk—sure, it's ostensibly not connected to the internet, but who really knows?

But, what should be done about it? It doesn't make sense to switch out the architecture of a city's subway system every 30 years—I'm not convinced it makes sense even every 50 or 100 years. How do you set up a system like that?

That's why I encrypt everything: you just never know what kind of things are going to catch the attention of the wrong people.

Do you also feel the same way about search engines? Should my Google searches be encrypted?

Seeing that tells me it is not just some sort of public website, and not something you just want any random person to access. Think like PLCs controlling public infrastructure (this is a real scenario in places) If it is on the public internet, I imagine the first thing you go is login to it. If it is HTTP, those credentials are going over the internet in the clear.

Why are you confusing https encryption with private vs publicly available information?

Let's unpack your concepts a bit using COVID-19 as an example[0]. The information that Wikipedia displays about COVID-19 is public information instead of top-secret classified files. But you'll notice that wikipedia serves its pages as "https". Think about why they do that. Even if you manually type "http" without the "s" in your web browser url bar[1], Wikipedia will still redirect you to "https". Why do they do that if COVID is public information?

As a web surfer, I also want wikipedia to serve its pages with "https". Think about why I would want that.

[0] https://en.wikipedia.org/wiki/COVID-19_pandemic

[1] this will still redirect to https: http://en.wikipedia.org/wiki/COVID-19_pandemic

...which is why numerous high-quality implementations already exist.

There isn't a way to say this without risking offending you, but if you can take it for what it is, I think you would benefit from it: you have posted a few examples in this thread where you think no one would care about encryption, and there are people posting here saying they do care about encryption in those cases. It might behoove you to approach this with a bit of humility and acknowledge that you are one of the people who isn't qualified to know when people need/want security, and your opinions are borne from that fact.

Actually that's incorrect. It's simple to add a LetsEncrypt cert in the right way -- but not easy to come up with all possible ways people might want to attack your site.

@kerkeslager wrote: "But there is always incentive for bad people to hack a server ..."

Those are good reasons, the ones you listed -- and yet another reason is that someone might want to use your website or app, to break into someone's else's website, e.g. by adding a link to, say, Google's login page, but the link is in fact to a password stealing site. -- And it's impossible to know when or if someone has the motivation to do such things to some of one's visitors / users.

1) I disagree that the modern web has degraded this experience much, if at all. If anything, the tools today are much better, easier, and more mature. Perhaps there's a few extra steps now, but Apache today is much easier to use than Apache in 1996, including things like installing it from a package manager. If you don't consider things like NearlyFreeSpeech and DigitalOcean "walled gardens", these have gotten much better as well. A few years back, I spent 30 minutes installing Wordpress and my completely nontechnical father was able to build a website. So no, things have not gotten harder, they've gotten easier. HTTPS perhaps makes things minimally harder, but many hosts will set up HTTPS for you with a free support ticket these days.

2) Removing the burden of HTTPS, and indeed removing the burden of a great many other things, still wouldn't bring you close to the ease of entry of Facebook or other walled gardens. Even though entry into the open web has gotten easier, it there has been a migration away from the open web because the closed web is so much easier. This isn't a problem that will be solved by getting rid of HTTPS. It's a problem that will only be solved by hacking open source software that does what Facebook et al does.

I'm sympathetic to your argument, but I've also seen a little tiny "I'm just storing a list of the CDs I own in a text file" apps blow up with multiple gigs of unwanted data, which _probably_ would not have happened with HTTPS.

Overall I'm on the side of "there must be some exceptions," but I have to admit that every month it's harder and harder to think of what the legitimate exceptions might actually be, given the toxic nature of the internet.

In those 5 years, HTTPS has gone from being the minority of traffic to being ~90% of the connections observed by most Chrome clients (scroll down a few graphs for the Chrome-observed one): https://transparencyreport.google.com/https/overview

Firefox has reported similar numbers. It's now more common for new web features to require HTTPS when they are introduced, to avoid developing HTTP sites as dependencies: https://blog.mozilla.org/security/2018/01/15/secure-contexts...

That doesn't mean that HTTP is banned, but given the magnitude of the change and the size of the web, I think it's fair to say that it's being deprecated.

More practically, anyone who wanted to build a product (or a government process) on intercepting or modifying people's unencrypted web traffic would find their dataset to be an order of magnitude smaller, and orders of magnitude less useful (since so much of the remaining HTTP traffic is in the long tail of small/older sites).

The crucial question is: do you control your users's DNS?

I had a setup like this in college, and wrote this: https://blog.sdslabs.co/2014/07/sdslabs-domain-working

There's currently no way on any modern system, as far as I'm aware, to install a CA but limit it to only a specific domain and its subdomains; any CA you install can issue a certificate for any domain. (There are theoretically some certificate extensions that allow limiting a certificate to subdomains, but as far as I can tell, implementations don't reliably support those extensions.)

Hard ask given how many don't work with JS disabled.

I have an SGI workstation and an HP workstation next to me. They cost $0.

That was >15 years ago, freecycled. Pretty sure they are less than $0 by now!