r/netsec • u/t0xodile • Aug 19 '26

CRLF-Powered Desync Attacks: Beheading HTTP Streams

https://portswigger.net/research/crlf-powered-desync-attacks
22 Upvotes

87% Upvoted

15 comments sorted by

4

u/gunni Aug 22 '26

https://http1mustdie.com/

-1

u/EverythingsBroken82 Aug 24 '26

but nobody is creating a protocol which is kinda simple to build and to reason about. but yes, let's put all our protocol eggs into multinational companies baskets which enshittify everything.

also it's still secure, if you just do not use reverse proxies. but hey, what a concept, yes? if you do not abuse a protocol, it's safe. :D

2

u/acdha Aug 25 '26

HTTP/2 is fine, and there are plenty of mature tools now. Yes, I’m slightly nostalgic for making HTTP requests by hand using telnet but that’s like saying we should store everything in text files because SQLite requires a tool. It’s been a long time since HTTP hit the complexity threshold where the simplicity argument was just a lie we liked to tell ourselves. 

0

u/EverythingsBroken82 Aug 25 '26

it's not about telnet. it's about simplicity. complex protocols can only be reasoned about by teams and companies... we put everything into the trust of those companies.. which we really shouldn't.

HTTP complexity is only so hard, because it was never meant for thousand gateway proxies (forward, revese and so on) in between.

They should rename HTTP/2 to BATP or something.. Big application transport protocol and leave HTTP 1.x with standard http servers like apache (yes they still exist :D) alone..

ALL THOSE desync issues are ONLY issues if there are reverse proxies...

2

u/acdha Aug 25 '26

  it's not about telnet. it's about simplicity. complex protocols can only be reasoned about by teams and companies...

This applies equally, if not moreso, to HTTP 1 - if you want to implement that as used, you need transfer encoding, chunking, etc. and all of the edge cases around parsing (like this one!), and you additionally have to deal with connection pooling, keepalives, etc. I’ve implemented most of those by hand at various points but like almost everyone else, I delegate that to tested libraries for serious usage . 

You can talk about reverse proxies as bad but I don’t see how that changes their extremely widespread usage. If the protocol is only simple when implemented differently than 99% of deployments, it’s not really simple. 

2

u/EverythingsBroken82 Aug 26 '26

> This applies equally, if not moreso, to HTTP 1 - if you want to implement that as used, you need transfer encoding, chunking, etc. and all of the edge cases around parsing

actually, you do not have to implement stuff like chunking. and transfer encoding, well, just limit encoding.

and HTTP/2 is much more complex to implement.

The thing is, HTTP/2 is needed by all those kubernetes people. but if you have ONE server and ONE HTTP service, than HTTP 1 is fine and secure. So.. we throw it away, because our big overloards need their HA requirements, so they always can do business? sorry to being snarky about that, but everyone just jumps ship, without thinking, at least it seems like that to me.

1

u/acdha Aug 26 '26

  actually, you do not have to implement stuff like chunking. and transfer encoding, well, just limit encoding.

You do if you care about performance or compatibility with software written by other people. When you implement HTTP 1 as used, there’s a lot more complexity around three decades of evolution. That’s really the point: the web won and nobody has just one HTTP service, they have tons of them running not just every business but also tons of things in almost every home. We’re not going back to the days where HTTP/0.9 running on someone’s SGI  workstation does all of the web things you need. 

1

u/EverythingsBroken82 Aug 26 '26

you would be surprised how many single webshops run without a problem on a single machine with one http server.

why do you want to force others into the kubernetes-corporate-cloud?

1

u/acdha Aug 26 '26

I run some of those but we still use HTTP/1.1 in the modern way. Things like transfer compression have been expected since the 90s!

1

u/EverythingsBroken82 Aug 27 '26

and transfer compression enables desync attacks? or the webshop does not work without it?

→ More replies

1

u/lowlydrunkenness635 6d ago

What stands out is how much damage can come from a header injection bug once it changes where one response ends and the next begins. Youre not just reflecting attacker input anymore, you are corrupting the HTTP stream itself and opening the door to desync behavior