RIP HTTP
http.rip
http.rip
Also I would not be too hasty to expect the death of any widely used protocol. You can still access gopher sites.
Yep. http/2 in browsers does not support plaintext, the same will likely be true for QUIC
>You can still access gopher sites.
Not via vanilla mainstream browsers.
This is mostly because internet middle boxes choke on plaintext http/2. Plaintext http/2 does not work for a not insignificant portion of users so browsers didn't bother to implement.
But its a thing that does exist and you can use if you really want. Just not on the public WWWW.
HTTP/1.1 has a beautiful, elegant, simplistic essence; super easy to implement servers and clients from scratch with literally no dependencies beyond string formatting and basic TCP network APIs.
Uh, HTTP 1.0 doesn't support the host header, which means that you need unique IP addresses for each host you want to serve.
Ironically, you could solve that problem with IPv6, but...
A QUIC library (or proxy) which reassembles all streams and just sends presents you the stream contents would allow you to run HTTP/1.1 over a QUIC and you have the same visbility. Just replace netcat with a hypothetical quiccat. Now obviously this would bring you not that much value for a real world deployment, since browsers and other tools don't do HTTP/1.1 over QUIC but prefer binary HTTP/3 over QUIC. But the comment about "use a tool that gives you a readable representation" still applies. You can use curl to get a readable request/response, browser dev tools. And if you need more insight, qvis (https://qvis.quictools.info) is pretty awesome.
I'm betting that HTTP outlives me and goes beyond the time period I use the www. So far, so good. HTTP/1.1 pipeliing works better than ever. The www is faster than it's ever been and I can consume more web than ever before. I am generally unable to crash the web browser I use to read HTML. All the software I'm using is generally relatively small and solid.
This is only possible because I use TCP clients, TLS proxies and a text-only browser. If I were using a popular web browser I could not make the above statements. Heck, even the supposedly most advanced browser today will choke/become unreasonably sluggish if I try to open a large HTML file, say 20M or more. Whereas I do not hesitate to open/dump 20M HTML files using the text-only browser.
Anyway, I always thought CurveCP was more impressive than HTTP/2 or HTTP/3, which both came later. It did not take a mega-sized "tech" company to create it, only one focused person. No internet advertising needed. I would be willing to bet Mike whatever or whomever at Google used CurveCP for inspiration in creating HTTP/2 and 3. Google, with its trillions of dollars and hundreds of thousands of employees, still has not come up with its own encryption that is any better than what the CurveCP author originally came up with, which is now part of QUIC and myriad other software: https://ianix.com/pub/curve25519-deployment.html
It is what it is. History.
The localhost proxy I use is configured to send all HTTP requests via TLS so the GET request for http://http.rip was sent to https://http.rip, port 443. It appears to have worked. I guess someone forgot to disable HTTPS.
The 5.1M is retrieved using a TCP client, in a shell script, not a browser, and it is saved to a single HTML file. Obviously, I want the HN pages returned in sequential order. Normally I use HTTP/1.1. pipelining for this, and most websites enable it. HN is a rare exception. I have custom utilities I wrote for HTTP/1.1. pipelining. (HTTP/2 fans will often DV comments where I praise 1.1 pipelining since "HOL blocking" is one of their "justifications" for creating HTTP/2. But I'm not using a web browser, I'm not rendering a complex, graphical web page, I'm not loading up advertising, I'm not waiting for real-time ad auctions to complete. "HOL blocking" is not a problem I have ever had because I do not use a web browser to do pipelining.)
TLS proxy listens on localhost address. Authoritative DNS on listens localhost address as well, using a custom root.zone file. DNS points to proxy address for all domains. (This "redirection" could also be accomplished by using a firewall if one is available.)
The proxy has all DNS data pre-loaded into memory. There's no DNS lookups when I access a website. The proxy knows the IP address for every domain name I am interested in.
That's a basic overview.
HoL blocking issues would only happen for requests to the same host anyways. That situation does not apply to resources hosted on separate hosts. The reason its not an issue for you is you are basically using http for bulk transport. You are not latency sensitive and rendering is not being blocked by multiple dependent subresources with different latency characteristics, which is the problem http/2 is trying to solve.
That's great for you and all, but its a little like saying that fancy GPU cards are pointless if you are only using emacs. Certainly true, but also kind of a stupid statement to say technology made for a very different usecase doesn't provide benefits when used in a totally different way than intended. Hammers are bad at screwing in screws is hardly a news story.
[Edit: I re-read this comment, and it was kind of a bit aggressive. Sorry about that]
> and a text-only browser.
So you are saying http/1.1 pipelining works great if, checks notes, your use case is a text browser that probably doesn't download all the separate assets and thus wouldn't use (or just minimally use) pipelining anyways?
So yes,i agree. Http/2 & 3 is pointless if your usecase is different enough from a normal person that all the usecases it is trying to solve don't apply.
For the first time in years.
Hearkened back to ancient days when the internet was less of a war zone.
Whether this anecdote supports or refutes your point is an exercise for the reader.
Alpine is righteous, though.
If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranform it into more human-readable text, if necessary. No need for an HTML reader, i.e., browser.
For example, I currently have a list of 96,339 websites that work, meaning I can read the textual content. This is composed mostly from sites submitted to HN over the past 18 months.
It does not make much sense to try to put a Javascript interpreter into a text-only browser. Some have tried and it did not prove worthwhile. There are command line utilities that are much more efficient than Javascript for requesting and parsing JSON to text.
The purpose of a text-only browser is to read text/html, not to run arbitrary code, e.g., "web apps". If a website has some particular graphical presentation, e.g., some "fucntionality" that relies on Javascript, then one does not choose a text-only browser to see it. The text-only browser makes all websites look more or less the same. It's "anti-graphical". It effectively removes most of the variations in appearance and layout across websites, which as one might guess, are usually due to graphics (e.g., fonts), graphical content (e.g., images) and Javascript.
If like Office documents with non-textmode fonts and other graphics, then why use a text-only browser. Text-only browser, by definition, does not display graphics. (I do not use links -g.) Text-only browser is for reading text/html.
If just want to download a document from some Google Docs endpoint, then this can be done with an HTTP client or a TCP client. Could use a text-mode browser for downloading documents but most times it's overkill, not "right tool for the job".
Also even if HTTPS is forced, it doesn't mean HTTP is dead. HTTP is still the protocol we are running over a TLS connection, so it's here to stay.
This already happens with some major apps.
I don't believe Alt-Svc is required, and as you say Safari is behaving this way already.
https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3
Discovering an HTTP/3 Endpoint
A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
Don't they already have hardcoded DoH?
HTTP specs are also structured this way now:
• RFC 9110 defines HTTP semantics;
• RFC 9111 defines HTTP caching behaviour;
• RFC 9112 defines HTTP/1.1;
• RFC 9113 defines HTTP/2;
• RFC 9114 defines HTTP/3.
(The previous edition, RFC 7230–7235 for HTTP and HTTP/1.1, plus RFC 7240 for HTTP/2, was really a bit of a weird structure, a regression for practical use compared to RFC 2616 which 7230–7235 obsoleted. Defining version-neutral semantics and then the 1.1, 2 and 3 wire formats is a very sensible design.)
That's unlikely and risky.
Let's just face the fact here: people already tried three times to make a better HTTP protocol and still feeling unsatisfied, so certainly they'll going to make HTTP/4 and 5 etc in the future.
If all future HTTP versions must be identified via some kind of probing (say DNS or Alt-Svc), I would bet HTTP/1.1 will be kept as a baseline for compatibility. That means more versions there are, more important HTTP/1.1 will become.
Plus, to an user, what's the difference between these versions? It's not like some important web feature can only work on new HTTP protocol, but not the old ones.
Now I use neverssl.com.
A university I attended blocked all BitTorrent traffic at the protocol level. They theoretically allowed exceptions per their policy but when I applied for some bioinformatics images to be allowed they said they would only allow specific files for a 24 hour window. I applied for a file and got no response. I applied for 1000 files and got no response. Then I gave up.
I'm surprised you didn't set up your own system to work around the stupid restrictions.
(Yeah, they could just run a local one-liner web server, but that's not as fun.)
Even updated by RFC 6761, the practices surrounding example.com only go so far as SHOULD and SHOULD NOT.
That said, I think it's a horrible idea to treat example.com differently, but that's just because I can't think of a single reason why you would want to do so. :)
I guess any site that doesn't auto-upgrade would work, but I have a habit of typing out http:// for this site in particular because it doesn't work over https.
Also restricts the ability of ISPs to inject ads into other people's sites.
It has been around for a long time and is useful for making sure you see Wifi terms pages.
neverssl strikes a pretty good balance
> They're trying to solve the "how do log into this captive portal" problem, and they needed to make this change to handle that typing "neverssl.com" now often evaluates to "https://neverssl.com".
So, yes, it's still useful for WiFi logins. The change in question was specifically for that purpose. https://neverssl.com now redirects to http://neverssl.com so you can log in to WiFi even if your browser thinks it knows better.
It is a highly accessible, highly compatible protocol, highly usable protocol.
I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information.
So much of security is performance or ruining the convenience of things just for the sake of protecting things.
It's really frustrating. But hey it's to protect the kids or something /s
Edit: Also around half the pages I currently have open are passing through cloudflare anyway and signed by them, so a third party hijacking the connection to throw in ads is just one business minded CEO away.
Cloudflare's customers aren't going to stand for that and will find a new CDN if it was ever shown to be the case that Cloudflare was intentionally altering content they're rehosting. Cloudflare's imperfect, but Prince isn't that dumb, so we're years away from even the hint of that being possible.
Clock sync would be a requirement for access.
A recent device would be a requirement for access (not everyone can afford a new one).
Site admin keeping up with certificate registration would be a requirement.
Approval from the centralized certificate authority would be a requirement.
Server's self domain name matching accessed domain name would be a requirement.
These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.
Just a few of the reasons why all my websites still allow HTTP.
HTTP is also way faster on slow connections.
> Clock sync would be a requirement for access.
If you're on the Internet, then unless you have a religious reason against the NTP protocol, setting the time accurately is not a problem.
> A recent device would be a requirement for access (not everyone can afford a new one).
It's a fair point to raise, but if we target TLS 1.2 (1.0 and 1.1's been deprecated, and 1.3 support still isn't everywhere.) then all Android phones with Lollipop, which was released in 2014, and up support TLS 1.2. (The shittiness of cheap Android devices means phones from back then don't work anymore, so low end phones from a few generations back are more accessible than a Nexus 6 (Google's launch pre-Pixel phone for Lollipop) would be.
If you're on a laptop/desktop, there are no released versions of Chrome on Windows that are so old they don't support TLS 1.2. This includes the now-unsupported XP SP2+ and Vista. That dates back to 2007. On Apple desktop/laptops, Mac OS X Snow Leopard (10.6) and greater have Chrome support for TLS 1.2. I'm away from my 2012 Macbook Pro right now, but it's on something newer than 10.6.
So if your audience would have to be on 9+ year old Android phones, 16+ year old Windows computers, or a similarly old Apple computers (which is entirely possible), but they've already been excluded from the running any credit card transactions on the Internet (and have been since June 2018 due to PCI forcing the deprecation of TLS 1.0 and 1.1).
> Site admin keeping up with certificate registration would be a requirement. > Approval from the centralized certificate authority would be a requirement.
Let's Encrypt, which has been around since 2014 just handles all that nonsense, with automated support for most of the popular web servers. It's free (gratis) even for commercial and for-profit purposes, and is sponsored by the EFF, among other organizations.
> Server's self domain name matching accessed domain name would be a requirement.
That's not the case, unless you're using bespoke web server software. Name-based virtual hosting is quite common, even in the TLS world, and lets the client specify which service it would like to connect to. The web server is then configured to reply with the hostname that was asked for, and multiple services, (with different names) can be run on the same server on the same IP address.
Regardless though, if the primary failure mode you're worried about is users being denied access to your site, they can always just click through the warning to access underlying site. They'll be used to it from using the rest of the web (eg Wikipedia switched over to be exclusively HTTPS in 2015, and Chrome started labeling HTTP as insecure Jan 2017).
As for speed, I was in South East Asia recently, and found that cities had LTE and 4G, but while there were stretches of no service (which exists even in a rich nation like the USA), what surprised me was finding EDGE cell data. If you're that constrained then sure.
I run a trivial site via http and I don’t care about isps and coffee shops injecting ads. I’ve never witnessed this myself or known anyone affected, but my site is free and non-commercial so I wouldn’t care if a location did that.
For me, it’s worth the removal of a minor chore to not run ssl. Comically, my host automatically ads ssl every once in a while, then tries to charge me, then breaks ssl.
What's even more fun is when people inject actual attack code because every major browser executes javascript by default.
Running non-ssl on the public internet is like unprotected sex with a random partner. Maybe because you've not witnessed a STD doesn't mean that there aren't a entire shitload of them out there that present real risks to the population.
That's not the only attack TLS is trying to thwart (although it is a major one). Passive surveillance resistance is also a big use case of TLS.
I think the biggest thing though, is everyone has pages that are sensitive some of the time (e.g., I want to visit my bank over TLS). It is really really difficult UI problem to give people actual security when TLS is only on some of the time. Users never really understand how the security stuff works, and it is usually trivial to trick them unless you basically do forced TLS everywhere. Its also hard to know what is sensitive to users as it varies by place (e.g. Tianamin square article on wikipedia. Maybe in other places, websites about abortion, etc. Some places nobody cares if you look that up. In other places it is a big deal. Difficult to make things secure only for the users where it matters.)
For much of the internet this is not protected as people use Chrome that performs passive surveillance.
For me, I’ve accepted passive surveillance for routine day to day activities. So I don’t care if my http traffic is analyzed by Starbucks or anyone. My TLS traffic is deep inspected by google through chrome, at work it’s literally MITM’d and inspected by IT, and at home the dns data is tracked by my ISP or google or maybe not cloudflare depending on my DNS, and otherwise inspected through host headers by my ISP and everyone in between.
I don’t think this is even a factor in deciding if my site is http or https.
Without https they could just mitm everyone without their knowledge.
https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
The way I handle it is I have the captive portal DNS name in public DNS returning a private address. When I order the CA cert from my cert provisioner of choice, I'm able to pass all verification checks. I'd use LetsEncrypt if I could, but good luck getting that going on a Cisco Wireless LAN Controller.
The problem is: If the first connection of the client is a https connection, your captive portal has no possibility to redirect this request to the portal.
HTTP isn't going anywhere. HTTPS is literally just HTTP with a TLS layer on top.
The only thing that might become less common is "HTTP/1.1 over TCP". But I get that this is much more verbose to write than "RIP HTTP".
Whoa whoa whoa! That is a lot to unpack right after that pledge. "I know I suck but I pledge to be here for you always!"
This feels like some kind of a personality crisis. Maybe we should take a moment to feel out the pros and cons more gently.
Surely _captive portals_ can't be the only thing going for you, HTTP ol' buddy!
(I mean...surely?)
HTTP is alive and well. Most people don't realise a lot of software/OS updates come through HTTP so that HTTP caching servers have an opportunity to do their thing.
But but... what abouts th3 securaitai?
The updates are signed. Tamper with them all you like.
(Mind you, you’ll often be able to do a good job of guessing based on the side-channel leak of how much data is transferred.)
See also: pervasive monitoring is an attack <https://www.rfc-editor.org/rfc/rfc7258.html>.
I would expect all major operating systems to deliver their updates over HTTPS these days.
(I know Arch Linux’s mirrors are widely available over HTTP and HTTPS, but the first mirror in the list is HTTPS, so the considerable majority of users will get packages over HTTPS—though since the second is HTTP, all it takes is DNS-blocking geo.mirror.pkgbuild.com to cause it to fetch over HTTP.)
As for “so that HTTP caching servers have an opportunity to do their thing”: how much do public intermediaries do caching any more? I don’t know how popular that kind of thing ever was, though I know it did happen sometimes, but with how uncommon plain-text HTTP is now, I’d honestly expect most vendors to just drop that functionality as almost-unused complexity.
tbf, I'm being a bit hyperbolic. Its totally reasonable to have security at different layers. One good thing about HTTPS though is it is a very well tested layer. Crypto is such an easy thing to screw up, even when doing just basic stuff.
If letsencrypt would offer wildcard certificates with their url based authentification as they offer for non-wildcard certificates, it would be annoying but bearable.
But having to tinker with the DNS infrastructure for each project which wants to use domain wide HTTPS is so much hassle.
The problem is that letsencrypt does not offer url based authentification for wildcard certs.
So you have to temper with your DNS infrastructure so that you can automate DNS updates for your domain.
For good reason though. You shouldn't be able to get a cert for a domain you cannot prove you control. Lots of people have webserver access to a specific domain but not all subdomains.
I am not aware of any service that allows that.
Can you give an example? What do you mean by "lots of people"?
The way we run public certificates may have 100 holes in it, but the entire thing isn't open for easy attack for anyone that's clever enough to see and modify a packet to whatever they want.
ocassionally -> occasionally
That the web's core transport protocol used to lack encryption and authentication is an artifact from a time when nobody thought that the Internet was ever going to be used for anything of real-world value.
HTTP is a dinosaur. The age of the dinosaurs is over. It's slightly cool and quirky that it used to be a thing, but we should all be glad that it isn't anymore.