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