HTTP/1.1 is nice and simple compared to HTTP/2, which I think is severely overengineered.
This "desync" attack seems completely pointless, it's not going to bypass TLS, and if you're not using an encrypted transport layer, HTTP is the least of your concerns...
gruntz · 12h ago
Actually TLS does not protect you here. Problem is that reverse proxies do reuse backend connections and single backend connection may deliver requests from different users.
AndyKelley · 4h ago
Sounds like not HTTP 1.1's problem.
t1234s · 12h ago
HTTP/1.1 must live. A world where all devices no longer support HTTP/1.1 mean CAs become the gatekeepers of what servers are allowed to be recognized as "valid" online.
treve · 13h ago
I hope it never goes away. There's advantages to simpler text based protocols.
jsnell · 12h ago
This is the fifth time I've seen this site be linked this week, and I feel I must be missing something.
There's nothing there yet, folks. It's still just an announcement of an announcement! No longer does a vulnerability need just brand, a logo and a website. It also needs premarketing. I'm surprised there's not a "sign up for the waitlist" popup.
It's not even actionable as a warning. What are you going to do in preparation? Turn off HTTP/1.1 entirely? Of course not. Turn off your reverse proxy? Even if it were theoretically possible, what site could do anything at this timeframe. Switch vendors? Good luck figuring out which systems are vulnerable and which are not. Add a calendar entry to check for patches in two weeks? I guess, but given how viral this is with no details, odds are you won't be able to miss it when it actually goes public.
toast0 · 13h ago
Oh good, I liked HTTP/1.0 better. HTTP/0.9 is fun, but few things support it anymore. :P
andyjohnson0 · 13h ago
> HTTP/1.1 Must Die
On the internet, I'd kind of agree.
But static sites arguably often don't need https. And plain http is a low-friction way to glue things together where security isn't an issue, or where a web stack doesnt even exist. I feel like I understand 1.x, wheras I'll never be clever enough to understand 2.x.
The site seems to be a front for Portswigger, who I interviewed with a while back. I'm still not sure what to make of them or the interview experience.
voidnap · 13h ago
I scrolled down the page to figure out why all the hate, and the first link is to a page on Request Smuggling.
Maybe I'm out of the loop but isn't request smuggling a vulnerability in HTTP proxies that try to convert HTTP2 to HTTP1? Why not showcase vulnerabilities in the HTTP1 spec that are solved in HTTP2?
A doomsday clock for a vulnerability in a bad http proxy, doing something that should probably never be attemped anyway, is a bit dramatic.
No comments yet
every · 12h ago
Lynx[1] supports only HTTP/1.0 and HTTP/1.1. Most denials seem to come from nginx sites. I assume it is their default...
- browsers need to start supporting a better language (it could be typescript without backwards compatibility for things like var and function scoping)
- browsers need to eventually provide a way to polyfill JavaScript
- then JS can be removed without breaking content
But for this to even be of any utility, there would need to be a WebUI framework developers are willing to use bundled with a browser (and properly versioned).
supportengineer · 11h ago
I wonder if "browser" is even the right paradigm anymore.
HTML, hypertext, in the 1990's, it was so elegant as long as you were doing only a GET.
As soon as you get into dynamic content, the whole thing gets ugly fast.
Not to mention users who now expect a "rich web experience"
There's got to be a way to bring elegance back.
yoz-y · 8h ago
I see the browser as the universal runtime. Which happens to also have okay hardware support (video, audio, etc).
supportengineer · 7h ago
Let's go all the way and have it run bytecode, and allow for arbitrary protocols. No longer bound to HTTP.
This was the original premise of Java Applets.
delduca · 13h ago
IIRC HTTP/1.1 can have more connections to the server than the HTTP 2/3... Which is great for CDNs.
This "desync" attack seems completely pointless, it's not going to bypass TLS, and if you're not using an encrypted transport layer, HTTP is the least of your concerns...
There's nothing there yet, folks. It's still just an announcement of an announcement! No longer does a vulnerability need just brand, a logo and a website. It also needs premarketing. I'm surprised there's not a "sign up for the waitlist" popup.
It's not even actionable as a warning. What are you going to do in preparation? Turn off HTTP/1.1 entirely? Of course not. Turn off your reverse proxy? Even if it were theoretically possible, what site could do anything at this timeframe. Switch vendors? Good luck figuring out which systems are vulnerable and which are not. Add a calendar entry to check for patches in two weeks? I guess, but given how viral this is with no details, odds are you won't be able to miss it when it actually goes public.
On the internet, I'd kind of agree.
But static sites arguably often don't need https. And plain http is a low-friction way to glue things together where security isn't an issue, or where a web stack doesnt even exist. I feel like I understand 1.x, wheras I'll never be clever enough to understand 2.x.
The site seems to be a front for Portswigger, who I interviewed with a while back. I'm still not sure what to make of them or the interview experience.
Maybe I'm out of the loop but isn't request smuggling a vulnerability in HTTP proxies that try to convert HTTP2 to HTTP1? Why not showcase vulnerabilities in the HTTP1 spec that are solved in HTTP2?
A doomsday clock for a vulnerability in a bad http proxy, doing something that should probably never be attemped anyway, is a bit dramatic.
No comments yet
[1] https://en.wikipedia.org/wiki/Lynx_(web_browser)
- browsers need to start supporting a better language (it could be typescript without backwards compatibility for things like var and function scoping) - browsers need to eventually provide a way to polyfill JavaScript - then JS can be removed without breaking content
But for this to even be of any utility, there would need to be a WebUI framework developers are willing to use bundled with a browser (and properly versioned).
HTML, hypertext, in the 1990's, it was so elegant as long as you were doing only a GET.
As soon as you get into dynamic content, the whole thing gets ugly fast.
Not to mention users who now expect a "rich web experience"
There's got to be a way to bring elegance back.
This was the original premise of Java Applets.