Plaintext HTTP in a modern world | Hacker News Reader

Plaintext HTTP in a modern world

jcs.org

49 pointszdw56 comments

It's not just sensitive information that users send, it's the information you send back. Your users are implicitly (knowingly or not) allowing their ISP, wifi hotspot, or anyone else who might be snooping to see what they're looking at and sell that information, inject ads or malicious code (if you're browsing on IE6, lord help you), or worse. I want neither Comcast nor a government nor a credit agency nor an unscrupulous proxy server/VPN nor a corporate firewall administrator knowing what's on the pages I or my visitors look at. And I don't want crapware/ads/lies jammed into those pages by lord knows who.

The problem here is that if someone can intercept your unencrypted traffic, they can also disable the headers that instruct the browser to switch to HTTPS. That means that unless you're getting your site preloaded into the browser as requiring HTTPS, folks on modern browsers who hit an unencrypted URL on a malicious network are as good as compromised, and they can not only read the traffic but modify it as well. And unless you disable non-HTTPS traffic, there's nothing you can do about it.

I would strongly recommend against taking the steps in this article unless you're running a site specifically for vintage computing enthusiasts.

Your isp (or any middle man) knows the IP address you’re connected to. On a public website they know everything you’re seeing anyway, if it’s encrypted or not.

> Your isp (or any middle man) knows the IP address you’re connected to.

The proliferation of CDNs made this mostly moot (big exception are huge companies or individuals who want to control everything using their own IP addresses) to the point governments tend to try to actively intercept requests due to the stubborn opaqueness.

It’s not mostly moot. Most web sites do not use CDNs.

And to the extent that websites do use CDNs, then your isp is no longer your concern for privacy, the CDN is.

There’s also SNI leaks (for now).

Valid point, kind of hard to solve actually because at some point the server needs to know who are you talking to. Limiting it is the current target for proposed standards, but alas it is an open problem for now.

> Most web sites do not use CDNs.

And unless your typical user is actually a developer, you are out of the park.

I forgot about SNI leakage. That's a valid point.

There are CDNs you wouldn't have thought to be actually CDNs. Most Wordpress sites (outside of WordPress.com) are actually being run on WordPress.com infrastructure, and even if not they are often shared installations such as from Namecheap or GoDaddy, which shares the same addresses. Not to mention alternative building sites like Wix, Squarespace, Carrd, or even GitHub (surprise!). Or independent shopping sites, most are actually just Etsy (operates on etsy.com) or Shopify (you can use a domain if you want to). And that's scratching the surface of how changed web is now.

You have underestimated how centralised is the web now. This can be bad or good (despite comments from second-hand critics, the French Minitel was amazing for its time, and on the flipside Facebook).

To the extent that the web is centralized my second point holds: TLS does nothing to protect you from the platform owners and you’re not much worse off going plaintext.

I suggest reading this presentation and blog post:

"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf

https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...

> Its protocol author argues that TLS is just a simple dependency no different than a TCP server module, so it should be trivial to implement in any client or server. But if your computer’s CPU is so slow that a modern TLS negotiation would take so long as to be unusable, or its platform doesn’t have a TLS 1.2 library available, that makes it impossible to write a client without depending on an external modern system.

This is asking for everybody else to put in the time and effort for you to do the computing equivalent of restoring classic cars. Someone proposing a new Internet protocol in 2021 doesn't need to include compatibility with freaking _System 6_ Macs.

"This requirement seems poorly thought out, especially considering the Gemini protocol doesn't even support forms (other than a single text box on a search form) so there's no chance of users submitting private data, and there's no mechanism for client-server sessions so clients can't be authenticated, meaning everything served pretty much has to be public anyway."

No chance? Everything has to be public? WTF? How does he arrive at this conclusion?

In Appendix 1 of the Gemini protocol one of the status codes is "SENSITIVE INPUT". It specifically gives the example of passwords.

One of the error codes in the Appendix is "CGI ERROR". This would seem to contemplate generating content dynamically, e.g., a user submitting ad-hoc queries to a database.

I would love it if all websites did not force the use of TLS and provided a plain HTTP option, but there are easier solutions for older computers than trying to get the web to change. (Good luck with that.)

One solution to to use a gateway the user controls, sitting between the vintage computer and the internet.

One can run a proxy on the gateway and have control over changing/deleting request and response headers like Upgrade-Insecure-Requests, Upgrade and Strict-Transport-Security, and TLS offloading/termination.

It works for me. Both for older software and older hardware.

