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 17:28:26 GMT
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.

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.
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?
--
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