0

I'm looking into HTTP version specific risks. HTTP 1.0 lacks support for persistent connections, meaning each request/response pair requires a new TCP connection to be established.

Considering the overhead associated with constantly opening and closing connections, it seems like HTTP 1.0 could be more susceptible to Denial-of-Service (DoS) attacks, especially when compared to later HTTP versions like 1.1 or 2, which support persistent connections.

Therefore I wonder the following:

  • Is HTTP 1.0 inherently more susceptible to denial-of-service (DoS) attacks due to its lack of support for persistent connections?
  • Are there any mitigations that can be applied specifically for HTTP 1.0 to lessen this risk?
  • Are there other security implications due to the lack of persistent connections in HTTP 1.0?
  • Are there other security risks that apply only to HTTP 1.0 that do not apply to other HTTP versions?
  • How about Head-of-Line Blocking? In HTTP/1.x, if one packet is lost, all responses behind it in a single TCP connection are delayed. Can't that be exploited for DoS attacks? As HTTP/2 and HTTP/3 addressed this issue making HTTP 1.x more susceptible to DoS?

Although not widely used anymore, the same would obviously apply on HTTP/0.9.

1 Answer 1

2

It is not true that HTTP 1.0 is inherently more susceptible to DoS due to the lack of persistent connection. First, HTTP 1.0 actually has support for persistent connection, only this needs to be specified explicitly ("Connection: keep-alive") while it is implicit with HTTP 1.1 and later. Additionally it is still possible for a client to create a new connection for each new request even in HTTP 1.1 or HTTP/2.

But, while creating a new TCP connection for each new request might drain some network related resources of the system, the possibility of having way more requests with many sequential (HTTP/1) or even multiplexed (HTTP/2) requests within the same TCP connection might even drain more resources from the system, i.e. database connection used in the request, computing etc.

So it is more a question of what resources are exhausted in the DoS attack - will it be network sockets or will it be application memory, database connections etc. Having non-persistent connections will exhaust the first one faster, persistent connections the second one.

In other words: it is not enough to ask which HTTP protocol is more susceptible to DoS. One must instead look at the design of the whole system to check where the relevant bottlenecks will be for various kinds of DoS attacks. And how a specific DoS can be mitigated depends on the kind of DoS and how exactly it affects the system and application, i.e. there is no generic solution covering all cases.

3
  • How about Head-of-Line Blocking? In HTTP/1.x, if one packet is lost, all responses behind it in a single TCP connection are delayed. Can't that be exploited for DoS attacks? As HTTP/2 and HTTP/3 addressed this issue making HTTP 1.x more susceptible to DoS?
    – Bob Ortiz
    Oct 30, 2023 at 16:13
  • I've added that to the original question and changed the title to reflect it.
    – Bob Ortiz
    Oct 30, 2023 at 16:43
  • @BobOrtiz: Head of line blocking has nothing to do with DoS. It is about performance. And getting more performance (i.e. more requests/s) by reducing head of line blocking can actually make request based DoS (instead of connection based) more easy. As I said, don't just look at the protocol but you need to look at the whole system. Oct 30, 2023 at 17:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .