You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2013/12/12 00:15:45 UTC
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
On Tue, 26 Nov 2013 09:47:44 +0100
Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <yl...@gmail.com>
> wrote:
>
> > On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
> > <ht...@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.
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.
Re: [SPAM?]: RE: Behavior of Host: vs. SNI Hostname in proxy CONNECT
requests
Posted by Peter Sylvester <pe...@edelweb.fr>.
On 12/12/2013 10:28 AM, Plüm, Rüdiger, Vodafone Group wrote:
>
>> -----Original Message-----
>> From: Kaspar Brand [mailto:httpd-dev.2013@velox.ch]
>> Sent: Donnerstag, 12. Dezember 2013 07:01
>> To: dev@httpd.apache.org
>> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
>>
>> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
>>> 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.
>> The logic in ssl_hook_ReadReq was added with r757373. It wasn't in the
>> initial version of the patch for SNI support (r606190). I didn't find
>> prior discussion of r757373 on the mailing list, but perhaps it was
>> motivated by this statement in RFC 6066 (RFC 4366 at the time):
>>
>> If the server_name is
>> established in the TLS session handshake, the client SHOULD NOT
>> attempt to request a different server name at the application layer.
>>
>> I never really understood the reasoning for turning this into a "reject
>> requests if the SNI extension and the Host header differ" (see e.g. [1],
> The reason is that you can define SSL parameters in Virtual hosts like SSLCiphers or SSLProtocols.
> If Host header and SNI host match you can be sure that the parameters that you set in the virtual host from which
> your request is being served have been used. If you allow a mismatch between SNI host and host header you might
> serve the request on a SSL connection that does not match your SSL parameters set up for the particular virtual host.
>
> Regards
>
> Rüdiger
SHOULD NOT does leave all things open to the server.
This was implemented 10 years ago.
Clients used sslv2, and 32bit xp today still cannot do sni.
Anyway: I am puzzled about the problem:
- There is some matching of the SNI value to some value X
from a server definition.
- X should be "compatible" to what is send later in the Host:
If there is some proxying involved then X should be the shared
value?
If there is NO SNI, that's another story
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Tim Bannister <is...@jellybaby.net>.
On 13 Dec 2013, at 06:05, Kaspar Brand <ht...@velox.ch> wrote:
> On 12.12.2013 20:06, William A. Rowe Jr. wrote:
>> On Thu, 12 Dec 2013 09:28:16 +0000 "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com> wrote:
>>
>> Yes, and? Why would this differ from the historical handling of the Host: header? The HTTP Host header is not the dns name of this hop, but the hostname component of the uri. This logic has completely broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
>
> "completely broken" is a relatively bold statement. As far as I can tell, it essentially boils down to the interpretation of the "url" parameter in the ProxyPass directive ("a partial URL for the remote server", as the docs currently say). In my understanding, in the https:// case, it's a URL for which mod_proxy_http should perform TLS name checking (à la RFC 6125), not simply a hostname [plus port] for opening an TCP connection and then issuing a CONNECT request.
ProxyPass doesn't get used on my forward proxies. This is the case where, e.g., your user-agent wants to reach an HTTPS URL via a proxy and so sends, e.g.:
CONNECT remote.host.example:443 HTTP/1.1
Host: remote.host.example
over an HTTPS connection to proxy.example. The configuration for my forward proxies isn't much different from the example at http://httpd.apache.org/docs/current/mod/mod_proxy.html#examples
I'm not sure what the TLS SNI hostname should contain but, AIUI, clients would send "proxy.example". It's not reasonable to expect the proxy server to know the private key for remote.host.example
--
Tim Bannister – isoma@jellybaby.net
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Mon, 16 Dec 2013 22:18:46 +0100
Rainer Jung <ra...@kippdata.de> wrote:
> On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> > On Sat, 14 Dec 2013 10:25:00 +0100
> > Kaspar Brand <ht...@velox.ch> wrote:
> >
> >> Just unload mod_proxy_http and mod_ssl
> >> from the configuration, and you'll find that forward proxying
> >> https:// requests continues to work perfectly, i.e. is completely
> >> unaffected by any code in these two modules (mod_proxy_connect is
> >> all it takes)
> >
> > I'm just wondering two days later if I'm the only one struck by the
> > madness of insisting 'httpd can only do one thing at once', or
> > whether I'm one of many who were too taken aback to respond yet.
> >
> > One thing httpd has done for years is 'walk and chew gum at the same
> > time', and done it well.
> >
> > If you are actually arguing for retaining a defect on the basis
> > that it is acceptable to require the user drop modules used by
> > other hosts running in the same process, I'm pretty sure your
> > solution is not acceptable to the pmc of this project.
> >
> > The user-agent must use an https CONNECT from the user agent to the
> > proxy server (using mod_ssl) lest the entire office/floor/it ops
> > center sniff that traffic off the wire. Your solution is devoid of
> > any sense of logic or security.
>
> "must" is a bit strong: AFAIK user agents will not use https to an
> https forward proxy, but instead http plus CONNECT.
If auth is used, https from the user-agent to the proxy host, and
https tunneled from the user-agent straight through to the target of
the CONNECT request, provided an https URL for the https protocol
proxy is configured.
> The proxy is a
> man in the middle but should nevertheless not be able to easily
> decrypt the ssl encryption set up between user agent and target
> server (via the packet forwarding proxy).
Also my understanding. https: proxy CONNECT would tunnel an entirely
distict ssl session end to end, with the proxy itself having very
little chance of decoding the conversation.
> The like no other sniffing
> system should be. What is noticeable though is the address/name and
> port of the system the user agent wants to connect to (the CONNECT
> data which is send unencrypted to the forward proxy).
Yes, the https target is revealed. Proxy auth is revealed (often
dangerously overlapping the user's credentials on other services).
> It seems Firefox does not yet support speaking https to the forward
> proxy (https://bugzilla.mozilla.org/show_bug.cgi?id=378637), and
> chrome seems to support it
> (http://www.chromium.org/developers/design-documents/secure-web-proxy).
> i haven't checked the current status in depth though.
Thanks for the data points, collecting a number of additional data
points in the morning.
> Finally: CONNECT over HTTPS wasn't working in our web server for a
> long time, see
> https://issues.apache.org/bugzilla/show_bug.cgi?id=29744.
I'd been aware of that.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Rainer Jung <ra...@kippdata.de>.
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand <ht...@velox.ch> wrote:
>
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>> ProxyPass is not involved in the SSL forward proxy case at all, as I
>> already tried to point out.
>
> Good, we've finally agreed. This entire thread has been on forward
> proxy, so I'm glad you've decided to stop delving into the ProxyPass
> side of this misbehavior.
>
>> Just unload mod_proxy_http and mod_ssl
>> from the configuration, and you'll find that forward proxying https://
>> requests continues to work perfectly, i.e. is completely unaffected by
>> any code in these two modules (mod_proxy_connect is all it takes)
>
> I'm just wondering two days later if I'm the only one struck by the
> madness of insisting 'httpd can only do one thing at once', or whether
> I'm one of many who were too taken aback to respond yet.
>
> One thing httpd has done for years is 'walk and chew gum at the same
> time', and done it well.
>
> If you are actually arguing for retaining a defect on the basis that
> it is acceptable to require the user drop modules used by other hosts
> running in the same process, I'm pretty sure your solution is not
> acceptable to the pmc of this project.
>
> The user-agent must use an https CONNECT from the user agent to the
> proxy server (using mod_ssl) lest the entire office/floor/it ops center
> sniff that traffic off the wire. Your solution is devoid of any sense
> of logic or security.
"must" is a bit strong: AFAIK user agents will not use https to an https
forward proxy, but instead http plus CONNECT. The proxy is a man in the
middle but should nevertheless not be able to easily decrypt the ssl
encryption set up between user agent and target server (via the packet
forwarding proxy). The like no other sniffing system should be. What is
noticeable though is the address/name and port of the system the user
agent wants to connect to (the CONNECT data which is send unencrypted to
the forward proxy).
It seems Firefox does not yet support speaking https to the forward
proxy (https://bugzilla.mozilla.org/show_bug.cgi?id=378637), and chrome
seems to support it
(http://www.chromium.org/developers/design-documents/secure-web-proxy).
i haven't checked the current status in depth though.
Finally: CONNECT over HTTPS wasn't working in our web server for a long
time, see https://issues.apache.org/bugzilla/show_bug.cgi?id=29744.
Regards,
Rainer
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand <ht...@velox.ch> wrote:
>
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>> ProxyPass is not involved in the SSL forward proxy case at all, as I
>> already tried to point out.
>
> Good, we've finally agreed. This entire thread has been on forward
> proxy, so I'm glad you've decided to stop delving into the ProxyPass
> side of this misbehavior.
Just for the record: it wasn't me who brought in references to PR 55782
or PR 54656 into this thread (both of which are about reverse proxying):
https://mail-archives.apache.org/mod_mbox/httpd-dev/201311.mbox/%3CCAKQ1sVPv86nzsbCk4Cyz-CG2qkhi1ioJwiig-3yLXpUU%2B%3D68qg%40mail.gmail.com%3E
https://mail-archives.apache.org/mod_mbox/httpd-dev/201312.mbox/%3C20131211171545.2012e83b%40hub%3E
>> Just unload mod_proxy_http and mod_ssl
>> from the configuration, and you'll find that forward proxying https://
>> requests continues to work perfectly, i.e. is completely unaffected by
>> any code in these two modules (mod_proxy_connect is all it takes)
>
> I'm just wondering two days later if I'm the only one struck by the
> madness of insisting 'httpd can only do one thing at once', or whether
> I'm one of many who were too taken aback to respond yet.
>
> One thing httpd has done for years is 'walk and chew gum at the same
> time', and done it well.
>
> If you are actually arguing for retaining a defect on the basis that
> it is acceptable to require the user drop modules used by other hosts
> running in the same process, I'm pretty sure your solution is not
> acceptable to the pmc of this project.
>
> The user-agent must use an https CONNECT from the user agent to the
> proxy server (using mod_ssl) lest the entire office/floor/it ops center
> sniff that traffic off the wire. Your solution is devoid of any sense
> of logic or security.
It's fairly far-fetched to make it appear as if I were proposing this as
a "solution", and there isn't any necessity to get personal in this thread.
I was making that statement in the context of illustrating that "ProxyPass
is not involved in the SSL forward proxy case at all".
I will reply to the issue about CONNECT and the relevance of RFC 2817
in a separate message.
Kaspar
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand <ht...@velox.ch> wrote:
> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
> ProxyPass is not involved in the SSL forward proxy case at all, as I
> already tried to point out.
Good, we've finally agreed. This entire thread has been on forward
proxy, so I'm glad you've decided to stop delving into the ProxyPass
side of this misbehavior.
> Just unload mod_proxy_http and mod_ssl
> from the configuration, and you'll find that forward proxying https://
> requests continues to work perfectly, i.e. is completely unaffected by
> any code in these two modules (mod_proxy_connect is all it takes)
I'm just wondering two days later if I'm the only one struck by the
madness of insisting 'httpd can only do one thing at once', or whether
I'm one of many who were too taken aback to respond yet.
One thing httpd has done for years is 'walk and chew gum at the same
time', and done it well.
If you are actually arguing for retaining a defect on the basis that
it is acceptable to require the user drop modules used by other hosts
running in the same process, I'm pretty sure your solution is not
acceptable to the pmc of this project.
The user-agent must use an https CONNECT from the user agent to the
proxy server (using mod_ssl) lest the entire office/floor/it ops center
sniff that traffic off the wire. Your solution is devoid of any sense
of logic or security.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Dec 17, 2013 at 5:44 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
>
> On Mon, 16 Dec 2013 22:29:39 -0600
> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
> > 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.
This occurs only in the case where CONNECT over SSL is used (which is
not so widespread, since SSL tunneling clients only seem to support
this), as opposed to CONNECT on a plain TCP connection through
mod_proxy_connect to a backend (which is used by most/all? browsers,
to forward any stream --SSL or not-- between the client and the origin
server).
Since CONNECT over SSL is handled by mod_proxy_connect (r813178,
following PR29744), httpd should also make it work with SNI, IMHO
https://issues.apache.org/bugzilla/show_bug.cgi?id=29744#c141 is still
such (legitimate) case of CONNECT over SSL which won't work without
your patch.
I also agree with you that SNI can hardly always be mapped to Host:
without the possibility to use an IP address and/or a port (both
legitimate Host: parts).
So I'm +1 with your patch, though it would be nice if
SSLStrictSNIVhostCheck could default to "on" for IP-based vhosts and
named-based vhosts *all* listenning on port 443, except when
ProxyRequests is "on"...
I don't know if it's feasible at all (since at least mod_rewrite can
change all that at runtime), but these are typical cases for enforcing
strict SNI (when provided by the client).
>
> 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.
I think the same apply for forward proxy (not CONNECT), ie :
GET http(s)://server.example.com/ HTTP/1.1
Host: proxy.example.com
The latter is simply ignored.
Regards,
Yann.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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 <ht...@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.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
Yann Ylavic wrote:
> On Mon, Dec 23, 2013 at 9:49 PM, Ruediger Pluem <rp...@apache.org> wrote:
>>
>>
>> Kaspar Brand wrote:
>>> On 21.12.2013 14:21, Ruediger Pluem wrote:
>>>>> I guess a more general fix for this would be:
>>>>
>>>> No further comments / feedback? If not then I would commit the patch.
>>>
>>> The change looks fine to me (for easier comparison/review,
>>> a whitespace-change-ignoring version is attached).
>>>
>>> What would probably make sense is to amend the following comment
>>> on this occasion:
>>>
>>> /*
>>> * The SNI extension supplied a hostname. So don't accept requests
>>> * with either no hostname or a different hostname.
>>> */
>>>
>>> It doesn't say anything about the rationale right now, and as
>>> recent discussions have shown, it would be helpful to explain
>>> why this is done.
>>
>> Done. I have tried to improve the comment and added a TODO if my
>> reasoning for the checks is really true.
>
> Sorry to be late, I'm overwhelmed these days...
>
> + /*
> + * The SNI extension supplied a hostname. So don't accept requests
> + * with either no hostname or a different hostname as this could
> + * cause us to end up in a different virtual host as the one that
> + * was used for the handshake causing different SSL parameters to
> + * be applied.
> + * XXX: TODO check if this is really true and that there are
> + * SSL parameters that are not fixed by a renegotiation in
> + * ssl_hook_Access.
> + */
>
> According to http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303@velox.ch%3E,
> the (great) analyse Kaspar made in 2008, the only parameters which
> won't be renegotiated are SSLCACertificateFile/Path and
> SSLCADNRequestFile/Path.
Thanks for the digging, but doesn't this mean that I can have a client cert verification to the SNI host first
with a cert that is not accepted in the host of the host header and hence circumvent a proper client cert
checking during renegotiation?
Hence it would be unsafe to allow switching the virtual host (at least with client certs) from the SNI chosen one
to a host header chosen one.
Hence the checks are a safe thing to do at least in the client cert verification case.
Furthermore SSLProtocol is mentioned as "not switchable" during a renegotiation. Hence it would be possible to
circumvent stricter SSLProtocol requirements in one host by more open once in another host.
> This is because of the lacking OpenSSL's SSL_set_cert_store()
> function, which always seem to be the case with the latest versions
> (AFAICT).
> There may also be issues when SSLVerifyClient is "optional*", but
> optional issues IMHO.
>
> + if (!r->hostname) {
> + ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
> APLOGNO(02031)
> + "Hostname %s provided via SNI, but no hostname"
> + " provided in HTTP request", servername);
> + return HTTP_BAD_REQUEST;
> + }
>
> One thing this code is possibly missing is HTTP < 1.1 requests (as
> William noted in his proposed patch), where no Host is provided,
> couldn't SNI be used by the client in this case?
Maybe, but how many HTTP 0.9 clients / HTTP 1.0 clients that do not sent a host header and do SNI do you know?
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Dec 24, 2013 at 1:50 PM, Dr Stephen Henson <
shenson@opensslfoundation.com> wrote:
> On 24/12/2013 11:58, Yann Ylavic wrote:
> >
> > According to
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303@velox.ch%3E
> ,
> > the (great) analyse Kaspar made in 2008, the only parameters which
> > won't be renegotiated are SSLCACertificateFile/Path and
> > SSLCADNRequestFile/Path.
> > This is because of the lacking OpenSSL's SSL_set_cert_store()
> > function, which always seem to be the case with the latest versions
> > (AFAICT).
>
> OpenSSL 1.0.2 and later will address this. It supports separate
> verification and
> chain building stores which can be set at the SSL_CTX or SSL level. See:
>
> http://www.openssl.org/docs/ssl/SSL_CTX_set1_verify_cert_store.html
>
Thanks for the pointer.
Regards,
Yann.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 24/12/2013 11:58, Yann Ylavic wrote:
>
> According to http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303@velox.ch%3E,
> the (great) analyse Kaspar made in 2008, the only parameters which
> won't be renegotiated are SSLCACertificateFile/Path and
> SSLCADNRequestFile/Path.
> This is because of the lacking OpenSSL's SSL_set_cert_store()
> function, which always seem to be the case with the latest versions
> (AFAICT).
OpenSSL 1.0.2 and later will address this. It supports separate verification and
chain building stores which can be set at the SSL_CTX or SSL level. See:
http://www.openssl.org/docs/ssl/SSL_CTX_set1_verify_cert_store.html
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Dec 23, 2013 at 9:49 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> Kaspar Brand wrote:
>> On 21.12.2013 14:21, Ruediger Pluem wrote:
>>>> I guess a more general fix for this would be:
>>>
>>> No further comments / feedback? If not then I would commit the patch.
>>
>> The change looks fine to me (for easier comparison/review,
>> a whitespace-change-ignoring version is attached).
>>
>> What would probably make sense is to amend the following comment
>> on this occasion:
>>
>> /*
>> * The SNI extension supplied a hostname. So don't accept requests
>> * with either no hostname or a different hostname.
>> */
>>
>> It doesn't say anything about the rationale right now, and as
>> recent discussions have shown, it would be helpful to explain
>> why this is done.
>
> Done. I have tried to improve the comment and added a TODO if my
> reasoning for the checks is really true.
Sorry to be late, I'm overwhelmed these days...
+ /*
+ * The SNI extension supplied a hostname. So don't accept requests
+ * with either no hostname or a different hostname as this could
+ * cause us to end up in a different virtual host as the one that
+ * was used for the handshake causing different SSL parameters to
+ * be applied.
+ * XXX: TODO check if this is really true and that there are
+ * SSL parameters that are not fixed by a renegotiation in
+ * ssl_hook_Access.
+ */
According to http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303@velox.ch%3E,
the (great) analyse Kaspar made in 2008, the only parameters which
won't be renegotiated are SSLCACertificateFile/Path and
SSLCADNRequestFile/Path.
This is because of the lacking OpenSSL's SSL_set_cert_store()
function, which always seem to be the case with the latest versions
(AFAICT).
There may also be issues when SSLVerifyClient is "optional*", but
optional issues IMHO.
+ if (!r->hostname) {
+ ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
APLOGNO(02031)
+ "Hostname %s provided via SNI, but no hostname"
+ " provided in HTTP request", servername);
+ return HTTP_BAD_REQUEST;
+ }
One thing this code is possibly missing is HTTP < 1.1 requests (as
William noted in his proposed patch), where no Host is provided,
couldn't SNI be used by the client in this case?
Personnaly I like the idea of being able to disable the check, when
SSLStrictSNIVHostCheck is off for example, but probably it should be
set "on" by default in this case.
Regards,
Yann.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
Ruediger Pluem wrote:
>
>
> Kaspar Brand wrote:
>> On 21.12.2013 14:21, Ruediger Pluem wrote:
>>>> I guess a more general fix for this would be:
>>>
>>> No further comments / feedback? If not then I would commit the patch.
>>
>> The change looks fine to me (for easier comparison/review,
>> a whitespace-change-ignoring version is attached).
>>
>> What would probably make sense is to amend the following comment
>> on this occasion:
>>
>> /*
>> * The SNI extension supplied a hostname. So don't accept requests
>> * with either no hostname or a different hostname.
>> */
>>
>> It doesn't say anything about the rationale right now, and as
>> recent discussions have shown, it would be helpful to explain
>> why this is done.
>
> Done. I have tried to improve the comment and added a TODO if my
> reasoning for the checks is really true.
I improved the comment (r1555240). IMHO the checks still make sense.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
Kaspar Brand wrote:
> On 21.12.2013 14:21, Ruediger Pluem wrote:
>>> I guess a more general fix for this would be:
>>
>> No further comments / feedback? If not then I would commit the patch.
>
> The change looks fine to me (for easier comparison/review,
> a whitespace-change-ignoring version is attached).
>
> What would probably make sense is to amend the following comment
> on this occasion:
>
> /*
> * The SNI extension supplied a hostname. So don't accept requests
> * with either no hostname or a different hostname.
> */
>
> It doesn't say anything about the rationale right now, and as
> recent discussions have shown, it would be helpful to explain
> why this is done.
Done. I have tried to improve the comment and added a TODO if my
reasoning for the checks is really true.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 21.12.2013 14:21, Ruediger Pluem wrote:
>> I guess a more general fix for this would be:
>
> No further comments / feedback? If not then I would commit the patch.
The change looks fine to me (for easier comparison/review,
a whitespace-change-ignoring version is attached).
What would probably make sense is to amend the following comment
on this occasion:
/*
* The SNI extension supplied a hostname. So don't accept requests
* with either no hostname or a different hostname.
*/
It doesn't say anything about the rationale right now, and as
recent discussions have shown, it would be helpful to explain
why this is done.
Kaspar
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
Ruediger Pluem wrote:
>
>
> Kaspar Brand wrote:
>
>> 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]
>
> I guess a more general fix for this would be:
No further comments / feedback? If not then I would commit the patch.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
Kaspar Brand wrote:
> 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]
I guess a more general fix for this would be:
Index: ssl_engine_kernel.c
===================================================================
--- ssl_engine_kernel.c (revision 1551684)
+++ ssl_engine_kernel.c (working copy)
@@ -164,48 +164,50 @@
return DECLINED;
}
#ifdef HAVE_TLSEXT
- if ((servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name))) {
- char *host, *scope_id;
- apr_port_t port;
- apr_status_t rv;
+ if (r->proxyreq != PROXYREQ_PROXY) {
+ if ((servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name))) {
+ char *host, *scope_id;
+ apr_port_t port;
+ apr_status_t rv;
- /*
- * The SNI extension supplied a hostname. So don't accept requests
- * with either no hostname or a different hostname.
- */
- if (!r->hostname) {
- ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02031)
- "Hostname %s provided via SNI, but no hostname"
- " provided in HTTP request", servername);
- return HTTP_BAD_REQUEST;
+ /*
+ * The SNI extension supplied a hostname. So don't accept requests
+ * with either no hostname or a different hostname.
+ */
+ if (!r->hostname) {
+ ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02031)
+ "Hostname %s provided via SNI, but no hostname"
+ " provided in HTTP request", servername);
+ return HTTP_BAD_REQUEST;
+ }
+ rv = apr_parse_addr_port(&host, &scope_id, &port, r->hostname, r->pool);
+ if (rv != APR_SUCCESS || scope_id) {
+ return HTTP_BAD_REQUEST;
+ }
+ if (strcasecmp(host, servername)) {
+ ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02032)
+ "Hostname %s provided via SNI and hostname %s provided"
+ " via HTTP are different", servername, host);
+ return HTTP_BAD_REQUEST;
+ }
}
- rv = apr_parse_addr_port(&host, &scope_id, &port, r->hostname, r->pool);
- if (rv != APR_SUCCESS || scope_id) {
- return HTTP_BAD_REQUEST;
+ else if (((sc->strict_sni_vhost_check == SSL_ENABLED_TRUE)
+ || (mySrvConfig(sslconn->server))->strict_sni_vhost_check
+ == SSL_ENABLED_TRUE)
+ && r->connection->vhost_lookup_data) {
+ /*
+ * We are using a name based configuration here, but no hostname was
+ * provided via SNI. Don't allow that if are requested to do strict
+ * checking. Check wether this strict checking was setup either in the
+ * server config we used for handshaking or in our current server.
+ * This should avoid insecure configuration by accident.
+ */
+ ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02033)
+ "No hostname was provided via SNI for a name based"
+ " virtual host");
+ return HTTP_FORBIDDEN;
}
- if (strcasecmp(host, servername)) {
- ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02032)
- "Hostname %s provided via SNI and hostname %s provided"
- " via HTTP are different", servername, host);
- return HTTP_BAD_REQUEST;
- }
}
- else if (((sc->strict_sni_vhost_check == SSL_ENABLED_TRUE)
- || (mySrvConfig(sslconn->server))->strict_sni_vhost_check
- == SSL_ENABLED_TRUE)
- && r->connection->vhost_lookup_data) {
- /*
- * We are using a name based configuration here, but no hostname was
- * provided via SNI. Don't allow that if are requested to do strict
- * checking. Check wether this strict checking was setup either in the
- * server config we used for handshaking or in our current server.
- * This should avoid insecure configuration by accident.
- */
- ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02033)
- "No hostname was provided via SNI for a name based"
- " virtual host");
- return HTTP_FORBIDDEN;
- }
#endif
SSL_set_app_data2(ssl, r);
While this looks awfully more complex at first glance it actually just skips all these checks if a forward proxy request
was detected by mod_proxy. This covers "normal" forward proxy requests as well as CONNECT forward request.
Using the Host header to choose a name based virtual host on Apache side in case of a forward proxy request does not
make any sense at all. Hence a forward proxy virtual host should always be IP/Port based.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 17.12.2013 05:29, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand <ht...@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.
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 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.
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
http://tools.ietf.org/id/draft-luotonen-web-proxy-tunneling-01.txt
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
"mis-implementation"
(https://issues.apache.org/bugzilla/show_bug.cgi?id=54656#c3), 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.)
Kaspar
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand <ht...@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.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
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).
> or whether I'm
> instead responsible to identify user-agent by user-agent those which
> comply with RFC2817's examples.
I don't think that any remotely common browser is doing RFC2817-style
requests these days (neither is mod_ssl doing in client mode, when
proxying SSL requests). See also section 8.1 for the can of worms this
potentially opens up when "'http' [were used] to identify both secure
and non-secure resources").
> So how do you want to do this, or
> would you like to return to a discussion of ProxyPass in the forward
> proxy context?
ProxyPass is not involved in the SSL forward proxy case at all, as I
already tried to point out. Just unload mod_proxy_http and mod_ssl from
the configuration, and you'll find that forward proxying https://
requests continues to work perfectly, i.e. is completely unaffected by
any code in these two modules (mod_proxy_connect is all it takes).
Kaspar
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Sat, 14 Dec 2013 09:04:53 +0100
Kaspar Brand <ht...@velox.ch> wrote:
> I won't defend the checks introduced with r757373 under all
> circumstances, but they are definitely not the cause for this
> purported defect.
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, or whether I'm
instead responsible to identify user-agent by user-agent those which
comply with RFC2817's examples. So how do you want to do this, or
would you like to return to a discussion of ProxyPass in the forward
proxy context?
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
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
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 13 Dec 2013 07:05:13 +0100
Kaspar Brand <ht...@velox.ch> wrote:
> On 12.12.2013 20:06, William A. Rowe Jr. wrote:
> > On Thu, 12 Dec 2013 09:28:16 +0000
> > "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com> wrote:
> >> The reason is that you can define SSL parameters in Virtual hosts
> >> like SSLCiphers or SSLProtocols. If Host header and SNI host match
> >> you can be sure that the parameters that you set in the virtual
> >> host from which your request is being served have been used. If
> >> you allow a mismatch between SNI host and host header you might
> >> serve the request on a SSL connection that does not match your SSL
> >> parameters set up for the particular virtual host.
> >
> > Yes, and? Why would this differ from the historical handling of the
> > Host: header? The HTTP Host header is not the dns name of this hop,
> > but the hostname component of the uri. This logic has completely
> > broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
>
> "completely broken" is a relatively bold statement.
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.
> As far as I can
> tell, it essentially boils down to the interpretation of the "url"
> parameter in the ProxyPass directive ("a partial URL for the remote
> server", as the docs currently say).
As mentioned by several others, you seem quite confused on this thread.
ProxyPass is orthogonal to forward proxy configurations. Perhaps you
are mixing up my top post on this subject (of 25 Nov) with the PR 55782?
That report details reverse proxy misbehavior. 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.
> In my understanding, in the
> https:// case, it's a URL for which mod_proxy_http should perform TLS
> name checking (à la RFC 6125), not simply a hostname [plus port] for
> opening an TCP connection and then issuing a CONNECT request.
Thankfully, the user can toggle the SSLProxyCheckPeerCN behavior.
There is no toggle for the misguided AP 02032 error check behavior,
causing all forward proxy CONNECT requests to fail.
> (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.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 12.12.2013 20:06, William A. Rowe Jr. wrote:
> On Thu, 12 Dec 2013 09:28:16 +0000
> "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com> wrote:
>> The reason is that you can define SSL parameters in Virtual hosts
>> like SSLCiphers or SSLProtocols. If Host header and SNI host match
>> you can be sure that the parameters that you set in the virtual host
>> from which your request is being served have been used. If you allow
>> a mismatch between SNI host and host header you might serve the
>> request on a SSL connection that does not match your SSL parameters
>> set up for the particular virtual host.
>
> Yes, and? Why would this differ from the historical handling of the
> Host: header? The HTTP Host header is not the dns name of this hop,
> but the hostname component of the uri. This logic has completely
> broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
"completely broken" is a relatively bold statement. As far as I can
tell, it essentially boils down to the interpretation of the "url"
parameter in the ProxyPass directive ("a partial URL for the remote
server", as the docs currently say). In my understanding, in the
https:// case, it's a URL for which mod_proxy_http should perform TLS
name checking (à la RFC 6125), not simply a hostname [plus port] for
opening an TCP connection and then issuing a CONNECT request.
The SNI related changes to the [client] side of mod_ssl for 2.4 (and the
cherrypicked backport to 2.2.25) simply made it more obvious that the
expected effect of ProxyPass statements is probably underspecified when
it is used together with ProxyPreserveHost and/or SSLProxyCheckPeerCN
(with the default for the latter having been changed to On for 2.4).
One way to achieve the "treat the ProxyPass url as a TCP peer for
CONNECT requests" would be the combination outlined in [1], I think.
(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.)
Kaspar
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201204.mbox/%3C4F8E7873.8000004%40velox.ch%3E
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
William A. Rowe Jr. wrote:
> On Fri, 13 Dec 2013 10:46:43 +0100
> Ruediger Pluem <rp...@apache.org> wrote:
>
>> William A. Rowe Jr. wrote:
>>>
>>> Yes, and? Why would this differ from the historical handling of the
>>> Host: header? The HTTP Host header is not the dns name of this hop,
>>
>> It doesn't, but we clearly stated in the docs before: Don't use name
>> based virtual hosting with SSL for exactly this reasons.
>
> And the issue discussed in the top post has nothing to do with name
> based virtual hosting, the same problem persists in IP/port-based
> election of a forward proxy host.
>
>>> but the hostname component of the uri. This logic has completely
>>> broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
>>
>> How does this break forward proxies? Usually you connect to a forward
>> proxy via HTTP. How does SNI matter here?
>
> You are connecting to your proxy via https://, I hope. The current
No, I don't, but following the further discussion in the thread I get your point.
Personalized proxy credentials are a good reason to connect to the proxy via
https. I did not have this on my radar since I never used a proxy authentication
in practice.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 13 Dec 2013 10:46:43 +0100
Ruediger Pluem <rp...@apache.org> wrote:
> William A. Rowe Jr. wrote:
> >
> > Yes, and? Why would this differ from the historical handling of the
> > Host: header? The HTTP Host header is not the dns name of this hop,
>
> It doesn't, but we clearly stated in the docs before: Don't use name
> based virtual hosting with SSL for exactly this reasons.
And the issue discussed in the top post has nothing to do with name
based virtual hosting, the same problem persists in IP/port-based
election of a forward proxy host.
> > but the hostname component of the uri. This logic has completely
> > broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
>
> How does this break forward proxies? Usually you connect to a forward
> proxy via HTTP. How does SNI matter here?
You are connecting to your proxy via https://, I hope. The current
browsers are sending the dns name of the proxy via SNI (I have not
experimented with them all to determine what they do if you specify
an IP address as a proxy host - according to spec no SNI extension
should be sent - but that shouldn't be necessary to work around our
broken server). The client sends the hostname [+possibly the port]
of the requested http or httpd page or back-end CONNECT target as
the Host: header. And there we die.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Dec 14, 2013 at 9:02 AM, Kaspar Brand <ht...@velox.ch>wrote:
> On 13.12.2013 15:52, Yann Ylavic wrote:
> > I can't tell whether this applies to all the other SSL parameters though
> > (most -if not all?- seem to be handled the same way in ssl_hook_Access(),
> > but I didn't do an exhaustive search to tell the truth, and maybe it is
> not
> > feasible here for all).
>
> An analysis of some of these questions can be found here:
>
>
> https://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C484778CA.3020800%40velox.ch%3E
>
>
> https://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303%40velox.ch%3E
>
Thanks, very instructive links (and thread, with the "SNI in 2.2.x"one
too, leading to the commits).
Regards,
Yann.
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 13.12.2013 15:52, Yann Ylavic wrote:
> I can't tell whether this applies to all the other SSL parameters though
> (most -if not all?- seem to be handled the same way in ssl_hook_Access(),
> but I didn't do an exhaustive search to tell the truth, and maybe it is not
> feasible here for all).
An analysis of some of these questions can be found here:
https://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C484778CA.3020800%40velox.ch%3E
https://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3C48592955.2090303%40velox.ch%3E
Kaspar
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Dec 13, 2013 at 2:42 PM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:
>
>
>
>
> *Von:* Yann Ylavic [mailto:ylavic.dev@gmail.com]
> *Gesendet:* Freitag, 13. Dezember 2013 13:09
> *An:* httpd
> *Betreff:* Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
> requests
>
>
>
> Without SNI (in 2.2.x, I can't tell for 2.4), doesn't this lead to a
> (secure/full) renegotiation?
>
>
>
> IMHO no. This is the problem.
>
IM(even more)HO, the following 2.2.x code from ssl_hook_Access() does the
trick :
/*
* Override of SSLCipherSuite
*
* We provide two options here:
*
* o The paranoid and default approach where we force a renegotiation
when
* the cipher suite changed in _any_ way (which is straight-forward
but
* often forces renegotiations too often and is perhaps not what the
* user actually wanted).
*
* o The optimized and still secure way where we force a renegotiation
* only if the currently active cipher is no longer contained in the
* reconfigured/new cipher suite. Any other changes are not important
* because it's the servers choice to select a cipher from the ones
the
* client supports. So as long as the current cipher is still in the
new
* cipher suite we're happy. Because we can assume we would have
* selected it again even when other (better) ciphers exists now in
the
* new cipher suite. This approach is fine because the user explicitly
* has to enable this via ``SSLOptions +OptRenegotiate''. So we do no
* implicit optimizations.
*/
if (dc->szCipherSuite || (r->server != handshakeserver)) {
... renegotiate if the (whole) ciphercipher suite changed
(paranoïd) ...
... or if the handshaked cipher is not in r->server's cipher suite
(+OptRenegotiate) ...
}
I have seen the "Reconfigured cipher suite will force renegotiation" log
many times because of multiple SSL vhosts listening on the same IP:port (a
common configuration "mistake" without SNI, but which works, slowly...).
I can't tell whether this applies to all the other SSL parameters though
(most -if not all?- seem to be handled the same way in ssl_hook_Access(),
but I didn't do an exhaustive search to tell the truth, and maybe it is not
feasible here for all).
Regards,
Yann.
AW: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
Von: Yann Ylavic [mailto:ylavic.dev@gmail.com]
Gesendet: Freitag, 13. Dezember 2013 13:09
An: httpd
Betreff: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
On Fri, Dec 13, 2013 at 10:46 AM, Ruediger Pluem <rp...@apache.org>> wrote:
William A. Rowe Jr. wrote:>
> The SSL settings come from first the IP/port search, then the resolved
> SNI hostname's vhost, and finally from the corresponding Host: named
> vhost where applicable. Of course the Host: vhost config may override
> the SNI hostname vhost, that's the correct httpd behavior, just as
> changing SSL options within a <location > block overrides the vhost.
>
>
But these SSL options are not applied later. So if you have two virtual hosts:
NameVirtualHost someip:443
<virtualhost someip:443>
Servername strong
SSLCiphersuite something strong
</virtualhost>
<virtualhost someip:443>
Servername weak
SSLCiphersuite something weak
</virtualhost>
Then you would be able to connect to the strong virtual host with a weak cipher just by supplying 'weak' in SNI and
'strong' in the host header.
Without SNI (in 2.2.x, I can't tell for 2.4), doesn't this lead to a (secure/full) renegotiation?
IMHO no. This is the problem.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Dec 13, 2013 at 10:46 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
> William A. Rowe Jr. wrote:>
> > The SSL settings come from first the IP/port search, then the resolved
> > SNI hostname's vhost, and finally from the corresponding Host: named
> > vhost where applicable. Of course the Host: vhost config may override
> > the SNI hostname vhost, that's the correct httpd behavior, just as
> > changing SSL options within a <location > block overrides the vhost.
> >
> >
>
> But these SSL options are not applied later. So if you have two virtual
> hosts:
>
> NameVirtualHost someip:443
>
> <virtualhost someip:443>
> Servername strong
> SSLCiphersuite something strong
> </virtualhost>
>
> <virtualhost someip:443>
> Servername weak
> SSLCiphersuite something weak
> </virtualhost>
>
> Then you would be able to connect to the strong virtual host with a weak
> cipher just by supplying 'weak' in SNI and
> 'strong' in the host header.
>
Without SNI (in 2.2.x, I can't tell for 2.4), doesn't this lead to a
(secure/full) renegotiation?
With the configuration above, the client would first reach the "strong"
vhost (first in config) and then the "weak" one (when the Host: is read,
according to the "strong" SSL parameters), resulting in a renego.
Yes this is huge pain and expensive, but an administrator issue AFAICT.
Why would it be different with SNI?
Except that the client reaches "weak" first, couldn't a renego be issued if
finally it asks for "Host: strong"?
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Ruediger Pluem <rp...@apache.org>.
William A. Rowe Jr. wrote:
> On Thu, 12 Dec 2013 09:28:16 +0000
> "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Kaspar Brand [mailto:httpd-dev.2013@velox.ch]
>>> Sent: Donnerstag, 12. Dezember 2013 07:01
>>> To: dev@httpd.apache.org
>>> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
>>> requests
>>>
>>> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
>>>> 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.
>>>
>>> The logic in ssl_hook_ReadReq was added with r757373. It wasn't in
>>> the initial version of the patch for SNI support (r606190). I
>>> didn't find prior discussion of r757373 on the mailing list, but
>>> perhaps it was motivated by this statement in RFC 6066 (RFC 4366 at
>>> the time):
>>>
>>> If the server_name is
>>> established in the TLS session handshake, the client SHOULD NOT
>>> attempt to request a different server name at the application
>>> layer.
>>>
>>> I never really understood the reasoning for turning this into a
>>> "reject requests if the SNI extension and the Host header
>>> differ" (see e.g. [1],
>>
>> The reason is that you can define SSL parameters in Virtual hosts
>> like SSLCiphers or SSLProtocols. If Host header and SNI host match
>> you can be sure that the parameters that you set in the virtual host
>> from which your request is being served have been used. If you allow
>> a mismatch between SNI host and host header you might serve the
>> request on a SSL connection that does not match your SSL parameters
>> set up for the particular virtual host.
>
> Yes, and? Why would this differ from the historical handling of the
> Host: header? The HTTP Host header is not the dns name of this hop,
It doesn't, but we clearly stated in the docs before: Don't use name based virtual
hosting with SSL for exactly this reasons.
> but the hostname component of the uri. This logic has completely
> broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
How does this break forward proxies? Usually you connect to a forward proxy via HTTP.
How does SNI matter here?
>
> The SSL settings come from first the IP/port search, then the resolved
> SNI hostname's vhost, and finally from the corresponding Host: named
> vhost where applicable. Of course the Host: vhost config may override
> the SNI hostname vhost, that's the correct httpd behavior, just as
> changing SSL options within a <location > block overrides the vhost.
>
>
But these SSL options are not applied later. So if you have two virtual hosts:
NameVirtualHost someip:443
<virtualhost someip:443>
Servername strong
SSLCiphersuite something strong
</virtualhost>
<virtualhost someip:443>
Servername weak
SSLCiphersuite something weak
</virtualhost>
Then you would be able to connect to the strong virtual host with a weak cipher just by supplying 'weak' in SNI and
'strong' in the host header.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Thu, 12 Dec 2013 09:28:16 +0000
"Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com> wrote:
>
>
> > -----Original Message-----
> > From: Kaspar Brand [mailto:httpd-dev.2013@velox.ch]
> > Sent: Donnerstag, 12. Dezember 2013 07:01
> > To: dev@httpd.apache.org
> > Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
> > requests
> >
> > On 12.12.2013 00:15, William A. Rowe Jr. wrote:
> > > 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.
> >
> > The logic in ssl_hook_ReadReq was added with r757373. It wasn't in
> > the initial version of the patch for SNI support (r606190). I
> > didn't find prior discussion of r757373 on the mailing list, but
> > perhaps it was motivated by this statement in RFC 6066 (RFC 4366 at
> > the time):
> >
> > If the server_name is
> > established in the TLS session handshake, the client SHOULD NOT
> > attempt to request a different server name at the application
> > layer.
> >
> > I never really understood the reasoning for turning this into a
> > "reject requests if the SNI extension and the Host header
> > differ" (see e.g. [1],
>
> The reason is that you can define SSL parameters in Virtual hosts
> like SSLCiphers or SSLProtocols. If Host header and SNI host match
> you can be sure that the parameters that you set in the virtual host
> from which your request is being served have been used. If you allow
> a mismatch between SNI host and host header you might serve the
> request on a SSL connection that does not match your SSL parameters
> set up for the particular virtual host.
Yes, and? Why would this differ from the historical handling of the
Host: header? The HTTP Host header is not the dns name of this hop,
but the hostname component of the uri. This logic has completely
broken forward proxies in httpd on the 2.4 and 2.2.25 releases.
The SSL settings come from first the IP/port search, then the resolved
SNI hostname's vhost, and finally from the corresponding Host: named
vhost where applicable. Of course the Host: vhost config may override
the SNI hostname vhost, that's the correct httpd behavior, just as
changing SSL options within a <location > block overrides the vhost.
RE: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Original Message-----
> From: Kaspar Brand [mailto:httpd-dev.2013@velox.ch]
> Sent: Donnerstag, 12. Dezember 2013 07:01
> To: dev@httpd.apache.org
> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
>
> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
> > 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.
>
> The logic in ssl_hook_ReadReq was added with r757373. It wasn't in the
> initial version of the patch for SNI support (r606190). I didn't find
> prior discussion of r757373 on the mailing list, but perhaps it was
> motivated by this statement in RFC 6066 (RFC 4366 at the time):
>
> If the server_name is
> established in the TLS session handshake, the client SHOULD NOT
> attempt to request a different server name at the application layer.
>
> I never really understood the reasoning for turning this into a "reject
> requests if the SNI extension and the Host header differ" (see e.g. [1],
The reason is that you can define SSL parameters in Virtual hosts like SSLCiphers or SSLProtocols.
If Host header and SNI host match you can be sure that the parameters that you set in the virtual host from which
your request is being served have been used. If you allow a mismatch between SNI host and host header you might
serve the request on a SSL connection that does not match your SSL parameters set up for the particular virtual host.
Regards
Rüdiger
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Posted by Kaspar Brand <ht...@velox.ch>.
On 12.12.2013 00:15, William A. Rowe Jr. wrote:
> 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.
The logic in ssl_hook_ReadReq was added with r757373. It wasn't in the
initial version of the patch for SNI support (r606190). I didn't find
prior discussion of r757373 on the mailing list, but perhaps it was
motivated by this statement in RFC 6066 (RFC 4366 at the time):
If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.
I never really understood the reasoning for turning this into a "reject
requests if the SNI extension and the Host header differ" (see e.g. [1],
where I was becoming tired of things said in [2]). Also, I think that
SSLStrictSNIVHostCheck is a pretty unnecessary knob.
Kaspar
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/200903.mbox/%3C49D0EFF7.8030902%40velox.ch%3E
[2]
https://mail-archives.apache.org/mod_mbox/httpd-dev/200903.mbox/%3C49CE8500.5060505@apache.org%3E
Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy
CONNECT requests
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Thu, 12 Dec 2013 08:46:32 +0100
Peter Sylvester <pe...@edelweb.fr> wrote:
> > 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.
That doesn't doesn't as user agents won't proceed with a request
because they had not established trust, and the user agent then
rightfully ends this attempt with an error (or sufficiently painful
'ignore this error' action on the part of the user).
But again, the Host: field is not defined as the dns name of this
next-hop server, but the hostname component of the requested URI.
Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
requests
Posted by Peter Sylvester <pe...@edelweb.fr>.
On 12/12/2013 12:15 AM, William A. Rowe Jr. wrote:
> On Tue, 26 Nov 2013 09:47:44 +0100
> Yann Ylavic <yl...@gmail.com> wrote:
>
>> On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <yl...@gmail.com>
>> wrote:
>>
>>> On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
>>> <ht...@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