On Mon, 16 Dec 2013 22:29:39 -0600 "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100 > Kaspar Brand <httpd-dev.2...@velox.ch> 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. > > Are you aware of a more authoritative source for the CONNECT HTTP > verb? I'm happy to parse that with you. > > My defect is really very simple, Here's a request to proxy.example.com > created in order to tunnel an https connection to server.example.com; > > CONNECT server.example.com:443 HTTP/1.1 > Host: server.example.com:443 > 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, server.example.com != proxy.example.com and > things fall apart. The defect is really that simple to describe. The defect is actually a little more insideous. If you toggle the Host to break RFC2616's definition, and use the proxy.example.com identity instead, the end result will be the same - it will still mismatch and report that the SNI host should have matched server.example.com. That is even true when connecting non-ssl to server.example.com:80. If the hostname header value was already transposed from the user-agent request headers into a proxy request headers at the time that test occurs then we might have a more complex problem.
