I absolutely love it, that the website is available over plaintext HTTP. (The maintainer(s) should consider honouring the Upgrade-Insecure-Requests header[1], so that modern browsers still get the HTTPS version.)
I've recently got my hands on a PowerBook G4 (2002), a quite interesting and still somewhat capable machine; however the OSX version it's stuck on (10.5.8) is having more and more problems reaching the TLS-secured web: TenFourFox is no longer maintained; Safari, curl, etc are all built against an ancient release of OpenSSL; etc. Even downloading TenFourFox is no longer possible, as system Safari can no longer load SourceForge, since SF requires a more modern TLS version than what the OS can understand.
Treating both plaintext HTTP and modern HTTPS as first-class citizens is the way to go for such projects & efforts, so hats off.
Oh thanks for the tip! Did not know about the Upgrade-Insecure-Requests, will have a look and add to the wiki :)
Your story is exactly why we gave both HTTP and HTTPS access. I'm also still super inspired and happy to see how the whole Amiga website ecosystems tend to be served mostly over HTTP, so that it's possible to browse such resources on the most modest/limited/bare configurations.
Just wanted to toss an idea, you can run latest OpenBSD on that G4 PowerBook and it should run well (and have all the latest encryption/security features of course). I've got it running on an iMac G4 (among many other older computers). Of course I also know OS X has its own appeal, just throwing the idea out there in case you weren't aware! :)
I do absolutely love OpenBSD, and I'm enjoying it on my Thinkpad already. It makes for an awesome desktop/workstation, and I actually feel very productive using it.
I have different plans for that machine. I'm planning to max it out (it's an A1025, so 2x512MB RAM, 802.11g, IDE->CF adapter + 2x64GB CF for storage, battery replacements, etc), and try various OS's of the era: MacOS 9.2.2; OSX 10.4, 10.5 and developer preview for 10.6; maybe even BeOS - to see which one(s) I like the best. Perhaps it will end up with OpenBSD on it as well! I'm also planning to do some development on each of these OSs :)
Niiiice, sounds good. Indeed, I have a few machines with their "original" (or originally-supported OS), and then sometimes try different stuff on them. BTW, another cool one to try on PowerPC is Haiku OS! I haven't yet tried it myself, but... https://www.haiku-os.org/
Haiku might not be the easiest thing to try, judging by their docs[1], the PowerPC port seems dead, with not much interest from the dev team to continue - understandable, it's a niche OS on a niche platform. It's a lovely system though, runs great in a VM - maybe something to run on a spare x86 box :)
I allow http:// on my personal site as well due to this reason. I strongly support the use of old computers (and am planning to remove all JS from my site, just haven't got around to replacing the ready-made theme I started with). "Old" computers are only "obsolete" because corporate powers pushed forward and left perfectly-working stuff behind.
> I absolutely love it, that the website is available over plaintext HTTP. (The maintainer(s) should consider honouring the Upgrade-Insecure-Requests header[1], so that modern browsers still get the HTTPS version.)
And browsers should honor HSTS sent over HTTP. And hstspreload.org should not refuse to include sites that maintain HTTP access instead of just redirecting to HTTP. And https:// should never have existed as a separate URL scheme.
It sucks that security advocates refuse to consider backwards compatibility even when for most websites the only attack they really need to protect from is malicious (US-based?) ISPs injecting ads, which should have been solved via legislation instead.
I'm actually doing this kind of thing at work right now. A client has a piece of software written by a vendor that went belly-up in 2007. The software is a central part of their business (don't ask me why they didn't try harder earlier to replace this piece of software in the past 15 years), but only talks SSL 3.0 and talks to internet resources to function.
We had set up a shim for them to give them time to fix this mess, by setting up mitmproxy[0] explicitly enabling SSL 3.0 and upgrading the protocol for external requests. Since then, the shim has been killed by a careless upgrade, and it turns out that most SSL software (including OpenSSL) can't even be forced to talk SSL 3.0 anymore. If you want to get OpenSSL to talk SSL 3.0, you need an old version. The modern versions maintain the enable-ssl3 option, but it is always forced to no-ssl3 at configure time. I don't know if there's an easy way around this, so I've set up a docker image that pulls and builds and old version, and installs an old version of mitmproxy (along with python's cryptography and other dependencies).
It's not elegant, but it does technically work, for now. At some point, it's likely that the ciphers supported by it won't be supported by the modern internet, in which case I suppose you could daisy-chain mitmproxy instances, each upgrading the protocols for the last.
If somebody has a better idea for this kind of situation, I'd love to hear it. I hate this setup and would love to have a more elegant solution.
edit: I actually discovered that OpenSSL 1.1.1p doesn't force no-ssl if you do enable-ssl3 as well as enable-ssl3-method. That's a much more workable solution, and passes tests. I mentioned OpenSSL 3.0.4 in a previous edit of this comment, but it turns out that compiles, says it enables ssl3, but fails to complete an SSL 3.0 handshake.
edit 2: If anybody is curious, here's a working Dockerfile example for this, with configuration, volumes, and path stuff left as an exercise for the reader: https://paste.ofcode.org/uCyMuF6NtLKGyesT8FKYTB
Not really insecure, because all communication over the public Internet is done on TLS 1.2+. Really, it's at worst as insecure as just using HTTP to the mitm proxy and then having the proxy do the encryption to the outside world, given that the SSL3 connection is entirely contained in a private network. I had actually suggested that initially, but the software refuses to communicate without SSL (which was a fine policy at the time). Also, SSL3 isn't actually that insecure when there is no possibility of controlling any aspect of client communication.
> Why don't you modify the hard-coded `no-ssl3` config and try re-compiling?
I was actually missing an option, but it still doesn't work with OpenSSL 3.0. Fortunately, 1.1.1 works with it just fine, including the latest version released just today.
The biggest challenge is in getting the machine to download a modern TLS implementation in the first place. You could just use a different, modern machine for that, but this asks interesting questions about our software/formats/protocols supply chains. How recent does a machine need to be, to be able to upgrade to anything at all? Can you understand what the software you're running is actually doing? With the forked Firefox being hopelessly behind upstream, what are the risks of running an outdated stack - should you bet on being obscure enough to not be a target, or take every precaution, such as just disabling JS altogether?
I've recently got my hands on a PowerBook G4 (2002), a quite interesting and still somewhat capable machine; however the OSX version it's stuck on (10.5.8) is having more and more problems reaching the TLS-secured web: TenFourFox is no longer maintained; Safari, curl, etc are all built against an ancient release of OpenSSL; etc. Even downloading TenFourFox is no longer possible, as system Safari can no longer load SourceForge, since SF requires a more modern TLS version than what the OS can understand.
Treating both plaintext HTTP and modern HTTPS as first-class citizens is the way to go for such projects & efforts, so hats off.
[1]: https://developer.mozilla.org/en-US/docs/web/http/headers/up...