0

I'm exploring the history and evolution of the HTTP protocol and I know that HTTP/0.9 is generally not used anymore. It's clear how features evolved in newer HTTP versions and how primitive HTTP/0.9 actually is with no support for headers, no status codes, only GET method, no HTTP version declaration et cetera.

While there isn't an official "end-of-life" declaration for HTTP versions I was wondering if there are version specific security vulnerabilities or risks associated with the use of HTTP/0.9, effectively making it "end-of-life" from a security standpoint.

Related is this article from 2018, interestingly the domain still supports HTTP/0.9 as of October 2023, tested using telnet: https://www.tobymackenzie.com/blog/2018/02/18/supporting-http-0-9/.

4 Answers 4

3
+50

A protocol does not have end of life. It's just a set of instructions, messages and things like that. When someone writes code that implements a protocol, that client have end of life.

For instance, AudioGalaxy was a popular file sharing from the early 2000's. Its protocol is available. Even if AudioGalaxy servers are not up anymore and its clients don't connect anymore, nothing stops anyone from implementing the protocol on a client and server, and restart the network.

Protocols can be superseded by new releases, but if some clients refuse to support the new version and keep using the older version, the protocol keep working.

I don't know of any graphical browser that can support HTTP 0.9 anymore, but as the protocol is very simple, it's possible to someone to write one if wanted.

3
  • Despite security that raises a whole new question: "Should a protocol have an end-of-life date?". I can't imagine it being very productive to indefinitely support protocols for compatibility reasons while ignoring inefficiencies.
    – Bob Ortiz
    Nov 1, 2023 at 12:25
  • 1
    FTP is a good example: it's a pain on firewalls, ACTIVE mode switches the client and server roles, the client-side firewall have to MitM the connection to know which port it should allow, server-side firewall have to do the same for PASSIVE mode, it can be used to portscan and even tunnel inside internal networks... and it's still supported.
    – ThoriumBR
    Nov 1, 2023 at 13:06
  • @ThoriumBR: You want a pain on firewalls, try SFTP in ACTIVE mode.
    – Joshua
    Nov 6, 2023 at 3:30
2

A Protocol is just a 'agreement' on how to communicate. as a result, it can't really have a "End Of Life" while there are still devices that use it (and there are).

Just like how other Protocols are still in existence, even when most people do not use them any more.

there is no longer a expectation that Browsers support anything below HTTP 1.1 though. Meaning it is effectively "obsolete" (even though most still work with the older standards).

Add to that that HTTP 1.0 consist of the complete support of 0.9 with some minor caveats that you aren't going to encounter. RFC#1945

Also, your reference material is not for a 2023 article, but for one from 2018. (not import, just pointing it out)

2
  • It is an article from 2018 but I tested HTTP/0.9 using telnet and as of 2023 it still works on that domain. I clarified it in the question.
    – Bob Ortiz
    Nov 1, 2023 at 12:26
  • 1
    it works on almost all Webservers... just try telnet google.com 80 with GET / and see the response get back. since it ONLY supports GET and lacks any headers... it can only do things you can do with a single unauthenticated GET request.... which isn't a lot anyway. and it was "not important" because its me nitpicking a detail not relevant for your question...
    – LvB
    Nov 1, 2023 at 13:18
1

The main weakness with HTTP/0.9 is the lack of information exchanged. Since there are no HTTP header fields, there is also no information about the intended Content-Type: the client must guess. Relying on guessing can have security implications when different parties (server, client, firewall) have different ideas on how the content should be interpreted.

Apart from that no header fields means no cookie based sessions, no header based authentication, no HTTP security headers like Content-Security-Policy ... . This surely has security implications too.

4
  • You can do basic auth without headers, but the entire server side application has to be in on it. Hilariously the no headers works both ways; if you don't have headers than you don't need Content-Security-Policy.
    – Joshua
    Oct 31, 2023 at 3:25
  • @Joshua: "You can do basic auth without header" - sure, you can encode username and password into the URL., you can encode session state into the URL, you can encode other information into the content etc. There is no standard way to do this though, i.e. it gets messy which is bad for security. "if you don't have headers than you don't need Content-Security-Policy" - I don't understand this argument. Content-Security-Policy is about the server defining what type of content is allowed and from where. How is this not relevant if you don't have headers? Maybe you mix this up with CORS? Oct 31, 2023 at 5:56
  • You're right, I mixed it up with CORS; however it turns out it also applies to Content-Security-Policy because you can declare it in a meta tag.
    – Joshua
    Oct 31, 2023 at 13:15
  • @Joshua: If your HTML is vulnerable to injections (a point which CSP tries to prevent) then it might not be advisable to rely on meta tags included in the HTML to protect the HTML. In other words - just because it can be done does mean it provides equivalent security. Oct 31, 2023 at 15:13
1

The real flaw in HTTP/0.9 is it conflicts with later version of the protocol. Separation between headers and body was added later, 0.9 is just a body. You can request a document with some HTTP headers inside the document and then things become more complex.

Let's say this document is a text file. If the first lines of the text file looks like a valid HTTP/1.0 or HTTP/1.1 response (so some headers and a body) then any reverse proxy receiving this response may interpret it as a valid HTTP/1.0 or HTTP/1.1 response while it made a HTTP/0.9 query -- and then extract a body from the response and interpreting the headers part as real headers. So anyone who can control the content of a file in the server can in fact control the headers part of the HTTP response (like creating cookies).

Now if everything works well in this proxy it knows it asked for a 0.9 version and wont interpret the headers. But :

  • everything is not always working well in a reverse proxy
  • the proxy may not known it made a 0.9 request (as it could be an hidden smuggled request for example)
  • every actor in the chain of proxys and servers may disagree on what is a 0.9 query and what is not. In the old past You had Nginx behave in 0.9 mode with request on HTTP/65538.9 for example, and a lot of server acted in 0.9 mode with requests on HTTP/0.9, which is also wrong.

You must log in to answer this question.

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