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 #16 from Dan McLaughlin <dan@xxxxxxxxxxxx> ---
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.

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