5 ms·

Entirely unsurprising. With all this complexity, HTTP2 is on par with a full TCP/IP stack. All major operating systems had decades to optimize and bulletproof t

Entirely unsurprising. With all this complexity, HTTP2 is on par with a full TCP/IP stack. All major operating systems had decades to optimize and bulletproof these, and still to this day we find issues with them every now and then. What did people expect would happen when we start reinventing the wheel yet again, on top of what we already have? And this is just the tip of the iceberg. Consider this a warm-up exercise.

JoshTriplett 7y ago
Also, issues like CVE-2019-9517 ("Internal Data Buffering") provide strong motivation for integrating those layers, as HTTP/3 is doing.
the_duke 7y ago
We can happily look forward to HTTP/3 then. It actually IS a full stack...
- persistent 7y ago
  Putting HTTP/3 on a userspace QUIC stack solves a number of these problems.
  - throwaway2048 7y ago
    HTTP/2 already is userspace.
- mey 7y ago
  I'm curious about how practical UDP amplification/reflection attacks will be in the wild with QUIC. A cloudflare blog mentions it in passing ( https://blog.cloudflare.com/head-start-with-quic/ https://blog.cloudflare.com/head-start-with-quic/ ). I haven't dug into the protocol, but since what replaces the TCP SYN/ACK is now also setting up encryption, a lot more data is flying back and forth.
SCHiM 7y ago
Indeed. Looking at the descriptions of the attacks all these are simple. They probably would have occurred to any halfway competent attacker looking at ways to DOS your sever in the first several hours of playing around with it. Consider that one of the attacks is described as a "ping flood", remember when we first dealt with that? Decades ago. And the "data dribble" looks like a re-heated version of the HTTP "Slowloris" attack. It's extremely regrettable that the creators of the vulnerable software didn't take a look at any of the plethora of existing attacks and imagine how they might be adapted to attack their implementations.
zxcmx 7y ago
The other way to look at it is that the only people who deeply need to care about things like this are cloud providers. Basically anyone who cares about DoS resistance is using a CDN and/or cloud load balancers, or has enough scale to build out their own CDN. Otherwise you'll get soaked at layer 3 anyway, L7 DoS resistance is "nice to have" but not enough.
- cmroanirgo 7y ago
  I am very interested in my little vps not being reduced to a smoking heap just because some script kiddie wanted some cheap lulz. Of course, it's not hard to dos a tiny vps, but I think it very important not to court unnecessary trouble.
drawkbox 7y ago
Version 2 syndrome on full display aka the "second-system effect" [1]. > The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems, to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence. They "simplified" it by making it more complex and layers of binary/connection complexity... failing to address many common attack vectors and adding fully new attack vectors that should have been expected. Now debugging those in HTTP/2 is harder and in a big binary blob. I miss text based/MIME HTTP 1.1, simplicity should be the goal always, not more complexity that solves almost nothing, but HTTP/2 did give some big orgs control of the layer/protocol/standard which was most of the driving force. Much of this could have been fixed lower level in SCTP or something similar on the transport layer, but instead we get another abstraction on top of it all, with more holes and tougher to debug. Solution: let's do it again in HTTP/3... new standard to fix all the old standards, more complexity that leads to misunderstanding in implementations that leads to more attack vectors. Obligatory xkcd [2] [1] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect [2] https://xkcd.com/927/ https://xkcd.com/927/
- lucaspardue 7y ago
  Versions prior to HTTP/2 give the appearance of being simple but in actuality there are many many edge cases that also are the cause of vulnerabilities. HTTP/2's binary syntax addresses some of those edge cases mainly through better-formed header fields and a common chunking of body data. SCTP is undeployable on the Internet. HTTP/2 is deployed on the Internet. It brings multiplexing and of course that brings some additional complexity and constraints. But these have proven more deployable than HTTP/1.x-style solutions such a pipe lining. HTTP/3 is actually a simpler application mapping than HTTP/2. This is due to the complexity getting pulled into the transport. But it's a zero sum game, just moving the concerns around doesn't mean they are automatically fixed.
  - drawkbox 7y ago
    HTTP/3 has a better goal in that it aims to push these elements back down to the transport layer using QUIC, in HTTP/2 transport abstractions bubbled up to the protocol layer making for a messy abstraction. HTTP/2 is a leaky abstraction and blends too much of the transport and protocol layers and unnecessarily complex. Though I will add that much of the protocol and standards work in recent years or even the last 5-10 has largely been companies aiming to take control of the standards by implementing standards that benefit them the most over maybe sensible simplifying, adding complexity to own it more. That definitely is a factor and HTTP/2 was rushed probably for this reason. SCTP would be doable as it is a transport layer and yes difficulty in rolling it out, but Google went after QUIC, which is also a transport layer and is similar to SCTP (UDP capabilities or essentially a transport version of RUDP mixed with ordering/verification), because they also call the shots on that. It makes sense for Google to push that but does it make sense for everyone to just allow that? People have to understand that standards are now pushed company level rather than from engineering solely. The needs of HTTP/2 went beyond a better system, it ventured into control the standards and market standards territory. Hopefully HTTP/3 is better and less complexity, but judging by who wants it in and how companies want to control these layers more, I have my doubts. We now have 3 HTTP protocol layers to support, more and more it will box out engineers from being able to compete or other browsers/web servers to compete. I don't know that the pros outweigh the cons in some of these scenarios. Who really gains/ed from HTTP/2 HTTP/3? UDP was always available as well as reliable UDP. HTTP/2 and HTTP/3 feel more like a standards grab with minimal benefits but major benefits to the pushers. I am not against progress in any way, I am against power grabs and iterations that provide little benefits from major overhauls and 'second-system syndrome' as well as complexity rather than simplicity to some of those ends. Did we really benefit from obfuscating protocol layers of HTTP (the HyperTEXT Transfer Protocol) into binary? What did we gain? We lost plenty, easier debugging, simplification, control of the standard, competition etc. Hopefully we gained from it but I am not seeing it. We already had encryption and compression to stop ad networks/data collection, binary gains are minimal for lots of complexity. Simplification was destroyed for what? Resource inlining breaks caching. Multiplexing is nice but it came at great cost and didn't really improve the end result. HTTP/2 reminds me of the over complexity in frameworks, SOAP vs REST, binary vs text, binary JSON and many other things that were edge cases that now everyone has to deal with. As engineers we must take complexity and simplify it, that is the job, I don't see lots of that in recent years with standards and development. Minimalism and simplicity should be the goal, complexity should be like authority, it should be questioned harshly and be allowed only when there is no other way. Making another version and more complexity is easy, making something simple is extremely difficult.
dfeojm-zlib 7y ago
Yeap. Emperor's new clothes / Not Invented Here / reinventing the wheel / new is "better" than old - churn / kitchen-sink design-by-committee (cough OpenSSL cough). This happens more and more. Instead of fixing existing infrastructure that has a well-established/proven history, throwing everything away and starting over like what came before never existed. And let's over-engineer it and add every possible feature that we'll never use! It's so new and broken, isn't it awesome!?!
- rumanator 7y ago
  > Instead of fixing existing infrastructure that has a well-established/proven history, throwing everything away and starting over like what came before never existed. Isn't HTTP/2 just that, an attempt to fix existing infrastructure? I mean, HTTP/2 was a revision of HTTP/1.* that aimed to fix some problems such as the inability to address latency issues with basic techniques such as pipelining and multiplexing requests.
manigandham 7y ago
Of course a new protocol might have new bugs, but what's your alternative? The web needed to evolve. HTTP2 offers a lot of new benefits. Maybe if the TCP standards could actually update in time frames other than decades then that's how it would've went. And if did get TCP2, you could say exactly the same thing about it being new and more open to bugs.

JoshTriplett 7y ago

Also, issues like CVE-2019-9517 ("Internal Data Buffering") provide strong motivation for integrating those layers, as HTTP/3 is doing.

the_duke 7y ago

We can happily look forward to HTTP/3 then. It actually IS a full stack...

persistent 7y ago
Putting HTTP/3 on a userspace QUIC stack solves a number of these problems.
- throwaway2048 7y ago
  HTTP/2 already is userspace.
mey 7y ago
I'm curious about how practical UDP amplification/reflection attacks will be in the wild with QUIC. A cloudflare blog mentions it in passing ( https://blog.cloudflare.com/head-start-with-quic/ https://blog.cloudflare.com/head-start-with-quic/ ). I haven't dug into the protocol, but since what replaces the TCP SYN/ACK is now also setting up encryption, a lot more data is flying back and forth.

SCHiM 7y ago

Indeed. Looking at the descriptions of the attacks all these are simple. They probably would have occurred to any halfway competent attacker looking at ways to DOS your sever in the first several hours of playing around with it. Consider that one of the attacks is described as a "ping flood", remember when we first dealt with that? Decades ago. And the "data dribble" looks like a re-heated version of the HTTP "Slowloris" attack. It's extremely regrettable that the creators of the vulnerable software didn't take a look at any of the plethora of existing attacks and imagine how they might be adapted to attack their implementations.

zxcmx 7y ago

The other way to look at it is that the only people who deeply need to care about things like this are cloud providers. Basically anyone who cares about DoS resistance is using a CDN and/or cloud load balancers, or has enough scale to build out their own CDN. Otherwise you'll get soaked at layer 3 anyway, L7 DoS resistance is "nice to have" but not enough.

cmroanirgo 7y ago
I am very interested in my little vps not being reduced to a smoking heap just because some script kiddie wanted some cheap lulz. Of course, it's not hard to dos a tiny vps, but I think it very important not to court unnecessary trouble.

drawkbox 7y ago

