The real death of HTTP isn't that HTTPS is being forced. That's good and bad but at least you can chose and it's HTTP underneath. The death of HTTP is "HTTP"/3 which is barely related to past HTTP protocols and doesn't even allow a choice. Eventually the megacorp browsers will drop real HTTP/1.1 support from their browsers for QUIC based transport. That will be the death of HTTP.

HTTP/3-only will not be a thing in the foreseeable future. One major reason is that clients actually need knowledge that a website supports HTTP/3. And how do they obtain that knowledge? It's over a HTTP/1.1 or HTTP/2 request which returns the Alt-Svc: h3 header. It will probably take decades until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported - and only after that websites can drop HTTP/x over TLS support. HTTP/3 is also just 50% as CPU efficient as TCP based HTTP versions, so using it doesn't make sense for every use-case.

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.

Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker.

This already happens with some major apps.

Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.

I'm not sure the specification says what you describe, it doesn't in my reading.

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.

This seems correct. But as the spec says, some services might run HTTP/3 on a different port than 443 - e.g. for load balancing purposes. Those setups would fail if clients just try to connect to 443.

>until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported

Don't they already have hardcoded DoH?

DNS over HTTP is something different than Service Discovery over HTTP (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...). The latter is plain DNS, but allows to transfer alternate service responses as part of the DNS response packet. As you can see from the link, it's still in a draft state.

If they have their own DoH, it can send them any response format. http3 drafts are supported in the wild too.

HTTP/3 is absolutely related to past HTTP protocols: it’s built upon HTTP semantics.

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.)

What's interesting about this doomsday scenario is it suggests that a few web browsers dictate the course of the www, not several billion websites.

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.

> HTTP/1.1 pipeliing works better than ever

> 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.

I just installed lynx the other day in an Alpine guest machine to pull down some source code.

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.

Unfortunately lynx, links and and w3m will only work on a subset of websites.

Can you provide some examples of websites that do not "work". I really want to know.

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.

I would expect Google Docs to fare poorly in text mode.

Yep, graphics do not work. That's why it's called a "text-only browser".

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".

Crying shame, that.

Would you mind sharing details on your tools / setup? Intrigued by this.

Here is an example. I often read HN as a single web page. Today this is about 5.1M for me and there are about 2945 items. In the text-only browser, opening this file works smoothly enough. Whereas if I try opening this 5.1M file in a popular browser, for me, it's sluggish and janky. NB. This is _not_ the sole reason I avoid using a popular browser. It's just an observation. I have been using text-only browsers (not lynx or w3m) for over 20 years and I will keep using them until I am dead.

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.

> HTTP/2 fans will often to 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 and all pages I'm requesting come from the same host. "HOL blocking" is not a problem I have ever had

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]

This is the kind of thing I really come here for. Thanks for sharing.

It's why I am here, too. Because there are folks who can appreciate it. Cheers.

> Eventually the megacorp browsers will drop real HTTP/1.1 support from their browsers for QUIC based transport

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.

What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure?

Also I would not be too hasty to expect the death of any widely used protocol. You can still access gopher sites.

> What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure?

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.

> Yep. http/2 in browsers does not support plaintext, the same will likely be true for QUIC

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.

Presumably the non secure equivalent for internal services will just be a self signed cert. So you don't lose any existing capabilities.

Correct, TLS is built into the protocol itself instead of it being HTTP wrapped in a TLS stream.

1.1 will survive due to low resource IoT devices where the extra burden of caching state is too much of an imposition.

Not educated on this, but whats the problem with it?

With HTTP/1.1 you can debug a request via an ASCII telnet session. Not feasible with QUIC.

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.

You can debug it because the telnet tool and the kernels TCP stack reassemble a lot of binary TCP and IP frames for you. If they wouldn't, you would have a much harder time looking at it.

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.

You can effectively debug unencrypted HTTP using tcpdump, no reassembly usually required because a request with headers and a response headers fit one IP packet. If they don’t, someone uses way too big headers (or too many).

Given most sites still support HTTP/1.0, it's very unlikely we'll see anyone drop http/1.1 for another three decades, at least. Especially when you factor in how slow some large chunks of the world are to upgrade their OSes and software suites.

> Given most sites still support HTTP/1.0

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...

My go-to HTTP-only endpoint is http://example.com. It should be usable for as long as IANA and the Internet as we know it exists.

This was mine, too, until I started regularly using a (university) network where the local resolver resolved example.com to 127.0.0.1. I complained, and was told that RFC2606 gave them license to override it to anything they wanted, and that this behavior would not be changed. Doesn't square with my reading of the RFC, but complaining further wasn't going to achieve anything.

