Intent to Deprecate and Remove: HTTP/0.9 Support

[Matt Menke]

Primary eng email

mme...@chromium.org

Summary

HTTP/0.9 is the predecessor to HTTP/1.x. The big difference between HTTP/0.9 and HTTP/1.x is that HTTP/0.9 lacks any response headers. So when we send an HTTP/1.x request, if the server responds with a message that doesn't look like HTTP/1.x, we just assume it's an HTTP/0.9 response and treat the entire response is the response body, with no headers.

I want to remove HTTP/0.9 support entirely in M54, so if we can't parse the response response as an HTTP/1.x response, we fail the request with a network error (ERR_INVALID_RESPONSE or somesuch).

Motivation

There's no way to verify the response is actually HTTP/0.9. Anything we receive is treated as a valid HTTP/0.9 response if it's not HTTP/1.x. As a result, if we're talking to a server that implements a protocol that starts by having the server, rather than the client, send the initial data / handshake / whatever, or sends an error response when they see an HTTP request, we treat that as a valid HTTP/0.9 response. Even worse, if those servers don't close the socket as well, we'll treat the response as a hanging GET, and potentially keep the socket alive eternally (Or, if the request was triggered by a webpage, at least until the user navigates away from the webpage).

If a broken server sends extra data at the end of an HTTP/1.x response, we'll potentially treat that extra data as an HTTP/0.9 response to the next request, if we manage to reuse the socket before we receive that extra junk data. If the request was for the contents of a frame, we'll generally either just display the resulting garbage to the user, or save it to a file, depending on the result of the mime sniffer, which we'll always have to use, since without headers, the server can't send us a mime type.

There are similar cases where we're talking to broken SSL server or using a broken proxy.

HTTP/0.9 servers are also unable to indicate a request failed to the browser, which can cause problems with caching heuristics.

Some of this weirdness has lead a security issue that's fundamental to the design of HTTP/0.9: https://crbug.com/600352, which affects all major browsers. I apologize that it's currently access restricted. We'll open it up once the reporter publicly discloses the problem. The only foolproof way to fix the issue is to remove HTTP/0.9 support all together.

Alternative implementation suggestion for web developers

Switch to using HTTP/1.0, HTTP/1.1, or, even better, HTTP/2.  Switching to HTTP/1.x should be a very simple change.

RFC 1945, the original spec for HTTP/1.0 came out in 1996, about two decades ago, and fixed many of the shortcomings of HTTP/0.9. I don't think it's unreasonable to people to update their servers to support it.

Compatibility Risk

Servers that require HTTP/0.9 support will stop working. The main potential problem here is with embedded systems that, through bugs or deliberate design, require HTTP/0.9 support. We're not aware of any such devices, but that's not to say they're not out there.

Current Browser Support:

Edge: Supports HTTP/0.9. No signals on removing it yet. It's my understanding that Edge supports HTTP/0.9 only because Chrome does. Hopefully they'll follow suit in removing it.

FireFox: Supports HTTP/0.9. They're aware of the issue, but to the extent of my knowledge, haven't yet taken action. Unclear what action they'll take, when they do.

Safari: Supports HTTP/0.9. As a result of the issue, they've restricted HTTP/0.9 to certain ports. This mitigates the problem, but does not solve it.

Usage information

According to our numbers, about 0.01% of HTTP responses are HTTP/0.9 (that count excludes HTTP/2 and QUIC requests).  Each week, about 1% of Chrome users see a response that's interpreted as HTTP/0.9.  Note that these numbers likely overstate the prevalence of HTTP/0.9.  If we get anything from a server in response to an HTTP/1.x request, and it's not HTTP/1.x, then we assume it's HTTP/0.9.  It could well be we're talking to a broken server, or a non-HTTP server.

Public Tracking Bug

https://crbug.com/624462

Entry on the feature dashboard

N/A

Requesting approval to remove too?

Yes

[Darin Fisher]

