> After looking into the source code, there are (at least) two places
> where this patch has to be applied.
> 
> 1) The place described earlier and mentioned in the original patch (I
> would guess)
> 2) There is duplicated code in the same function when the proxy answered
> with "407 Proxy Authentication Required". Maybe it is possible to move
> this into an extra function, maybe send_proxy_headers.

Apparently I was mistaken at this point. With the very first place where
an HTTP CONNECT is issued being the only exception, at all other places
the Host header is sent.

However, I'm not sure whether these are correct. As far as I can see,
there are two possible hosts which can be sent:

* 'host' (denoting the 'remote' config option)
* 'p->options.server' (denoting the 'http-proxy' config option)

I would guess that sending the latter would be correct, but the OpenVPN
sources use the first one. For example, consider the following
configuration:

        http-proxy-option VERSION 1.1
        http-proxy vpn.example.com 80
        remote localhost 1194

I would expect the OpenVPN client to send the request as following (over
a connection with vpn.example.com:80):

        CONNECT localhost:1194 HTTP/1.1
        Host: vpn.example.com

At the moment (and with the patch proposed in 2008), the following
request is sent:

        CONNECT localhost:1194 HTTP/1.1
        Host: localhost

The problem is that the RFC isn't clear at that point. Consider the
following snippet from the section about 'CONNECT':

>    This specification reserves the method name CONNECT for use with a
>    proxy that can dynamically switch to being a tunnel (e.g. SSL
>    tunneling [44]).

The section about the host header isn't very helpful either:

>    The Host request-header field specifies the Internet host and port
>    number of the resource being requested, as obtained from the original
>    URI given by the user or referring resource (generally an HTTP URL
>    [...]

From this, I would remotely guess that my proposal is correct.

I didn't receive an answer from the Apache folks yet about how
mod_proxy_connect differentiates between multiple VirtualHosts. My short
experiments only showed indifferent behavior, so maybe some of you who
have more experience could tell.

For completeness' sake I've attached the appropriate patch (without HTTP
version check, as described earlier). Please let me know what you think
about it.

Lars
--- openvpn-2.1.3.orig/proxy.c	2010-09-26 23:05:46.000000000 +0100
+++ openvpn-2.1.3/proxy.c	2010-09-29 15:50:55.000000000 +0100
@@ -551,6 +551,10 @@
       /* send HTTP CONNECT message to proxy */
       if (!send_line_crlf (sd, buf))
 	goto error;
+      
+      openvpn_snprintf(buf, sizeof(buf), "Host: %s", p->options.server);
+      if (!send_line_crlf(sd, buf))
+        goto error;
 
       /* send User-Agent string if provided */
       if (p->options.user_agent)
@@ -676,7 +680,7 @@
 
           
           /* send HOST etc, */
-          openvpn_snprintf (buf, sizeof(buf), "Host: %s", host);
+          openvpn_snprintf (buf, sizeof(buf), "Host: %s", p->options.server);
           msg (D_PROXY, "Send to HTTP proxy: '%s'", buf);
           if (!send_line_crlf (sd, buf))
             goto error;
@@ -787,7 +791,7 @@
 		goto error;
 
 	      /* send HOST etc, */
-	      openvpn_snprintf (buf, sizeof(buf), "Host: %s", host);
+	      openvpn_snprintf (buf, sizeof(buf), "Host: %s", p->options.server);
 	      msg (D_PROXY, "Send to HTTP proxy: '%s'", buf);
 	      if (!send_line_crlf (sd, buf))
 		goto error;

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to