One Third of the Web Will Stop Working in 4 Days
lowendbox.com
lowendbox.com
From the comment section. In other words, click-bait title.
But still you need to transfer the client and check it's hash for it to work and that's hard to implement in practice.
But you could bootstrap the thing over HTTPS (the download of the client) and then not need it ever again which is neat. Specially if you use TCP/HTTP now.
Following through the links referenced in the article, this appears to be the actual underlying research: https://portswigger.net/research/http-desync-attacks-request...
Cloudflare most recently blocked a vulnerability affecting some php websites where a zip file upload contains a reverse shell. This seems plain in comparison (probably because it is).
This sensationalist headline, that doomsday style clock (as another poster shared) makes me question the motives of these researchers. Have they shorted any CDN stocks?
I think the article uses this as an example of the concept of Request Smuggling in general. This broad approach has been known for a long time. I assume the new research uses conceptually similar but concretely different approaches to trigger parser desyncs.
From my reading this is a problem if:
1. Your CDN/Load balancer allows for HTTP/1.1 connections
2. You do some filtering/firewalling/auth/etc at your CDN/Load balancer for specific endpoints
I'm sure it's more than that, and I'm just missing it.
If you do all your filtering/auth/etc on your backend servers this doesn't matter right? Obviously people DO filtering/auth/etc at the edge so they would be affected but 1/3rd seems high. Maybe 1/3rd of traffic is HTTP/1.1 but they would also have to be doing filtering/auth at the edge to be hit by this right?
Again, for the 3rd time, I'm probably missing something, just trying to better understand the issue.
Some load balancers fronting multiple application connection through multiplexed requests on a single HTTP 1.1 connection, and bugs occur with the handling (generally handling request boundaries).
For example you can have a HTTP 1.1 front connection that behind the scenes operates a separate HTTP 1.0, 1.1, 2 or 3 connection.
When smuggling additional data through the request you trip up the handler at the load balancer handler to inject a response that shouldn't be there, which will be served for one of the clients (even the wrong client request).
Similar to HTTP response splitting attacks of the past.
Eg. 3 requests come into the load balancer, and request 2 smuggles in an extra response that could be served as a response to request 1 or 3.
That's how I understood the last such attack.
See https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 for a relevant demo.
You can also (in principle) steal responses intended for other clients, and control responses that get delivered to other clients.
So, I can't tell if it's real(ish) or advertising.
Perhaps the word "upstream" is significant
Not all proxies, i.e., authors of proxies, are created equal
Some might be incorrect
This may be the fault of the proxy authors, not the fault of the protocol designer^1
This blog post makes a claim that HTTP/1.1 only "power[s] a third of the web"
I have rarely found a website that will not accept HTTP/1.1
https://http1mustdie.com accepts HTTP/1.0 and 1.1
I have used HTTP/1.1 pipelining outside the browser for 17 years^2
It works beautifully for me outside the browser
Today I use 1.1 pipelining literally every day. Almost all websites I encounter still support and enable it
Would love to see some examples of sites that do not accept HTTP/1.1 amd only accept HTTP/[23]
1. Unlike the designers of HTTP/1.1, the designers of HTTP/2 have made mistakes, bad enough to warrant an immediate replacement
"This head-of-line blocking in HTTP/2 is now widely regarded as a design flaw, and much of the effort behind QUIC and HTTP/3 has been devoted to reduce head-of-line blocking issues.^[58]^[59]"
58. ^ Huston, Geoff (March 4, 2019). "A Quick Look at QUIC". www.circleid.com. Retrieved August 2, 2019.
59. ^ Gal, Shauli (June 22, 2017). "The Full Picture on HTTP/2 and HOL Blocking". Medium. Retrieved August 3, 2019.
This is interesting to me since this is allegedly the "problem" with HTTP/1.1 (cf. problem with advertising-sponsored web browsers) that HTTP/2 was supposed to "solve"^3
2. To retrieve multiple resources from same host in a single TCP connections. (Unlike browsers that routinely open up dozens of TCP connections to multiple hosts, usually for telemetry/advertising/tracking purposes.) It is desirable for me to receive the responses in the same order the requests were sent. As such, "HOL" is a on-issue for me.
3. See "Introduction" https://www.ietf.org/rfc/rfc7540.txt
HTTP/3 reminds me of CurveCP that was published years before QUIC^4
Except the HTTP/3 RFC is written by Akamai employee whereas CurveCP is from an academic, like HTTP/1.1
Also CurveCP needs no "SNI" that leaks domain names in plaintext like TLS and hence needs no complicated Band-Aid like ECH. Still waiting for ECH to be available outside of maybe a limited percentage of sites on a single CDN (Cloudflare)^5 It has been years