On 13.12.2013 20:17, William A. Rowe Jr. wrote:
> I will agree, plain-text forward proxy listeners are unaffected, only
> https:// listeners are tested for TLS/Host: mismatches. Also, if the
> proxy request refers to a resource on the same proxy host, I suppose
> that would also succeed. Although I can't think of a client which would
> attempt that.
>
> Otherwise, yes, https:// forward-proxied requests are entirely broken
> by the error test AP02032.
That's exactly where the misconception lies (and no, I'm not confused).
When forward proxying SSL connections with the CONNECT method, all of
the handshake is completely opaque to mod_proxy[_http]. Since you
specifically mentioned 2.2.25, you're apparently claiming that r1497466
and r1497470 have broken SSL forward proxying. That's certainly not the
case, they only relate to reverse proxying.
> This report details
> forward proxy misbehavior. This entire class of defects are rooted in
> the TLS/SNI implementation, but *this* forward proxy defect is trivial
> to reproduce.
When forward proxying SSL requests with CONNECT - as this thread
apparently is about -, then it's the user's browser which fills in the
SNI extension. And gladly (and not unsurpringly at all), browsers have
always done the right thing: fill in the SNI extension based on the
hostname component of the URI they are requesting, not on the host name
of the proxy they are connecting to.
> There is no toggle for the misguided AP 02032 error check behavior,
> causing all forward proxy CONNECT requests to fail.
The equivalent code for 2.2.x has been present in mod_ssl since the
initial SNI implementation was added with r776281 (for 2.2.12). The
reverse proxy related changes in 2.2.25 do not have any interaction with
that code (and neither an impact which would "completely break" anything).
The "misguided AP 02032 error check behavior" would certainly have been
discovered much earlier (soon after the 2.2.12 release, I assume), if it
had really been "misguided". Similarly, the claims in PR 54656 ("a host
of other design errors" with the SNI logic etc.) do not appear to be
substantial either.
>> (The issue you are looking into should be solved on the client-side
>> code, i.e. primarily in mod_proxy[_http], IMO, although I wouldn't
>> mind modifications to the server-side part [ssl_hook_ReadReq] either.)
>
> Because AP 02032 causes to the forward proxy server side defect, that
> wouldn't get us any closer to restoring forward proxy behavior.
I won't defend the checks introduced with r757373 under all
circumstances, but they are definitely not the cause for this purported
defect. As identified by Rüdiger and Yann, they primarily relate to the
question of how to handle requests from non-SNI capable clients for
non-default vhosts (how/if specific vhost-level SSL parameters should be
enforced, and when/if renegotiations will occur).
Kaspar
