Frank Behrens wrote:
Hi Matthias!
Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> wrote on 12 Nov 2008
14:36:
On Wed, 12 Nov 2008, Frank Behrens wrote:
James Yonan <j...@yonan.net> wrote on 4 Nov 2008 12:16:
Shouldn't you check p->options.http_version and make sure it's >= 1.1
before sending the Host header?
Here is a revised patch, that works for me and implements your
suggestion:
Sorry Frank,
I have to object. It does not implement James's suggestion as you claim,
Ok, this was a mistake. I implemented the solution I proposed on this list in my mail from 05
Nov 2008
(<4911d76d.7020...@harz.behrens.de>).
but random guesswork - inadequate for security software and prone to
breaking at later updates.
I would not say "random guesswork".
--- proxy.c.orig 2008-10-06 09:22:20.000000000 +0200
+++ proxy.c 2008-11-06 20:49:55.000000000 +0100
@@ -348,6 +348,14 @@ establish_http_proxy_passthru (struct ht
if (!send_line_crlf (sd, buf))
goto error;
+ /* send Host: header for HTTP version above 1.0 */
+ if (strcmp(p->options.http_version, "1.0") != 0) {
This doesn't check for ">= 1.1", but "!= 1.0".
What if I use 0.9, or garbage, or nothing?
Oops, you lose -- in either case.
What have we currently? Only HTTP/1.0 and HTTP/1.1.
0.9 does not matter, it defines GET only, has not headers is not able to proxy HTTPS
connections. So my solution handles backward compatibility without problems. The
remaining question is how to handle future upward compatibility. You never know, what you
will get. So we can either:
- disable all future protocol version the user may configure or
- hope that the protocol is upwards compatible.
I decided to implement the 2nd solution, because the other parts are already implemented
this way. The user may already use arbitrary protocol versions.
You may want to accept only 1.0 and 1.1 rather than 1.0 and 1.n for n >= 1
- but there should only ever be A SINGLE PLACE to enforce that.
Else you'll have a hell of work once you start implementing HTTP/1.2
later on...
But then this check must no be done for the Host: header, but for the complete proxy
support. I see your objections, but "my" additional header does not introduce an additional
security problem, all other proxy setup code is already version independent.
May be "CONNECT HTTP/2.0" will directly connect to the NSA/BND/(insert your favorite
agency here)? ;-)
I'd say that if you have a routine which handles HTTP/1.x, you should be
pretty safe. At the moment 0.9, 1.0 and 1.1 is what's in use. 0.9 I would
not care about now, as that one is underspecified and proper RFC is
completely missing (afaik). If I'm not mistaken, 0.9 is the version used
by clients not supporting all 1.0 features. I think a work on a HTTP/2.0
protocol did also start but nobody has brought that to life. (you might
find some references which is about 10 years old or so)
So make sure 1.0 and 1.1 is handled properly, and you're safe. I'd say
that 1.2+ can at the moment be handled as 1.1, as the protocols usually is
backwards compatible. And I would rather reject 2.0 and 0.9 protocols, as
they most probably should be considered undocumented at the moment.
kind regards,
David Sommerseth
