11

As of 2023, still many webservers support HTTP/1.0 and HTTP/1.1 while not supporting recent HTTP/2 and/or HTTP/3 protocols. I understand that newer HTTP versions offer various performance enhancements, but I'm particularly interested in the security implications.

What security risks are involved in using older HTTP protocols such HTTP/1.0 or HTTP/1.1? If we ignore device compatibility for a moment and purely look at it from a security point of view, why should one upgrade from previous HTTP versions to HTTP/2 or HTTP/3?

3
  • 2
    I've removed your mentioning of HTTP/0.9 since you've already asked a question specifically about HTTP/0.9 which should cover this aspect. Oct 30, 2023 at 17:27
  • 7
    Job security of Google engineers. Oct 31, 2023 at 7:04
  • Not exactly what you asked, but you may find this interesting: portswigger.net/research/http2
    – paj28
    Nov 2, 2023 at 17:01

3 Answers 3

26

There is no significant security improvement between HTTP/1 and HTTP/2 and HTTP/3. But this wasn't a design goal. Instead the focus was on performance and any security improvement or degradation is more a side effect.

One might argue though that the change from the text based protocol of HTTP/1 with sometimes ambiguous interpretation (like different spellings of the same field name, multiple fields repeated with contradicting values) to a more binary protocol in HTTP/2 enables a more consistent interpretation between different implementations. This is a good thing for security since inconsistent interpretation enables attack like HTTP request and response splitting, which make HTTP cache pollution possible or allow bypass of security analysis. It isn't perfect though in HTTP/2, but better than in HTTP/1.

One might also argue that the additional complexity of implementing even the basic protocol scares away many wanne-be programmers from implementing the protocol. For HTTP/1 one unfortunately can find way too many broken implementation attempts on StackOverflow and even in production. With HTTP/2 instead more programmers use existing libraries instead of trying to implement their own based on the assumptions that this will reduce overhead and/or dependencies. Thus, there are fewer and better maintained HTTP/2 implementations compared to HTTP/1.

But on the other hand the additional complexity can also worsen security. This can be seen in the recent HTTP/2 rapid reset attack which makes use of additional features in HTTP/2 which were not available in HTTP/1.

One might also argue that the insistence on TLS (or similar) encryption for HTTP/2 and HTTP/3 is good for security (even though HTTP/2 could be used without encryption). But HTTP/1 with TLS does not provide less security here.

10
  • 4
    A possible risk: forcing TLS with HTTP 2 in cases where it doesn't work (e.g. home router config page) might train users to ignore security warnings. But those scenarios can use HTTP 1.1 anyway.
    – user253751
    Oct 31, 2023 at 21:02
  • @user253751: I'm not sure how you want to force this. The URL syntax differentiates only between http and https, not between HTTP/1, HTTP/2 and HTTP/3. These are enabled only by the server and only if the server (and client) supports it. And trying to use https against a plain http server will not result in a security warning, it will simply not work. Nov 1, 2023 at 6:05
  • @user253751 Browsers will soon outright not allow non-TLS connection so you don't really have to worry much about that anymore.
    – Nelson
    Nov 1, 2023 at 6:18
  • 2
    @Nelson They tried that. It didn't work.
    – user253751
    Nov 1, 2023 at 23:27
  • 2
    @Brad: "No browser supports HTTP/2 without TLS. " - I'm assuming that you refer to my statement "even though HTTP/2 could be used without encryption". That's based on the standard - not on the implementation in the browsers. The standard explicitly defines HTTP/2 also over plain TCP using the Upgrade header. This is supported for example by nginx (h2c) and curl. Browsers decided to not support it. Nov 2, 2023 at 6:03
7

When looking at the HTTP protocol, you can't ignore its 'sister' component TLS. (All is as of time of writing) TLS Version in current use are:

  • TLS 1.0 (Obsolete)
  • TLS 1.1 (Obsolete)
  • TLS 1.2 (Outdated)
  • TLS 1.3 (Recommended version)

TLS 1.2 already recommends the use of HTTP/1.1 for its SNI extension. (making virtual hosts possible on a single IP)

that means the following is the case for the HTTP protocol:

  • HTTP/0.x (Experimental, do not use)
  • HTTP/0.9 (retcon version of HTTP, superseded by HTTP/1.0)
  • HTTP/1.0 (First version to support headers, outdated and only still present for legacy use)
  • HTTP/1.1 (Current Recommended version)
  • HTTP/2.0 (a.k.a. SPDY, a standard single multiplex connection. adds great improvements if you fully implement its capabilities.)
  • HTTP/3.0 (a.k.a. QUIC, deviates from the other HTTP standards by using UDP instead of TCP, especially well suited for huge transfers, low-latency, and real-time uses.)

as you can see, for HTTP the newer versions are for 'special case' uses (mainly).

and if we look at the raw protocol, there is no real difference security-wise between HTTP/1.1 till HTTP3.0.

Protocol wise, HTTP/3.0 has some interesting implications due to its session-less medium, but the protocol solves this internally.

and since Lets Encrypt is a thing, all connections should be TLS encrypted anyway limiting the impact of the HTTP protocol on the attack surface.

As for the obsolete version of HTTP, those don't support the current in-use security mechanism fully, such as:

  • up to date TLS (1.2 or newer)
  • CORS (fully)
  • CSP (Content Security Policy)
  • STS (Strict Transport Security
  • etc. (see securityheaders.com or check the current MDN pages for more details.)
9
  • 1
    SNI applies to and can be used in all TLS versions, though chronologically many implementations didn't support it (or not correctly!) until about 2010, by which time 1.2 was adopted and recommended -- but not always used. SAN is another solution for vhosting (in all TLS versions) and was widely supported years earlier (on 1.0 and 1.1 and even SSL3). PS: the English word is spelled (spelt in some dialects) 'obsolete' Oct 31, 2023 at 2:12
  • 3
    Note: TLS-protocol-extension SNI (Server Name Indication) and virtualhosting on the HTTP-Host-header aren't alternatives; neither substitutes the other. Oct 31, 2023 at 9:39
  • 1
    ... and the Java 7 implementation of SNI was buggy to start; I recall several updates that changed SNI before it actually worked reliably. (And even today JSSE won't do SNI for a single-label hostname, which is arguably a violation.) Nov 1, 2023 at 0:28
  • 1
    @LvB: SNI was defined in RFC 3546 (not 3564) in 2003. Since TLS 1.1 was only released in 2006 (RFC 4346) and TLS 1.2 in 2008 (RFC 5246) SNI clearly already applies to TLS 1.0. It does not apply to SSLv3 though since this version did not have the concept of extensions which is used by SNI. Nov 1, 2023 at 13:37
  • 2
    For 1.0 and 1.1 extensions are defined entirely in separate documents: 3546 for 2246 and 4366 for 4346 for the 'initial' ones, 4492 for ECC, and others elsewhere. For 1.2 the extension format and sigalgs are in 5246 but other initial extensions including SNI in 6066; 4492 still applies, but later is modified by 7919 and 8422. Only for 1.3 are most extensions in the base document (8446). (@SteffenUllrich) Nov 2, 2023 at 0:34
4

What security risks are involved in using older HTTP protocols such HTTP/1.0 or HTTP/1.1?

HTTP request smuggling is a vulnerability where two servers are not in agreement where HTTP requests start and finish. Consider a situation where a proxy server forwards requests to an application server. By messing with the Content-Length and Transfer-Encoding headers, the proxy server can interpret the request differently from the backend server.

This is a solved issue when both the proxy server and application server speak HTTP/2 or 3, since these protocols have different mechanisms to wrap requests.

1
  • This was on my mind too. Isn't client-side desync (CSD) a form of HTTP request smuggling? In that case, isn't the risk specific to the pipelining function of HTTP/1.1 alone, which doesn't exist in HTTP/1.0? Which is replaced by multiplexing in newer HTTP versions. Meaning: A security-wise justification for upgrading to a newer version, as HTTP/1.1 in particular has associated smuggling/CSD risks?
    – Bob Ortiz
    Nov 1, 2023 at 14:20

You must log in to answer this question.

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