osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 55707] SSLProtocol directive seem to be ignored over different virtualhosts on the same ip+port


https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #17 from Dan McLaughlin <dan@xxxxxxxxxxxx> ---
(In reply to Dan McLaughlin from comment #16)
> Is this issue supposed to be fix?  
> 
> I'm trying to be as detailed as possible to help, so don't skim my comments
> or notes below or you might miss important information. First I'll explain
> how things are configure, then at the bottom I'll explain the behavior we
> see.
> 
> We have some third party clients that use our web service that have not
> upgraded their applications so we have to temporarily support TLS 1.0 for
> them.  We are limited to only a single IP address and port because of
> infrastructure outside of our control.  We do have two domains however that
> are registered in DNS that point to the same external IP address.  What we
> are attempting to do is use the two domain names we have registered to
> support upgrading all of our clients that support TLS 1.2 & 1.3 using
> www.domain-new.com, while still providing temporary support for clients that
> still only support TLS 1.0 using www.domain-old.com. 
> 
> NOTE: There are couple things that I'll mention that aren't detailed in my
> example, but I'm mentioning them just in case you think they could somehow
> affect things.
> 
> 1) <Location "/secure/myWebService">, <Location "/secure/AppA">, etc... are
> contexts that are hosted on our back-end application servers and are
> proxied/load balanced to the back-end Tomcat application servers using
> mod_jk.
> 
> 2) HAProxy sits in front of Apache load balancing a farm of Apache
> webservers. We use mod_remoteip and send-proxy-v2 so that we can log the
> actual client IP address in the Apache access logs instead of the HAProxy IP
> address.
> 
> The HAProxy config looks like this:
> 
> ...
> listen https_proxy 
> 	bind 144.192.168.2:443
>         mode tcp
>         option tcplog
> 	option ssl-hello-chk
>         balance roundrobin
>         server http01 144.192.168.5:443 check-send-proxy send-proxy-v2
>         server http02 144.192.168.6:443 check-send-proxy send-proxy-v2   
> 
> In each of our Virtual Hosts we configure mod_remoteip send-proxy-v2 support
> using:
>     RemoteIPProxyProtocol On
>     RemoteIPTrustedProxy 144.192.168.2
> 
> 
> Here is the simplified version of what I'm running... 
> 
> Listen 144.192.168.5:443
> 
> <VirtualHost _default_:443>
>     
> #NOTE: I added _default_ only because I saw a comment earlier in this ticket
> #where it was stated that I had to have a default host configured that
> #supported all of the SSL protocols that I needed to support in all vhosts.
> #Adding this hasn't changed the behavior at all. Things behave the same
> #regardless, meaning if I remove the _default_ vhost I see no change in the
> #behavior I see. I'm leaving it here only to show I've tried it.
> 
>     DocumentRoot "/docroot"
>     RemoteIPProxyProtocol On
>     RemoteIPTrustedProxy 192.168.0.2
>     
>     SSLEngine on
>     SSLProtocol all
>     SSLCipherSuite DEFAULT
>     SSLStrictSNIVHostCheck on
>     SSLCertificateFile /certs/www.domain-new.com.server.crt.pem
>     SSLCertificateKeyFile /certs/www.domain-new.com.priv.key.pem
>     SSLCACertificateFile /trustedCAs/cacerts.crt.pem
>     SSLCARevocationFile /crls/ca-bundle.crl
>     SSLVerifyClient none
>     SSLVerifyDepth  10
> </VirtualHost>
> 
> <VirtualHost 144.192.168.5:443>
>     
> #NOTE: We need to Support TLSv1 for Legacy Web Service Clients ie. .NET 3.5,
> #JDK 6
> #The plan was to point all Legacy Clients that only support TLS 1.0 to
> #https://www.domain-old.com/secure/myWebService 
>     
>     ServerName www.domain-old.com
>     RemoteIPProxyProtocol On
>     RemoteIPTrustedProxy 192.168.0.2
>     DocumentRoot "/docroot"
>     
>     SSLEngine on
>     SSLProtocol TLSv1
>     SSLCipherSuite DEFAULT
>     SSLStrictSNIVHostCheck on
>     SSLCertificateFile /certs/www.domain-old.com.server.crt.pem
>     SSLCertificateKeyFile /certs/www.domain-old.com.priv.key.pem
>     SSLCACertificateFile /trustedCAs/cacerts.crt.pem
>     SSLCARevocationFile /crls/ca-bundle.crl
>     SSLVerifyClient none
>     SSLVerifyDepth  10
> 
>     # Because we only want to support TLS 1.0 for two customers we use
> mod_rewrite to rewrite anything that's not trying to hit
> /secure/myWebService to the virtual host for our primary domain where all of
> our applications are hosted on www.domain-new.com. Commenting this out makes
> no difference in the behavior we see. 
> 
>     RewriteEngine On
>     RewriteCond %{REQUEST_URI} !^/secure/myWebService.* [NC]
>     RewriteCond %{HTTP_HOST} www.\domain-old\.com$ [NC]
>     RewriteRule ^ https://www.domain-new.com%{REQUEST_URI} [L,R=301] 
> 
>     <Location "/secure/myWebService">
>       Require ip 143.33.44.43 201.23.45.3
>     </Location>
> </VirtualHost>
> 
> <VirtualHost 144.192.168.5:443>
> 
> #We need to support ONLY TLSv1.2 & TLSv1.3 for Newer Browsers and Web Service
> #Clients ie. Latest Browsers, .NET 4.6.2, JDK 7u131 or greater
> #The plan was to point all Newer Clients that support TLS 1.2 & 1.3 to
> #https://www.domain-new.com/secure/myWebService
> 
>     ServerName www.domain-new.com
>     RemoteIPProxyProtocol On
>     RemoteIPTrustedProxy 192.168.0.2
>     DocumentRoot "/docroot"
> 
>     SSLEngine on
>     SSLProtocol SSLProtocol TLSv1.2 TLSv1.3
>     SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
>     SSLStrictSNIVHostCheck on
>     SSLCertificateFile /certs/www.domain-new.com.server.crt.pem
>     SSLCertificateKeyFile /certs/www.domain-new.com.priv.key.pem
>     SSLCACertificateFile /trustedCAs/cacerts.crt.pem
>     SSLCARevocationFile /crls/ca-bundle.crl
>     SSLVerifyClient none
>     SSLVerifyDepth  10
> 
>     <Location "/secure/myWebService">
>       Require all granted
>     </Location>
> 
>     <Location "/secure/myWebService">
>       Require all granted
>     </Location>
> 
>     <Location "/secure/AppA">
>       Require all granted
>     </Location>
> 
>     <Location "/secure/AppB">
>       Require all granted
>     </Location>
> 
>    <Location "/secure/AppC">
>       Require all granted
>     </Location>
> 
>     <Location "/secure/AppD">
>       Require all granted
>     </Location>
> </VirtualHost>
> 
> What I was expecting is that if I hit
> https://www.domain-old.com/secure/myWebService that TLS 1.0 would be
> negotiated, and if I hit https://www.domain-new.com/secure/myWebService that
> TLS 1.3 or 1.2 would be negotiated.  That's not what happens. In the example
> above TLS 1.0 is what Chrome, FireFox, and Safari negotiate (all the latest
> versions), regardless if I connect to
> https://www.domain-old.com/secure/myWebService or
> https://www.domain-new.com/secure/myWebService.
> 
> In summary, what I'm seeing is that whatever the SSLProtocol is configured
> to in the first VirtualHost is the SSL protocol that is used for ALL
> VirtualHosts that share the same IP:Port.  If I change the order of the
> VirtualHosts, then the TLS version changes to whatever the first VirtualHost
> is. If don't change the order but instead change the SSLProtocol for
> www.domain-old.com VirtualHost to TLSv1.3 then all the VirtualHosts use
> TLSv1.3. 
> 
> Based on everything I've read in this ticket and the related OpenSSL tickets
> what I'm attempting to do should be working using the version of Apache and
> OpenSSL that I'm using, but its clearly not.  I'm running Apache/2.4.37
> (Win64) OpenSSL/1.1.1 mod_jk/1.2.46 VC15 from ApacheLounge on Windows 2008
> R2 SP1.  I'd much rather be running on this on Linux, but it's out of my
> control because of third-party integrations we have the require us to run on
> Windows.


All references to 192.168.0.2 above were a type, it was supposed to be
144.192.168.2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx