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