httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Matěja <pa...@netsafe.cz>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 20 Feb 2014 19:03:43 GMT
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