Live data from Hacker News

RIP HTTP

http.rip

111–120 of 131 posts

Re: RIP HTTP

#111
post #68

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?

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

Re: RIP HTTP

#112
post #83

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

> 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 diffi…

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

Re: RIP HTTP

#113
post #3

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 o…

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

Don't they already have hardcoded DoH?

Re: RIP HTTP

#114
post #105

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…

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.

Re: RIP HTTP

#115
post #68

Earlier quoted context omitted.

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?

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

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

Re: RIP HTTP

#116

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.

Re: RIP HTTP

#117
post #68

Earlier quoted context omitted.

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 ar…

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.

Re: RIP HTTP

#118

Earlier quoted context omitted.

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 o…

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

Re: RIP HTTP

#119
post #97

Earlier quoted context omitted.

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 o…

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.

Re: RIP HTTP

#120
post #117

Earlier quoted context omitted.

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 ar…

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 af…

Or I can use HTTP with any browser I feel like today, even Netscape
Post reply on HN