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. <wmr...@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 <pa...@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