Of the possible HTTP/0.9 responses, how many occur in the main frame? In other words how many more error pages would this change introduce?

Thanks,
-Darin

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvq_4vKV3mYpRP447aosHB97jOXQhSJ_QOa-mzmQDeAyvQ%40mail.gmail.com.

[PhistucK]

I vaguely remember that HTTP/0.9 is used a lot in the context of proxies (which a lot of the time means enterprise controlled devices, that are not enabling usage statistics) - is this still the case?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAP0-QptWup0%2BeYppqj-4vaYV4QZ7XfjkqirewqK3yc77jkwcXA%40mail.gmail.com.

[Harald Alvestrand]

Hooray for the idea that we might at last remove support for this misbegotten pitiful excuse for a protocol! I sometimes think of http/0.9 as a great example of how NOT to do protocol design - and the fact it got the Web started just shows how important other factors are....

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

Since you're targeting M54, can we collect data on M53 on how many additional error pages we'd show, and maybe even split those up by standard vs non-standard ports?

With that, LGTM1 to remove in M54, assuming that the data we get from M53 beta isn't a strong signal to go for a different solution.

[Philip Jägenstedt]

0.01% is a very high worst case number, if even a tiny fraction of that amounts to a total failure to load the page it might affect huge numbers of users.

Adding more histograms for M53 won't allow us to see stable channel data before the M54 branch, would it be acceptable to delay until M55? And will there be a deprecation message in the console? I ask because this isn't using UseCounter, so the template messages in Deprecation.cpp can't be used.

[Matt Menke]

I'm happy to add the requested histogram to M53.

In terms of code complexity, removing HTTP/0.9 support and bringing it back is a matter of a dozen or so lines of code in a file that changes fairly slowly.  If the M53 numbers prove problematic, we can very easily revert the change on the M54 branch.  I can even keep most of that code around, and just return an error code before we start treating a response as HTTP/0.9, to make the revert even simpler, if it's needed.

My main motivation for rushing it out is just the security issue, which the reporter plans to publicly announce at the end of August.  It is rated low severity by the security team, but I prefer to minimize its potential impact.

I was not planning on adding a deprecation message.  I'm not even sure if the renderer process currently knows whether a response was received over HTTP/0.9, and am reluctant to invest time learning blink's architecture well enough to add such a message.

Phistuck:  I had not heard that.  I think it's fairly unlikely enterprise proxies do this, for a couple reasons:  It puts more load on the proxy server since it breaks socket reuse, makes every resource that previously had an explicit mime type before dependent on mime sniffing heuristics, and breaks headers that set cookies.  If you wrapped the web in a proxy that converts everythign to HTTP/0.9, you'd break a huge number of websites.

[Philip Jägenstedt]

This is a tricky tradeoff, between unknown compat risk and a low severity security issue, but LGTM2. Removal in M54 would still leave time for a revert based on M53 stable data, so can check back with this thread once you have some more data on the compat risk?

[Matt Menke]

SGTM.  I'll add the histograms to M53, remove from M54 promptly with a new error code (Faster removal and a distinct error code means we'll be more likely to hear if there are widespread problems before branch is cut), and share the M53 stable numbers here once we have them.  I'll also keep an eye out for related bug reports on the tracker.

[PhistucK]

It would be great if you could add it to ChromeStatus. This makes sure (or makes it more likely that) the change is announced.

☆PhistucK

[Matt Menke]

Done (I marked it as removed in M54 - not sure if there's some better way to represent the current situation)

[PhistucK]

I think deprecated in Chrome 53 works and when you decide to remove (before Chrome 54 beta is out, or at least its blog post), change it to removed in Chrome 54.

☆PhistucK

[Chris Palmer]

LGTM, FWIW. Thank you, from security team. :)

But, I also think FTP can go. A seemingly-relevant selection of UMA histograms show that it is all-but-unused:

Media.URLScheme

Navigation.MainFrameScheme

Navigation.MainFrameSchemeDifferentPage