Now I use neverssl.com.

RFC 2606 is a "best current practices" document, which is less stringent than a standard. I'd say it gives them flexibility.

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. :)

Yikes. We use example.com all the time in my intro to network programming class. HTTPS would get in the way of learning the basics, so I'm glad there are some HTTP options out there still.

(Yeah, they could just run a local one-liner web server, but that's not as fun.)

I don’t miss the seemingly arbitrary restrictions from university IT admins.

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.

>Then I gave up.

I'm surprised you didn't set up your own system to work around the stupid restrictions.

My go-to used to be http://ihave50dollars.com. After it closed down, http://captive.apple.com became my new go-to.

I use neverssl.com

Another one is http://httpforever.com/.

I use http://paulgraham.com

Another plug for http://gfblip.appspot.com/

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.

example.com hasn’t been HTTP-only for quite some years now. It may still serve the page over HTTP rather than issuing a redirect to HTTPS, but that ain’t HTTP-only. Nor is there any guarantee of them retaining this deviation from accepted best practice.

That supports https too, so current/future browsers will auto-upgrade to https.

Oh cool. I worked on the networking layer of the first Kindle iOS (née iPhoneOS) app and that captive portal stuff was a pain in the ass. I would just walk across the street to Tully’s and use their wifi to get that pop up.

Interestingly enough this doesn't work for me on certain public wifi networks. I often have to go to a different HTTP-only URL, it's weird.

I've also had situations where _only_ neverssl.com wouldn't load but other http sites would switch to https with an invalid cert error. It's really weird.

That loads over HTTPS for me, due to Firefox redirecting automatically.

Weird, I can only access it on mobile data but not on my wifi.

this is my go to site for triggering wifi captive portals

Wonderful site http://n-gate.com

That one's my go-to as well. Hope the author's all right.

Glad to see another fan. For others, here's the relevant discussion http://n-gate.com/software/2017/07/12/0/ (needs some refreshes, I think the author made the website somewhat inaccessible on purpose)

HTTP encryption is a bit overrated. Governments only care about which sites you read and httpS don't help against that. TSL is also designed to be man-in-the-middle'd. Check your root certificates and ask yourself if you trust all those organizations. You will also likely find your ISP has a root certificate. The TLS handshake takes a lot of computer resources and makes your web experience slower. Encryption is good when you login to your bank over a random public wifi. It's unnecessary for public and open web sites that don't require username/password to login.

HTTPS by default came just in time for protecting us from ubiquitous injected ads from ISPs and wifi APs, we are lucky to not have experienced the worst of that.

HTTPS still provides some protection against MITM attacks.

Also restricts the ability of ISPs to inject ads into other people's sites.

HTTPS also protects us against attack tools like China’s Great Cannon.

https://citizenlab.ca/2015/04/chinas-great-cannon/

what's the status of DoH deployment and ESNI?

See neverssl.com.

It has been around for a long time and is useful for making sure you see Wifi terms pages.

NeverSSL is the way to go - they have a number of cache-busting tricks that I haven't seen on other sites.

Not anymore? (This discussion is pretty much a dupe.)

https://news.ycombinator.com/item?id=35789730

See the top reply to that comment:

> 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.

https://news.ycombinator.com/item?id=35792149

Except it actually makes the handling of that case worse, quite apart from making a lie of the name and content of the site.

captive.apple.com does the same trick with a smaller payload.

Where can I go that has a bigger payload? When I've successfully opened a site on an unfamiliar WiFi network I'd like to know up front if I'm gonna have trouble loading stuff.

captive.apple.com is just for captive portals - technically networks can (and do) spoof it, but it's just a connectivity check. Past that you can do any test you want over https.

I'd rather have both in one :)

neverssl strikes a pretty good balance

I'm still using HTTP and plan to continue for the next 25 years or so.[1]

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.

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

ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?

Only a few of the barriers presented by HTTPS:

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.

You are, of course, free to run your website however you chose. But if those are the first objections you have, I'd be happy to read and address your full list.

> 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.

Or I can use HTTP with any browser I feel like today, even Netscape

With how most of the internet already looks like without adblocker the difference would probably be impossible to even notice.

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.

I mean, it's not impossible for Matthew Prince, or his successor, or more likely his successor's successor, will just throw away the company by injecting unauthorized ads, but until they actually do, let's not pretend they have?

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.

> ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack

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.

>I run a trivial site via http and I don’t care about isps and coffee shops injecting ads

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.

It's not theoretical, but it's also not the end of the world, and I would accept it if it meant accessing information that is important to me over not being able to access it at all.

TBH, I'd probably make the same decision. But I don't know if I could ever really trust any information I got via such a connection though. Unless you had a secure connection to the site to use as a reference point, there's always the off chance you hit the right combination of "paypal" and "email address" or anything like an account number or some other thing that trips up the regexp/whatever to trick you into doing the wrong thing. You hope the alteration's as benign as injecting ads (hopefully they're not loud video ones), but that seems far from guaranteed since they're already modifying the page for their own financial gain.

They hate you because you spoke the truth.

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

> I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information.

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.)

> Passive surveillance resistance is also a big use case of TLS.

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.

Glorious nation of Kazakhstan agrees with you and up votes your comment.

Without https they could just mitm everyone without their knowledge.

https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

That article is horribly named, and defames the national government. There is no proof and not even an assertion that Kazakhstan even attempted MITM attacks. There's just controversy about the certificate. There's not even an example of it being installed on user devices! What a tempest in a teapot. Yes, it had significant and devastating ramifications, but none of those came about, and Wikipedia should not be pretending that this is a bigger deal than it turned out to be. "Attack", my foot.

Captive portals can and should have TLS enabled, even if they're internally served, there's nothing stopping you putting on a cert signed by a well known CA.

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.

I would love to know, how your captive portal is getting a valid certificate for https://google.com.

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.

My android phone seems to handle this well, not sure how it's detecting this and doing it, but seems like something that needs set on the OS side to detect when this occurs.

Seems a little dramatic...

HTTP isn't going anywhere. HTTPS is literally just HTTP with a TLS layer on top.

HTTP/3 does not include capability for non-encrypted connections.

Very true. Actually HTTP now also just refers to the semantics. HTTP/2 and HTTP/3 are still HTTP. They all support requests, responses, verbs, status codes, headers, caching semantics, etc.

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".

> But be careful, it could have had ads or malware injected and likely was spied on, by ISPs, governments, hotspots, and other malicious actors. And it also suffers a ranking punishment.

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?)