This is really a nice point. My parents' home computer is about 12 years old. They have a Windows XP machine, which is too basic to install Windows 10, so even upgrading Chrome and Firefox is not an option. (They cannot use Linux, let us not go there.) Many websites don't load because the desktop supports only legacy SSL, which the server (rightly, if it is serious about SSL), does not support. However, I feel that the point that the author makes about many websites not needing SSL is to the point. The author seems to suggest the right approach, since it leaves the choice to the user.

k-meleon supports XP. http://sourceforge.net/projects/kmeleon/files/k-meleon/75.1/...

Older versions of Otter Browser too, I think. https://sourceforge.net/projects/otter-browser/files/otter-b...

Uncompress it in a folder, and run.

I was running into similar problems running OS X 10.9. What I eventually did was set up a proxy server which MiTMs all https traffic and re-encrypts it. This totally worked, suddenly reviving all sorts of apps that I'd thought were broken forever.

Since other people were also having this problem, I ultimately put together a nice little installer. It's very Mac-focused, but if you have access to a Mac, you could extract the pkg to see how Squid (the proxy I use) is configured: https://jonathanalland.com/downloads/wowfunhappy-https-proxy...

It's probably not worth the effort to set up something like this for your parents, but I do think these sorts of proxies are a good (if imperfect) solution for old systems. You could plausibly set them up at the router level too.

Proxomitron can also do "SSL upgrade" thanks to OpenSSL, and being a MITM is useful for the usual things like adblocking and custom page styling.

That said, an IE6 user agent connecting to a TLS 1.2-only site showing up in server logs is probably a source of amusement and perplexion for some...

Have you tried Firefox 52 ESR? it no longer received updates, but it should work on XP (SP3 at least), and supports TLS 1.2, which almost every site should support nowadays. It should work fine for a while until we gradually move to TLS 1.3+ exclusively, and there is no deadline set for that.

I will try this, thanks for the suggestion.

This article criticizes Gemini[1] over its TLS requirement, saying it "makes it nearly impossible to access from a vintage computer or even a modern embedded system with limited CPU power".

The Gemini FAQ[2] addresses this point:

> Old machines are awesome, and keeping them running, online and useful for as long as possible is an awesome thing to do. But it also makes no sense for the vast majority of internet users to sacrifice any and all privacy protection to facilitate this. Remember, though, that Gemini does not aim to replace Gopher, so the retro-compatible internet is not directly endangered by it. In fact, people serving content via Gopher right now are strongly encouraged to start also serving that same content via Gemini simultaneously. Retrocomputing fans can continue to access the content via Gopher, while modern computer users who wish to can switch to Gemini and reap some benefits.

The blog post also says:

> This requirement seems poorly thought out, especially considering the Gemini protocol doesn’t even support forms (other than a single text box on a search form) so there’s no chance of users submitting private data, and there’s no mechanism for client-server sessions so clients can’t be authenticated, meaning everything served pretty much has to be public anyway.

While it's true that Gemini doesn't do uploading, simple text input (using query strings) can still easily hold private data.

More importantly, this completely ignores that TLS protects browsing history, and the integrity of pages. When I browse Gemini I don't have to worry about anyone watching what pages I visit, or changing them on the fly. TLS is the reason for that.

Finally, the claim that "client's can't be authenticated" is false. Gemini uses client certificates to allow users to log in to services such as private directories, message boards, and virtual plant growing games[3].

1: https://gemini.circumlunar.space/

2: https://gemini.circumlunar.space/docs/faq.html

3: https://github.com/michael-lazar/astrobotany or gemini://astrobotany.mozz.us

My main takeaway from this article is that the correct way to support older systems is not by supporting older versions of SSL/TLS. It is better to add support for plain HTTP delivery and only support modern SSL/TLS variants. Since the author recommends upgrading anyone with 'Upgrade-Insecure-Requests' header I don't think there is a downside to doing this.

If you truly don't have legacy clients trying to visit your website then 99%+ visitors won't see any difference in behaviour. So no reason NOT to do this.

There are many downsides.

First, a response without the redirect is still a "successful" request. This easily allows a middle man to observe and modify the response and request. With a 301 redirect, the server is not sending any html/json/etc content to the server - just the header.

Search engines, HTTP caches, bookmark managers, etc they all accept and update their indices upon 301 redirects. Non-browser user agents are unlikely to read and interpret CSP headers.

I am firmly set that these older user agents without SSL support, or ones with old vulnerable implementations are not worth supporting. You are taking the security level of everyone down, just to support that likely minority. They are already having problems with several other sites. They upgrading their hardware/software is the easier compromise to make, compared to the web site lowering the security for everyone.

> This easily allows a middle man to observe and modify the response and request.

The article is aimed at personal websites and blogs where security is not a significant concern.

Whats the downside of search engines and bookmark managers using the HTTP url ? Users who visit the link will get upgraded anyway.

> It sounds like the perfect thing to bring modern content to vintage computers, except that its protocol requires all content to be transferred over TLS 1.2 or higher which makes it nearly impossible to access from a vintage computer or even a modern embedded system with limited CPU power.

A modern embedded system with limited CPU power that can't do TLS 1.2? An ESP8266, one of the cheapest modern embedded systems can do TLS without problems. Heck, I've seen one or two ATTiny85's doing TLS (with some stability problems... But they're not called tiny for nothing).

If the AmigaOS project can do TLS (builtin since a decade ago) with less than half of the resources that the authour says results in an unreasonable wait time (their System6), maybe it isn't actually the hardware that is the problem.

Maybe he means an old m68k or some z80 speccy opening Gopher sites.

> But if your [computer’s CPU][0] is so slow that a modern TLS negotiation would take so long as to be unusable

The author is actually pretty explicit that they're talking about a System 6 Mac, which has all the hardware necessary not to be too slow for TLS. It's just that it's so old that finding a working SSL library for it is difficult, which on some fronts I can sympathise with...

But SSL should still be a requirement to prevent your users from having crap injected by whoever the hell is between you and them.

[0] https://jcs.org/system6c

> System 6 Mac, which has all the hardware necessary not to be too slow for TLS.

Eh, maybe not CPU wise, but 4MB of RAM are a bit shortish.

AmigaOS manages it with 512Kb of RAM.

I know Amiga has modern SSL libraries, but with just 512kb of RAM to run iBrowse? Sure?

I tried to emulate some m68k macs, and definitely, as the PC, 8MB are the minimum enough (with paging) to browse without issues with an old Netscape release, or icab.

PC's have it easier because a stripped Minix2 with Lynx and some light SSL library could do that with ease on a high 486/Pentium and 4MB of RAM.

One day I'll compile a modern Dillo with mbedtls for a virtual 486 with 4-8MB under Qemu.

ATTiny85 - I doubt it. With 8k program memory and 512B data RAM you will have trouble fitting in a single cipher and hash function, let alone the TLS + TCP stack. And ESP has HW acceleration for crypto.

> ATTiny85 - I doubt it. With 8k program memory and 512B data RAM you will have trouble fitting in a single cipher and hash function

It paged to disk. Including dropping functions in and out of flash to disk. I did mention it was unstable, right? But it's still doable.

That must have been quite something.

These protocols are all too heavy. My blog is available over raw TCP:

  nc apitman.com 2052 <<< /txt/feed

For the purpose expounded by the author, I find this to be a good move (somewhat similar to accessibility). I agree that serving HTTP to old machines and browsers is better than providing a false sense of comfort by using broken ciphers and protocols. Continuing to serve HTTPS for newer browsers with stronger protocols sounds like a good way to serve more people.

Aside from addressing the CSS and JS minimalism required for such sites to accommodate older browsers, how would one get the server settings done on Apache on a shared web host? The author provides instructions only for nginx.

Anecdote:

I recently found a 6 year old Android phone and tried to use it.

I can't use Google Play Store to install apps because I can't log into my Google Account, apparently because of old certificates or SSL versions, or something.

I can't use Google Chrome to download APKs. Downloads get stuck at 0%, apparently because Chrome doesn't trust the certificates. And when I browse, Chrome tells me that the site is not secure.

And I was unable to transfer APKs via USB. I don't really know why, I have developer mode and all of that enabled.

So, I guess it's bricked.

I'd be interested to know, in a parallel universe, had you updated the device continuously through normal usage as a primary phone, whether it would be just as bricked or not. That is, did you miss some window during which its old crypto would've been replaced with new crypto?

Host an FTP server, or send the APK's thru MTP.

Or, from a a PC from Linux hosting a directory of APK's (if you connect your phone to the same wireless lan): python2 -m SimpleHTTPServer 8080

connect from your phone to http://ip_from_pc:8080 and it will work.

Then send the Fdroid/Fedy APK to install new browsers.

thanks

Can you sideload a copy of Mobile Firefox?

This deprecation makes no sense, just because you want to use HTTPS should not mean you remove the ability for others to use HTTP.

