> a 12-year-old laptop still kicking isn't that big of a deal.
I have a 20yro TiBook. Both the RTC and the main battery are dead, and there's a tiny screen defect, but the machine is otherwise perfectly usable (if relatively slow). And by usable, I mean the desktop experience of Mac OS X 10.5 often feels more polished than that of some of the modern OS's...
The big bummer is that the modern web keeps raising a wall that's getting too tall for these machines to climb. TLS, JavaScript, and the firehose of new standards are making a lot of resources inaccessible.
(If you're in charge of maintaining a web server, please consider allowing unencrypted traffic on port 80 (rather than unconditionally redirecting to HTTPS), unless the Upgrade-Insecure-Requests[1] is present. Coupled with HSTS[2], it allows these "living museum pieces" to stay alive, while not compromising on security.)
This —- I really don’t care if my blog with no user registration or comments gets accessed over HTTP/1.1 without an SSL cert. Further, I find the way Chrome handles HSTS pretty gross, as some of us actually tinker with stuff that REALLY doesn’t need encryption, like little dev boards and projects running locally. Chrome makes those exceedingly difficult to use, thus the need for extremely convoluted workarounds like https://github.com/ip2k/I-Dont-Care-About-HSTS-For-Localhost (it’s my repo).
I do care. I don't want to have my name attached to any advertisements that shady airport routers may insert into the html for instance. TLS is a very good thing and we should have more of it, not less. Sorry that your unupgradable software comes from an era where security was not important.
> Sorry that your unupgradable software comes from an era where security was not important.
TenFourFox[1] continues to be maintained through community effort, and receives regular security fixes/backports. The problem is not software (although the project desperately lacks manpower), but the 20yro single-core CPU that literally sweats to push the crypto (let alone the CSS&JS).
Don't get me wrong. The relentless push for TLS is good, and I'm not arguing to take a step back - that would be insane. The change I'm asking for is, rather than doing [2] in your nginx.conf, do [3]. It doesn't change anything at all for modern browsers (when you hit that path, you're already at the mercy of an intercepting proxy), but makes your site more accessible for my ancient junk ;)
People don't care because they haven't seen what "advertisements from shady airport routers" even means. This has never been a real thing in most of Europe for example. I didn't care either until I traveled to US and had to check the homepage of my then employer. The experience can be compared today if you visit a ad-heavy shady news site with Ublock Origin on at first, then off.
My favorite pattern is serve all the content on http and https, but set the favicon to be fetched via https, and serve that with hsts. Preload hsts if you can. (Handling Upgrade-insecure-request seems good, too)
Then, modern browsers will use https after the first load and older browsers will use https, but probably not fetch the favicon.
It doesn't really hurt to return content instead of a redirect to connections that come in via http, if the user is being MITMed, they could make a http request and the MITM could make a https request and the server wouldn't know, and can't do anything about.
http makes passive observation easier of course, but there's not a huge difference between having the content and having a redirect to content that an observer could also load.
If modern encryption is that big of a performance drag, would using a proxy that deals with the encryption sidestep that issue?
With hardware that old and power-hungry, I'd expect a proxy hosted on a modern single-board computer in the local network to be essentially a rounding error on the electricity bill in comparison.
That would kinda kill the last hope of using one as a portable device. You'd either be chained to your home network, or have an extremely inconvenient dongle hanging from the side. (Unless you'd do the TLS termination e.g. on your phone.)
But that gave me some ideas. While the G4 PowerBooks are recent enough to be officially blessed with WiFi capability (via PCMCIA), Macs that are even older have to resort to community-made devices, such as BlueSCSI[1]. Perhaps it would be feasible to cram an SBC with on-board Wifi/BT into a PCMCIA form factor, and - in addition to providing physical network connectivity - use it for TLS?
This sounds like something an ESP32 or other wireless-capable microcontroller could do. It would probably be easier to fit a system-on-module than an off-the-shelf single board computer in a crammed space.
The proxy can also be hosted on a cheap virtual machine somewhere.
Personally I have a small proxy that convert HTTPS and Gemini to HTTP/0.9 with an option to use a readability library to keep only the content of the articles I'm browsing and not show anything else.
>(If you're in charge of maintaining a web server, please consider allowing unencrypted traffic on port 80 (rather than unconditionally redirecting to HTTPS), unless the Upgrade-Insecure-Requests[1] is present. Coupled with HSTS[2], it allows these "living museum pieces" to stay alive, while not compromising on security.)
So we kneecap the security of the general public in favour of the convenience of a few hobbyists? No. Nothing is stopping you from using a newer browser such as one of the many forks of Firefox, some of which exist solely to fill that need.
I agree with your stance on every single count but one. If your request already hits the plaintext 80->443 redirect, you've already lost; there's nothing the server can do to guarantee security, and refusing service altogether does not complicate the task for an intercepting proxy, because they can still make an upstream HTTPS request and serve it back over plaintext. That game was always lost, which was the original motivation behind HTTPS, and then HSTS.
This scenario is not hypothetical; it's literally what you must do if your hardware is not capable enough (my G4 struggles along, but older CPUs are the true test of patience). I wrote TLS-stripping, HTML-rewriting proxies for fun, and every HTTP client that trusts the web server with redirecting to HTTPS is vulnerable. If this affects you, the problem is that your web browser is likely more ancient than mine - HSTS with preloads has been a thing for like a decade.
I have a 20yro TiBook. Both the RTC and the main battery are dead, and there's a tiny screen defect, but the machine is otherwise perfectly usable (if relatively slow). And by usable, I mean the desktop experience of Mac OS X 10.5 often feels more polished than that of some of the modern OS's...
The big bummer is that the modern web keeps raising a wall that's getting too tall for these machines to climb. TLS, JavaScript, and the firehose of new standards are making a lot of resources inaccessible.
(If you're in charge of maintaining a web server, please consider allowing unencrypted traffic on port 80 (rather than unconditionally redirecting to HTTPS), unless the Upgrade-Insecure-Requests[1] is present. Coupled with HSTS[2], it allows these "living museum pieces" to stay alive, while not compromising on security.)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Up...
[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...