Net.FtpDataConnectionErrorCount

Net.FtpDataConnectionErrorHappened

Net.HadFtpServerType2

PasswordManager.TotalAccountsHiRes.WithScheme.Ftp 

(UMA stats are Google-internal; sorry. But the numbers are very low — many, many orders of magnitude below even file: URLs.)

[Rick Byers]

LGTM3

[Rick Byers]

Should we have a backup plan ready to mitigate the security issue in case we find the breakage/complaints are too great late in M54 beta?

[Chris Bentzel]

There are some separate bugs about removing FTP and it's been on the table before - but let's move to a different discussion than this one.

--

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/01353c16-7d52-4133-9130-884447ca48f8%40chromium.org.

[Matt Menke]

If need be, we can do what Safari did - restrict HTTP/0.9 to port 80 for HTTP and 443 for HTTPS, which mitigates the problem but does not fix it.  If we have to go that route, I do think we should still push for complete removal of HTTP/0.9 in a few revisions.

--

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFUtAY9091CWf92ECJrwzijd3RMkVCR%2BRK6y4QFHs6hDwS0T_g%40mail.gmail.com.

[Rick Byers]

On Thu, Jun 30, 2016 at 2:39 PM, Matt Menke <mme...@chromium.org> wrote:

If need be, we can do what Safari did - restrict HTTP/0.9 to port 80 for HTTP and 443 for HTTPS, which mitigates the problem but does not fix it.  If we have to go that route, I do think we should still push for complete removal of HTTP/0.9 in a few revisions.

As long as that's a trivial change we think is low enough risk to make late in beta (or even on stable in the worst case) then that sounds good to me.  Thanks!

[Jim Roskind]

Rather than consider the percentage of pages, it would be good to see what the percentage impacted users would be. You should be able to harvest that from the histograms as well.

Jim

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAP0-QptWup0%2BeYppqj-4vaYV4QZ7XfjkqirewqK3yc77jkwcXA%40mail.gmail.com.

[Matt Menke]

We've hit a bit of a snag.  The Tenda D301 home router uses HTTP/0.9.  While I believe the model is no longer being made, it isn't ancient, or at least it supports 802.11N.  Unclear if other Tenda products also use HTTP/0.9, or if there are other Broadcom-based home routers that do.  See https://crbug.com/637017.  As much as I want to get rid of HTTP/0.9, I think this may well mean we're stuck supporting it in perpetuity, given how rarely routers get firmware updates.  That is, unless we're willing to break their configuration UI, which I don't think we are.

The numbers otherwise look good, on dev only.  0.003% of pages that would otherwise display something show the new HTTP/0.9 error page.  Each day, 0.04% of users see those errors (Not actually sure how to interpret that one).

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvq_4vKV3mYpRP447aosHB97jOXQhSJ_QOa-mzmQDeAyvQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

[Philip Jägenstedt]

Maybe crazypants, but would it help at all to mitigate the security issue to limit HTTP/0.9 support to intranet or perhaps even to the gateway IP?

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvq_4vKV3mYpRP447aosHB97jOXQhSJ_QOa-mzmQDeAyvQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

[Brian Smith]

Philip Jägenstedt <foo...@chromium.org> wrote:
> Maybe crazypants, but would it help at all to mitigate the security issue to
> limit HTTP/0.9 support to intranet or perhaps even to the gateway IP?

I think this, or something like it, would be great. It would be really
sad to get this close to dropping HTTP/0.9 only for things like this
to stop it.

Perhaps only supporting HTTP/0.9 over http:// but not https:// is also
warranted. Then HTTPS (preloaded HSTS) sites can avoid being affected
by HTTP/0.9 in a clear way they can control.

Cheers,
Brian

[Matt Menke]

The security issue is actually exactly due to HTTP/0.9 connections to intranet IPs (Though intranet IPs with DNS addresses, which some home routers use), so I don't think that helps at all.  The security issue is only an issue with HTTP, not HTTPS, so restricting it to HTTPS also doesn't help.  Remember that the issue is remote sites (Which may use HTTP/1.x) accessing local non-HTTP systems, which send private data in response to any connection being established.