There are many things HTTPS (and HTTP/2+3 or websockets for that matter) can't do, the energy use is not an issue now as long as money is "free" and there still is stored sunrays in the ground, but eventually everything will use HTTP/TCP again.

I for one do my own security over HTTP and I save alot of time/energy doing it!

How long is reasonable to support browsers or devices that can’t even do HTTPS? HTTPS started with Netscape in 1994, 26 years ago?

And how is your computer from more than 26 years ago still connecting to the internet? Via dial up?

Ethernet was introduced in 1980 [1], 41 years ago.

[1] https://en.wikipedia.org/wiki/Ethernet

While you can buy Ethernet service, e.g. from my ISP, I would anticipate that the set of people who have purchased Ethernet to the Internet and can't do TLS is empty. It's a niche service, it's fast, it's symmetric, it's expensive.

Also you're going to need one hell of an adaptor to connect Ethernet from 1980 to modern Ethernet. The bit protocol is the same, but the hardware is radically different. I have never used the original Ethernet, but I have personally built 10base2 networks (still have terminators in various bit boxes) and I've seen some setups with 10base5 which is the earliest Ethernet that was actually commercially deployed:

https://en.wikipedia.org/wiki/10BASE5

> Also you're going to need one hell of an adaptor to connect Ethernet from 1980 to modern Ethernet.

There's actual quite a number of them (like [0]) around. They can be large, but considering you can go from parallel to modern ethernet _and_ you have a choice of adapter, it's not really as big a problem as you might be foreseeing.

[0] https://amiga68k.com/?product=plipbox-deluxe

Um. Did you mean to link something else entirely?

That's a Plipbox. One side of it speaks 10baseT (or maybe 100baseT, it doesn't really matter) and the other is a literal Centronics-style parallel port, not Ethernet at all.

The idea is, your Amiga can do PLIP (IP over the Parallel port) and this box turns that into Ethernet traffic which you can drop into any network with IP.

But if you've got some 10base5 or earlier Ethernet, this does not help you at all.

You can bridge Ethernet to other things. There are ports for 10/100 on most ISP client devices (eg: Comcast Modem). 10b2-5/10bT bridges are still available

> I would anticipate that the set of people who have purchased Ethernet to the Internet and can't do TLS is empty.

...what am I missing? Cable and DSL modems have ethernet ports don't they? Ethernet ports still support 10Mb/s and hall-duplex right? You might need a transceiver to physically adapt the connection, but its still ethernet... well, unless we're talking about pre-802.3 ethernet of which I'm not sure how compatible the frames are.

Serial to wifi adapters exists. You basically connect to the hosts with a fake SLIRP connection.

Define HTTPS. SSL? TLS? Which version?

The oldest "safe" version is TLS 1.2, which only gained browser support late 2013, so 7 years ago.

The article recommends not using the older unsafe versions for the sake of older browsers.

IMO its reasonable to require that users have close to the most up to date software that their devices support. So its fine to kill off browser support after a year as long as the site can still be accessed on a 10 year old bit of hardware.

1 year? Jesus christ. You know, in other industries things are routinely supported for decades. It is a good thing large chunks of actually essential infrastructure aren't designed by web people.

Its really not acceptable to be using a web browser 1 year behind on security updates. Especially since almost everyone is using an auto updating browser now.

Once a feature has been out on all major browsers for a year than its fair game to use. Its also not wasting your time trying to develop a modern web app which has support for netscape navigator.

Going off the usage stats of the site I work on, almost everyone is on the latest version of their browser and the ones that are not always end up upgrading after a warning notice is sent out about old borwsers.

Your web app should basically work (at least essential functionality) on something like lynx as that is a decent proxy for screen readers or other accessibility aids. You'll be looking at ADA complaints if you don't.

> I want neither Comcast nor a government nor a credit agency nor an unscrupulous proxy server/VPN nor a corporate firewall administrator knowing what's on the pages I or my visitors look at.

I have some bad news for you: if you use HTTPS, they also know what's on the pages you're looking at.

>r its platform doesn’t have a TLS 1.2 library available

A Pentium3 can run Dillo with mbedtls just fine.

i support the author and develop with the same ideas of any browser, anytime, in mind.

Off-topic: does anyone else here prefer to use "plaintext" as exclusively the opposite of richtext, while instead using "cleartext" as the opposite of ciphertext?

I realize that "plain" is acceptable here, but I never got into it.

Reply on news.ycombinator.com