I use sites like this a fair bit while developing embedded network code.

Pretty ignorant.

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.

HTTPS is not just about tamper protection, but also about confidentiality. Do you want an attacker to be able to identify exactly which packages and which versions of packages you have installed?

(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.

You mean like - https://justi.cz/security/2019/01/22/apt-rce.html?

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.

HTTP belonged to a simpler time, the same way in some communities you don't lock the front door.

the same time I could run email servers on the internet and not have to worry about people breaking into it :/

Every "web" page is using HTTP. With or without TLS.

We apparently still need http to detect wifi portals.

There's been countless RFCs for a DHCP hook. ie https://www.rfc-editor.org/rfc/rfc8910

There are some small embedded devices that only speak HTTP. E.g. I have a power outlet with a web interface. You can power cycle outlets through that. It speaks only HTTPS. (The current revision of the product has a better embedded system in it with a better TCP/IP stack, and supports https.)

Hmm, this website supports https with an expired self-signed cert, but the https request never completes and repeats over and over again.

I always just open the router IP and the captive page shows up I never even thought of opening a http website

How do you know the router IP when you're on a phone? I know you can dive into network settings, but seems like a hassle.

I've been using Caddy for personal projects and I don't even think about HTTPS anymore. Except when I have to use another web server at work :-/

That is fine for simple projects where all you have to do is automate cert updates for the root domain or a few subdomains. The problem is not to automate this process. It's easy to write a shellscript that regularly updates certs for a root domain or some subdomains.

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.

Add to it that wildcard certificates are nice for not showing your sub-domains in certificate transparency logs.

> The problem is that letsencrypt does not offer url based authentification for wildcard certs.

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.

Which users have access to put files into .well-known/ of the root domain?

I am not aware of any service that allows that.

Can you give an example? What do you mean by "lots of people"?

I usually use example.com for this purpose.

my isp used to inject ads to http sites

People that write articles like that never had that jerk friend that would connect to their LAN and arp flood to take over an IP or setup a pineapple to capture wifi then run a proxy to turn all their images upside down.

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.

Not that I make a habit of correcting other's spelling and grammar, however:

ocassionally -> occasionally

Such mistakes annoy me also, and I apply a simple heuristic: If running a spell checker isn't worth your time, reading what you wrote isn't worth my time.

Glad I'm not the only one that noticed!

Fixed