Version 2 syndrome on full display aka the "second-system effect" [1]. > The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems, to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence. They "simplified" it by making it more complex and layers of binary/connection complexity... failing to address many common attack vectors and adding fully new attack vectors that should have been expected. Now debugging those in HTTP/2 is harder and in a big binary blob. I miss text based/MIME HTTP 1.1, simplicity should be the goal always, not more complexity that solves almost nothing, but HTTP/2 did give some big orgs control of the layer/protocol/standard which was most of the driving force. Much of this could have been fixed lower level in SCTP or something similar on the transport layer, but instead we get another abstraction on top of it all, with more holes and tougher to debug. Solution: let's do it again in HTTP/3... new standard to fix all the old standards, more complexity that leads to misunderstanding in implementations that leads to more attack vectors. Obligatory xkcd [2] [1] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect [2] https://xkcd.com/927/ https://xkcd.com/927/

lucaspardue 7y ago
Versions prior to HTTP/2 give the appearance of being simple but in actuality there are many many edge cases that also are the cause of vulnerabilities. HTTP/2's binary syntax addresses some of those edge cases mainly through better-formed header fields and a common chunking of body data. SCTP is undeployable on the Internet. HTTP/2 is deployed on the Internet. It brings multiplexing and of course that brings some additional complexity and constraints. But these have proven more deployable than HTTP/1.x-style solutions such a pipe lining. HTTP/3 is actually a simpler application mapping than HTTP/2. This is due to the complexity getting pulled into the transport. But it's a zero sum game, just moving the concerns around doesn't mean they are automatically fixed.
- drawkbox 7y ago
  HTTP/3 has a better goal in that it aims to push these elements back down to the transport layer using QUIC, in HTTP/2 transport abstractions bubbled up to the protocol layer making for a messy abstraction. HTTP/2 is a leaky abstraction and blends too much of the transport and protocol layers and unnecessarily complex. Though I will add that much of the protocol and standards work in recent years or even the last 5-10 has largely been companies aiming to take control of the standards by implementing standards that benefit them the most over maybe sensible simplifying, adding complexity to own it more. That definitely is a factor and HTTP/2 was rushed probably for this reason. SCTP would be doable as it is a transport layer and yes difficulty in rolling it out, but Google went after QUIC, which is also a transport layer and is similar to SCTP (UDP capabilities or essentially a transport version of RUDP mixed with ordering/verification), because they also call the shots on that. It makes sense for Google to push that but does it make sense for everyone to just allow that? People have to understand that standards are now pushed company level rather than from engineering solely. The needs of HTTP/2 went beyond a better system, it ventured into control the standards and market standards territory. Hopefully HTTP/3 is better and less complexity, but judging by who wants it in and how companies want to control these layers more, I have my doubts. We now have 3 HTTP protocol layers to support, more and more it will box out engineers from being able to compete or other browsers/web servers to compete. I don't know that the pros outweigh the cons in some of these scenarios. Who really gains/ed from HTTP/2 HTTP/3? UDP was always available as well as reliable UDP. HTTP/2 and HTTP/3 feel more like a standards grab with minimal benefits but major benefits to the pushers. I am not against progress in any way, I am against power grabs and iterations that provide little benefits from major overhauls and 'second-system syndrome' as well as complexity rather than simplicity to some of those ends. Did we really benefit from obfuscating protocol layers of HTTP (the HyperTEXT Transfer Protocol) into binary? What did we gain? We lost plenty, easier debugging, simplification, control of the standard, competition etc. Hopefully we gained from it but I am not seeing it. We already had encryption and compression to stop ad networks/data collection, binary gains are minimal for lots of complexity. Simplification was destroyed for what? Resource inlining breaks caching. Multiplexing is nice but it came at great cost and didn't really improve the end result. HTTP/2 reminds me of the over complexity in frameworks, SOAP vs REST, binary vs text, binary JSON and many other things that were edge cases that now everyone has to deal with. As engineers we must take complexity and simplify it, that is the job, I don't see lots of that in recent years with standards and development. Minimalism and simplicity should be the goal, complexity should be like authority, it should be questioned harshly and be allowed only when there is no other way. Making another version and more complexity is easy, making something simple is extremely difficult.

dfeojm-zlib 7y ago

Yeap. Emperor's new clothes / Not Invented Here / reinventing the wheel / new is "better" than old - churn / kitchen-sink design-by-committee (cough OpenSSL cough). This happens more and more. Instead of fixing existing infrastructure that has a well-established/proven history, throwing everything away and starting over like what came before never existed. And let's over-engineer it and add every possible feature that we'll never use! It's so new and broken, isn't it awesome!?!

rumanator 7y ago
> Instead of fixing existing infrastructure that has a well-established/proven history, throwing everything away and starting over like what came before never existed. Isn't HTTP/2 just that, an attempt to fix existing infrastructure? I mean, HTTP/2 was a revision of HTTP/1.* that aimed to fix some problems such as the inability to address latency issues with basic techniques such as pipelining and multiplexing requests.

manigandham 7y ago

Of course a new protocol might have new bugs, but what's your alternative? The web needed to evolve. HTTP2 offers a lot of new benefits. Maybe if the TCP standards could actually update in time frames other than decades then that's how it would've went. And if did get TCP2, you could say exactly the same thing about it being new and more open to bugs.