httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Tue, 17 Dec 2013 17:34:33 GMT
On 17.12.2013 05:29, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand <> wrote:
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>>> I beg to differ.  We are left with a question of whether you are
>>> responsible to defend the current behavior, or whether I can simply
>>> rely on RFC2817 to document that you are wrong,
>> RFC 2817 is irrelevant in the context of https: URIs (see its abstract
>> and section 8.1).
> Kaspar, I point you to section 5.2 for the definition of CONNECT.

The entire section 5 is about applying CONNECT in the context of issuing
requests with an "Upgrade:" across proxies, neither about the user agent
connecting to the proxy nor hop-by-hop connections secured by TLS:

   5. Upgrade across Proxies

   As a hop-by-hop header, Upgrade is negotiated between each pair of
   HTTP counterparties.  If a User Agent sends a request with an Upgrade
   header to a proxy, it is requesting a change to the protocol between
   itself and the proxy, not an end-to-end change.

   Since TLS, in particular, requires end-to-end connectivity to provide
   authentication and prevent man-in-the-middle attacks, this memo
   specifies the CONNECT method to establish a tunnel across proxies.

   Once a tunnel is established, any of the operations in Section 3 can
   be used to establish a TLS connection.

Note in particular the last sentence: TLS only comes into play *after*
the tunnel has been established, i.e., all these CONNECT requests sent
via plain HTTP. Similarly, section 8.2 states:

   The Upgrade: mechanism defined here only requires onward tunneling at
   port 80.

> Are you aware of a more authoritative source for the CONNECT HTTP verb?

There isn't, and trying to apply RFC 2817 to a case it clearly is
neither applicable to nor authoritative for is probably the reason why
this thread seems to have caused so much confusion.

> My defect is really very simple, Here's a request to
> created in order to tunnel an https connection to;
>    Host:
>    Proxy-Authorization: basic aGVsbG86d29ybGQ=
> In this case, the admin wants no other network user to share the same
> auth identity, therefore the server-to-proxy connection is https://.
> In receiving the request, != and
> things fall apart.  The defect is really that simple to describe.

No disagreement that this is a valid use case. But the defect does not
consist of a bug in the current httpd code, the problem is the lack of a
relevant standard.

SSL forward proxying was never standardized after
expired, and as Rainer pointed out, of today's common browsers only
Chrome currently supports CONNECT over SSL, which is as non-standardized
as connecting to a proxy via SSL ("Please be aware that other browser do
not support the HTTPS proxy type in a .pac file", as their docs say).

If your goal is to make httpd compatible with Chrome's "Secure Web
Proxy" or another other client doing CONNECT over SSL, that's fine, and
I'm not opposed to it (a small change to ssl_hook_ReadReq [attached]
might actually be sufficient for this specific problem). But claiming
that "https:// forward-proxied requests are entirely broken" by the
current SNI implementation in mod_ssl, declaring it a
(, or using
terms like "foolishness" to characterize existing code is certainly not
helpful when trying to achieve this goal. (Note that I'm not the "fool"
who was written [nor committed] the particular code in question, so I
don't have to take the blame for this, and could simply stop bothering
further. I do think, however, that the fourth principle of "The Apache
Way" should also be valid for both this list and comments on ASF
Bugzilla, and am interested in finding an appropriate solution based on
technical-level discussions, nothing else.)


View raw message