The gateway IP probably would fix this particular situation, at least (Though then we'd also need to get the gateway IP).

Safari, at least, is just restricting HTTP/0.9 to default ports.  We could also try that approach.  Could also try just allowing it for HTTP connections over port 90 (That is, also not allowing it over SSL).

[Brian Smith]

Matt Menke <mme...@google.com> wrote:
> The security issue is actually exactly due to HTTP/0.9 connections to
> intranet IPs (Though intranet IPs with DNS addresses, which some home
> routers use), so I don't think that helps at all. The security issue is
> only an issue with HTTP, not HTTPS, so restricting it to HTTPS also doesn't
> help. Remember that the issue is remote sites (Which may use HTTP/1.x)
> accessing local non-HTTP systems, which send private data in response
> to any connection being established.

I think you are referring to security issues that you know about. What
about security issues that you don't know about? In other words, there
seems to be evidence that HTTP/0.9 support is of ~zero benefit to
remote websites. But, it is far from clear that it is ~zero risk.
That's why I think reducing the scope of HTTP/0.9 support to some very
tight subset of local addresses seems a good idea, especially when the
end goal is to eventually remove support completely.

Cheers,
Brian
--
https://briansmith.org/

[Matt Menke]

If we have to leave in support for any subset of routers, I don't think the end goal is to eventually remove support completely (Or, perhaps a bit more clearly, I don't think if any broken router model is going to prevent us from removing support, that we can ever remove support.  The Tenda D301 isn't going away, nor will it be updated.  If we keep support for HTTP/0.9 for local server, there's nothing preventing another router from having the same bug in 10 years, 20 years, 30 years, etc.  So we'll basically eternally be stuck in the same state, unless we're at some point willing to break the Tenda D301's of the world.

[Brian Smith]

Matt Menke <mme...@google.com> wrote:
> If we have to leave in support for any subset of routers, I don't think the
> end goal is to eventually remove support completely (Or, perhaps a bit
> more clearly, I don't think if any broken router model is going to prevent us
> from removing support, that we can ever remove support.

But, even in that worse case, you could minimize the risk of the
misfeature in various ways, potentially.

> The Tenda D301
> isn't going away, nor will it be updated. If we keep support for HTTP/0.9
> for local server, there's nothing preventing another router from having the
> same bug in 10 years, 20 years, 30 years, etc. So we'll basically eternally
> be stuck in the same state, unless we're at some point willing to break the
> Tenda D301's of the world.

As long as you support HTTP/0.9 for remote websites, you run the risk
that some future attempt to remove HTTP/0.9 will get blocked on some
remote website adding a dependency on HTTP/0.9. Whereas, you don't
have to worry about future compatibility concerns for remote websites
so much if you remote support for HTTP/0.9 from remote websites now.

Anyway, I didn't mean to start a big debate. I just wanted to voice my
support as a typical Chrome users for removing the HTTP/0.9
support--ideally completely, or if not completely, then as much as
possible.

[Matt Menke]

That's a fair point.  While I'm not sure there's any significant security risk to HTTP/0.9 running on remote sites, we could potentially disallow it on them, just to work towards reducing use of the (horrible) protocol.  Using it over HTTPS is particularly bizarre, as well.

I don't want to sound like I'm just dismissing you're idea - just playing devil's advocate here.  I'd love it if we could find some sort of consensus about a path that would allow us to eventually completely remove HTTP/0.9 support at some point, I'm just not sure there is one, unless we're willing to effectively "brick" hardware, at some point.  Even if we reached out to Tenda, and they fixed their firmware, very few people update firmware, so there's still be an issue here.

[Tom Bergan]

FWIW, breaking router config pages is not entirely unprecedented. Chrome 39 dropped support for SSLv3, which broke config pages on most Tomato and DD-WRT routers that had "https only" checked (and possibly other routers, I'm not sure).

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvrmRHi6KvdPjF3JVPNmypLFqzCDTLBeEiQhhJm%2Bhaensw%40mail.gmail.com.

[PhistucK]

What about allowing it strictly for typed (well, bookmarked, too) or same-origin navigations?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvrmRHi6KvdPjF3JVPNmypLFqzCDTLBeEiQhhJm%2Bhaensw%40mail.gmail.com.

[Matt Menke]

The problem with same-origin navigations is that's where the security issue lies (Basically you change the IP the DNS address maps to after the attacking page has been loaded.  And there are non-HTTP servers that rely on being on intranets for security, and send private data whenever you connect to them, even if you send an HTTP request, which they don't actually support).

Typed URLs may or may not do the trick - some "fancy" routers will redirect http://192.168.0.1/, to http://really.cool.routers.use.dns.injection.com/, or whatever.  They have to use HTTP/1.x to do the redirect, but it's possible that they serve up an http/0.9 response to the final request.  Or no such routers may exist.  The network stack shouldn't have a concept of a typed URL, though, so we'd probably have to pass a magic "Allow HTTP/0.9" flag down, which is doable, if not exactly elegant.  We'd also need to use it for all subresources, I assume.  And since this is HTTP we're talking about, this is subject to HTTP interception, which gets us back to the original problem.

The "gateway only" approach may be our safest bet, unless we run into some other broken use case we feel obligated not to break.

[Harald Alvestrand]

+1 to eventually breaking the Tendas of the world. Until they feel the pain, we won't get the gain.

Can we be seriously annoying to them by showing an interstitial like we do for self-signed certs, such as "This page is using an outdated Web protocol that is known to make users more vulnerable to attacks, proceed at their own risk"?

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yuhong Bao]

I have been thinking of yellow single-click warning interstitials for things like OCSP server not available for a while now.

---

From: 'Harald Alvestrand' via net-dev <net...@chromium.org>
Sent: Friday, August 12, 2016 11:07:59 PM
To: Matt Menke
Cc: PhistucK; Brian Smith; Philip Jägenstedt; Jim Roskind; Darin Fisher; blink-dev; net-dev
Subject: Re: [blink-dev] Re: Intent to Deprecate and Remove: HTTP/0.9 Support

 

You received this message because you are subscribed to a topic in the Google Groups "net-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/net-dev/NA3c8OZi4pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOqqYVFNe0g4E3tqvHrwBcaE7iHrABDrD6NV0NNuQvyR1MsBMw%40mail.gmail.com.

[Matt Menke]

Since we're nearing branch, I'm going to go ahead and just disable HTTP/0.9 over non-default ports for the time being.  We can still narrow where we allow it in future releases.  May add an administrative policy to re-enable it, to be phased out in a couple releases.

To unsubscribe from this group and all its topics, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOqqYVFNe0g4E3tqvHrwBcaE7iHrABDrD6NV0NNuQvyR1MsBMw%40mail.gmail.com.

[starbeamr...@gmail.com]

So that you are aware, my networking course at university taught us how to implement HTTP/0.9 before they taught it HTTP/1.0 and 1.1, because it was simpler to understand - at the time I seem to remember it took me several hours to work out what was wrong with my HTTP/1.0 (and even more so 1.1) implementation. While HTTP/0.9 is certainly an old protocol and should probably be disabled by default, I think that it should at least be hidden behind a flag.

[Chris Bentzel]

Flags make things more complicated over time, and infrequently exercised code paths by the few can lead to security issues for the many. I'd be extremely hesitant to keep it in for educational purposed of writing a server - someone can just use nc if they are really interested in trying it out. 

--

You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/c1e13494-d3af-4a6d-af8d-1476771eb97a%40chromium.org.

[Rick Byers]

Note that this removal had unexpected consequences for quite a lot of Shoutcast users.  That is now being addressed via this separate intent.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.