httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 20 Feb 2014 23:52:51 GMT
Maybe what you need is a new ProxyPreserveHost on/off/canon option so
that mod_proxy uses the ServerName to fill in the Host header (hence
the SNI and the "proxy-request-hostname" note checked later by mod_ssl
against the CN).

I may be misguided but I see some relation between UseCanonicalName
and the SNI/CN checks.
How about using ap_get_server_name_for_url() wherever r->hostname is
used by mod_ssl and mod_proxy to check/provide SNI/CN?
By doing this we would allow administrators to configure what is to be
used, following UseCanonicalName rules, without opening Pandora's
door.

Thoughts?

On Thu, Feb 20, 2014 at 8:03 PM, Pavel Matěja <pavel@netsafe.cz> wrote:
> Dne 20.2.2014 19:18, Yann Ylavic napsal(a):
>
>> On Thu, Feb 20, 2014 at 6:28 PM, Pavel Matěja <pavel@netsafe.cz> wrote:
>>>
>>> Hi,
>>> you missed the possibility when client goes to numeric IP
>>> (https://1.2.3.4/)
>>> in reverse proxy configuration.
>>> In such case you don't have useable 1.a, 1.b, 2.b nor 2.c. so there
>>> should
>>> be 2.d. ServerName.
>>
>>
>> IMHO in this case you don't have any usable SNI, if the proxy isn't
>> requesting "Host: <ServerName>", it can't use it as SNI.
>>
>>>
>>> In 3. you have to check backend CN against proxy VirualServer's
>>> ServerName
>>> in such case because you don't have anything else and you want backend
>>> with
>>> valid certificate.
>>
>>
>> You have to check backend's CN against what was requested, or the
>> check is useless.
>> If this is an IP address, unless the CN is that IP (which obviously
>> won't be), it will fail.
>> Don't use SSLProxyCheckPeerCN when (possibly) forwarding IP addresses.
>
>
> We are supposed to
> a) verify backend certificate on proxy - we must have SSLProxyCheckPeerName
> On.
> b) do security scans on range of ips
> Right now Nessus gets just tons of 400 and 502s. That doesn't seem to be
> right.
>
>
>>> Currently there are two possible scenarios with SSLCheckProxyPeerName On
>>> and
>>> numeric Host/URI:
>>> 1) you will try to open new connection which will fail the CN check and
>>> client gets 502 Bad Gateway
>>> 2) you will try to reuse already opened connection which will get you 400
>>> Bad Request because SNI hostname won't match the numeric one.
>>>
>>> Is the https://1.2.3.4/ supposed to work on reverse proxy, isn't it?
>>
>>
>> For 1) it is, but not with SSLProxyCheckPeerCN (as said above).
>> Should the proxy ignore the check failure when an IP address is used?
>> I don't think so since the admin explicitly configured CheckPeerCN,
>> and it does not match.
>
>
> It's configured because admin has to be sure there is not forged certificate
> on backend. Client doesn't care about fact there is some backend server at
> all. It should be transparent to him. Even when he doesn't provide FQDN Host
> in request.
> I would go the 'ignore' way as well.
>
>
>> For 2) the issue is not related to IP addresses, reusing a SNI-ed
>> connection without checking the current hostname is a bug IMHO.
>>
>>
>>> --
>>> Pavel Mateja
>>>
>>> Dne 20.2.2014 17:03, Yann Ylavic napsal(a):
>>>
>>>> There seem to be different questions in this thread regarding SNI.
>>>> Maybe we can enumerate them first to see what's going on (at least I
>>>> need
>>>> to)
>>>>
>>>> 1. What should the client-provided SNI be checked against?
>>>> 1.1. for server or proxy-reverse
>>>> 1.2. for proxy-forward/CONNECT
>>>>
>>>> Possibilities are :
>>>> 1.a. Host: header
>>>> 1.b. Request-URI's hostname
>>>> 1.c. ServerName/ServerAlias(es)
>>>> 1.d. ap_get_server_name_for_url()
>>>> 1.e. none
>>>>
>>>> 2. What should the proxy-provided SNI be?
>>>> 2.1. when ProxyPreserveHost is off
>>>> 2.2. when ProxyPreserveHost is on
>>>>
>>>> Possibilities are :
>>>> 2.a. proxy worker's hostname
>>>> 2.b. r->hostname
>>>> 2.c. Host: header (being sent)
>>>>
>>>> 3. What should the backend's CN be checked against?
>>>>
>>>> 4. How should the proxy reuse SNI connections?
>>>>
>>>> Currently :
>>>> 1.1 => 1.b if any, otherwise 1.a
>>>> 1.2 => 1.e
>>>> 2.1 => 2.a
>>>> 2.2 => 2.b
>>>> 3 => the proxy-provided SNI (or wildcard match)
>>>> 4 => always
>>>>
>>>>
>>>> I propose to use the following instead :
>>>>
>>>> 1.1 => 1.d
>>>> So that the admin can configure UseCanonicalName to branch 1.b-a or 1.c.
>>>>
>>>> 1.2 => 1.b
>>>> It seems that the client-provided SNI is the requested backend (not
>>>> the proxy), although I may be wrong.
>>>>
>>>> 2.1 => 2.c
>>>> 2.2 => 2.c
>>>> Both should use the Host: header since this is what the backend will
>>>> check.
>>>> Either the Host: is legitimate and we can forward it, or it should be
>>>> denied by the proxy before forwarding (that's kind of hot potato sent
>>>> to the backend otherwise).
>>>>
>>>> 3 => the proxy-provided SNI (or wildcard match)
>>>> Same as currently, but now this is really what was requested, whatever
>>>> ProxyPreserveHost is.
>>>> The SubjectAltName(s) should be used too.
>>>>
>>>> 4 => compare reusable connection's hostname with 2.c (when conn->is_ssl
>>>> only)
>>>>
>>>> I may be missing something, there are probably other alternatives, but
>>>> by proceeding this way maybe we can address both security,
>>>> compatibility and avoid the need for configurable (explicit) hostnames
>>>> to check or forward.
>>>>
>>>> Moreover I think we should *not* have a different behaviour on 2.2 and
>>>> 2.4...
>>>>
>>>> Also, as Peter Sylvester said in this thread, there is no real
>>>> requirement in openssl about what's in the SNI.
>>>> The RFC-6066 forbids anything but FQDN, but is that RFC really adapted
>>>> to HTTP vhosting, for real HTTP cases the IP addresses and/or ports
>>>> matter.
>>>> By accepting/handling any client-SNI ("host/IP[:port]"), and using any
>>>> proxy-SNI (optionally, the backend could be strict RFC compliant), we
>>>> could allow full SNI to vhosts mapping, and maybe evolve the RFC...
>>>>
>>>> Regards,
>>>> Yann.
>>>>
>>>> PS: if this is too late for next 2.2 (and/or 2.4), I'm +1 to apply the
>>>> checks only when SSLStrictSNIVHostCheck is on.
>>>>
>>>>
>>>> On Thu, Feb 20, 2014 at 4:09 AM, William A. Rowe Jr. <wmrowe@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> I believe that Kaspar and Ruediger are still entirely at odds with my
>>>>> position, but this 'enhancement' should never have been unilaterally
>>>>> applied as it was to 2.2.26 and must be reverted (even as the feature
>>>>> is 'fixed' with corrections they have blessed), e.g. the comparison
>>>>> must be constrained to apply only to SSLStrictSNIVHostCheck enforcing
>>>>> hosts under 2.2 to not break existing configurations.
>>>>>
>>>>> It similarly aught to be constrained to SSLStrictSNIVHostCheck on the
>>>>> 2.4 branch, but I'm just not going to participate in that debate at
>>>>> all, which is why I say 'aught to'.  Time for a few more committers to
>>>>> review the relevant specs and chime in with opinions on productive vs.
>>>>> disruptive rules that are out-of-spec.
>>>>>
>>>>>
>>>>> On Wed, Feb 19, 2014 at 2:24 AM, Pavel Matěja <pavel@netsafe.cz>
wrote:
>>>>>>
>>>>>>
>>>>>> Dne Út 18. února 2014 10:16:15, Daniel Kahn Gillmor napsal(a):
>>>>>>
>>>>>>> On 02/18/2014 08:14 AM, Pavel Matěja wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> There is one big risk when someone uses reverse HTTPS proxy
with
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> ServerAlias.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>> Let say you have on both - backend and proxy servers options:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> ServerName www.example.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> ServerAlias example.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>> In old non-SNI days everything was working just fine.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>> Now when one client connects to proxy and requires www.example.com,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> connection is established to backend server with SNI hostname
set to
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> www.example.com. Second client connects to proxy and requires
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> example.com. Worker is matched because there is just one.
Connection
>>>>>>>> is
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> reused but you will get 4xx Bad Request because there is
mismatch
>>>>>>>> between
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> old and current SNI hostname.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> It seems like an administrator could avoid this risk by doing
>>>>>>> hostname
>>>>>>
>>>>>>
>>>>>>
>>>>>>> canonicalization via external redirect at the proxy itself. This
>>>>>>
>>>>>>
>>>>>>
>>>>>>> probably isn't a currently common practice, but for sites who
should
>>>>>>
>>>>>>
>>>>>>
>>>>>>> canonicalize their hostnames, i don't see it as particularly
onerous.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> The main concern would be for non-canonicalized hostnames. e.g.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> *.example.com, where each user of a service gets to set up
>>>>>>
>>>>>>
>>>>>>
>>>>>>> https://$USERNAME.example.com/. A proxy would need to pass this
>>>>>>
>>>>>>
>>>>>>
>>>>>>> information through to the origin server -- so in the scenario
you
>>>>>>
>>>>>>
>>>>>>
>>>>>>> describe, a reverse proxy could run into serious trouble.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> --dkg
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I know.
>>>>>>
>>>>>> We have two slightly different webs like foo.com and bar.eu which
>>>>>> shared
>>>>>> one
>>>>>> virtual server on reverse proxy. Backend server distinguishes between
>>>>>> them
>>>>>> by hostname in handler.
>>>>>>
>>>>>> I had to create two separate vitual servers on reverse proxy using
two
>>>>>> different fake hostnames for backend server with same ip to
>>>>>> distinguish
>>>>>> workers in ap_proxy_get_worker().
>>>>>>
>>>>>>
>>>>>>
>>>>>> Another workaround I know about is to downgrade proxy - backend
>>>>>> connection
>>>>>> to SSLv3 only.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Pavel Matěja
>>>>>>
>>>>>>
>>>
>

Mime
View raw message