On 12/12/2013 12:15 AM, William A. Rowe Jr. wrote:
On Tue, 26 Nov 2013 09:47:44 +0100
Yann Ylavic <ylavic....@gmail.com> wrote:
On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <ylavic....@gmail.com>
wrote:
On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
<httpd-dev.2...@velox.ch>wrote:
On 26.11.2013 00:46, Yann Ylavic wrote:
Ideas for the appropriate patch to httpd? Scope this fix to
CONNECT requests alone, or all forward proxy requests?
Maybe all forward proxy modules are concerned.
There is PR 55782
which I started to debug but did not finish (run out of time).
From there it looked like ProxyPassPreserveHost may cause
problems too with SNI (not sure yet).
Also, 54656.
Anyway, shouldn't the proxy code(s) use the Host header to fill
in the
SNI
from r->headers_in (when applicable), instead of r->hostname, at
least
for
the CONNECT and ProxyPassPreserveHost cases?
AFAICT, this was the idea in the original patch for PR 53134, but a
"slightly different approach" was then committed (r1333969).
As far as PR 55782 is concerned, the problem might be that
proxy_util.c:ap_proxy_determine_connection() does not take Host:
header differences into account when checking if an existing
connection can be reused (not sure). With SNI this would have the
effect that the hostname from the TLS handshake is causing the
mismatch with the Host: header.
ap_proxy_determine_connection() should only care about IP:port
reuse, which can be even if the Host has changed.
Oh wait, you are probably right here, the IP:port cannot be reused if
the Host has changed with SNI, sorry for the noise...
Right :)
Using the Host as SNI at first (handshake) for
CONNECT/ProxyPreserveHost/subrequests (at least) is still the way to
go, IMHO.
Yes, that initial SNI Host -> vhost -> SSL negotiation is all correct
and get us to the appropriate configuration of ssl keys and certs for
the SNI connection's host target.
It gets to the target whether the conf is appropriate or not :-)
The rest of the SNI hostname processing steps are where the problem
lies. We still need to perform http headers -> vhost translation after
the connection is established. If there's any desire to do SNI hostname
validation, that has to be limited to comparing that hostname to the
ServerName/ServerAlias entries, not to the HTTP Host: which has a
different semantic meaning and is the only hostname of interest to
httpd as an HTTP server.
this part was always a bit strange: the initial idea was: When the code
sees the Host: and when there was no sni, to force a renegotiation
with the right cert/key.
best regards
Peter
