Discussion:
[Bug 55707] SSLProtocol directive seem to be ignored over different virtualhosts on the same ip+port
b***@apache.org
2015-06-11 21:04:33 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Charles Parker <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2016-03-03 13:22:42 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Christian Affolter <***@stepping-stone.ch> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@stepping-stone.c
| |h
--
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-01-13 09:10:35 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

nada <***@valgronda.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@valgronda.c
| |om
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-03-02 11:23:29 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Szőgyényi Gábor <***@freemail.hu> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@freemail.hu
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-04-03 16:03:11 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

***@xorax.info changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@xorax.info
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-05-16 12:10:45 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #2 from Charles Parker <***@gmail.com> ---
(In reply to Kaspar Brand from comment #1)
Confirmed. It's due to a current limitation in OpenSSL, actually - when we
use SSL_set_SSL_CTX() in the SNI callback in ssl_engine_kernel.c, OpenSSL
only switches the certificate, but not any of the other settings.
I have filed
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3183
This OpenSSL bug was marked as resolved on October 13, 2016. I don't see any
indication of which version(s) contain the fix, however.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-05-16 21:34:31 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #3 from Rainer Jung <***@kippdata.de> ---
The OpenSSL RT ticket was only closed as part of a mass update of old ticket.
From a mail to the OpenSSL dev list:

Here is the list of old RT tickets that we are closing. We sent email
to all of the originators, and it included the following text:

If you still think it is important for us to consider, please open an
issue on GitHub. Don't be shy! We are closing issues based purely
on the date, and the fact that despite several passes through our RT
tickets, we haven't closed them yet.

...

3183 SSL_set_SSL_CTX() should apply more settings from the SSL_CTX being
switched to
...

So this wasn't actually fixed, at least not at that time.

Regards,

Rainer
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-09-01 00:15:32 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Abir Ahmed <***@abirahmed.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #4 from Abir Ahmed <***@abirahmed.com> ---
Hey guys,

It's been a long time that it has been an issue. I am having the same trouble.

I contacted openssl git page and they said it's because how Apache handles
openssl.

I tried with both 1.0.2 and 1.1.0 and it's still not working.

Is there any workaround I can apply? It's pretty urgent.

Thank you
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-09-01 09:31:14 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #5 from nada <***@valgronda.com> ---
Just for the reference: here is the re-reported issue for OpenSSL on GitHub:
https://github.com/openssl/openssl/issues/4302
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-09-01 17:07:27 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Abir Ahmed <***@abirahmed.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW

--- Comment #6 from Abir Ahmed <***@abirahmed.com> ---
This is the issue where they replied. See their latest response.

Link: https://github.com/openssl/openssl/issues/4301
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2017-12-22 11:37:45 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Fabian Niepelt <***@mittwald.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@mittwald.de
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-09 05:06:53 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Mike Haller <***@webscale.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@webscale.com

--- Comment #7 from Mike Haller <***@webscale.com> ---
Created attachment 35848
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35848&action=edit
Reject connections not conforming to vhost SSLProtocol

This was developed and tested with 2.4.27 and in production with that
version. The patch was modified for 2.4.33 and lightly tested.

This checks the version of the connection against the SSLProtocol
configured for the virtual host that is matched based on the SNI.
Because the connection is initially made with the SSLProtocol configured
for the default host for the port, the default host must include all
protocols that will be supported by any virtual host.

This patch adds an additional return status of APR_EMISMATCH to the
init_vhost function so that the ssl_callback_ServerNameIndication
callback registered with OpenSSL can return fatal alert
SSL_AD_PROTOCOL_VERSION. This is intended to produce the same response
to the ClientHello as having an SSLProtocol specified that does not
include the version in question. Because the SNI callback is called
during the processing of the ClientHello and before a response is
produced, it seems to do exactly that.

Feedback is welcome.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-09 05:08:07 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Mike Haller <***@webscale.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-11 08:43:07 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #8 from Stefan Eissing <***@eissing.org> ---
Feedback on the patch:

Yes, this will work and prevent connections to a vhost with an SSL protocol
version that is not allowed there. However.

When I imagine being the user who typed a URL into my browser - and ran into
this behaviour - what would I be expected to do? Is there, in this setup, a way
to successfully connect to the vhost? I don't see it.

If we can agree that this is an undesirable situation, the only fix - besides
re-implementing mod_ssl and vhosts in a non 2.4.x compatible way - is that the
*server admin* gets an ERR/WARNING by a post config check in mod_ssl.

(Since we are talking about fixes in 2.4.x, WARNING is the only option unless
we introduce a "SSLVHostChecks strict" or some such.)

So, IMO, the patch is good, but not enough.

Feedback?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-11 14:45:12 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #9 from Mike Haller <***@webscale.com> ---
Thanks for looking Stefan.
Is there, in this setup, a way to successfully connect to the vhost?
The point of the patch is to prevent a successful connection to the vhost at
the TLS protocol layer. If that's not what you want and you instead wish to
produce a friendly error message for some versions, you can already configure
mod_ssl to accept all versions, and to publish the SSL_PROTOCOL env var, and
then use any number of ways (e.g. rewrite, setenvif) to produce an error page
if there is a version you do not wish to accept.
... the *server admin* gets an ERR/WARNING by a post config check in
mod_ssl.
From a user's perspective, they see behavior no different than if they attempt
to connect with a TLS version that is not specified in the default server's
SSLProtocol: a protocol version alert. Is the startup warning suggestion
because this patch changes the existing behavior that current configurations
will accept versions that are not allowed by a vhost's SSLProtocol?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-12 09:17:19 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #10 from Stefan Eissing <***@eissing.org> ---
I am fine with the patch. What I am after is: is a configuration that triggers
the patch not really a configuration error?

Simplified:
<vhost A>
SSLProtocol TLSv1.2
</vhost>

<vhost B>
SSLProtocol TLSv1.3
</vhost>

Is a client that speaks both TLSv1.2 and TLSv1.3 able to connect to vhost B at
all?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-12 14:16:53 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
Post by b***@apache.org
Is a client that speaks both TLSv1.2 and TLSv1.3 able to connect to vhost B
at all?
Yes. Such a client could speak to both.

The case I am solving is this:

<vhost A>
SSLProtocol +TLSV1 +TLSV1.1 +TLSV1.2
</vhost A>

<vhost B>
SSLProtocol +TLSV1.2
</vhost B>

This configuration allows for vhost B to accept only the newest protocol
implemented in 2.4.33.

It will function as expected if you write "SSLProtocol +TLSV1.1" for vhost B.
However, I would not consider that a useful configuration because I think that
the concept "minimum TLS version needed to connect to this host" is more
likely than arbitrarily specifying versions. For example, PCI DSS (the credit
card security standard) is requiring that TLSv1 and TLSv1.1 can no longer be
used to connect after June 30, 2018, but allows for any newer protocols
TLSv1.2, TLSv1.3, etc.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-12 14:22:29 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #12 from Stefan Eissing <***@eissing.org> ---

You are solving the puzzle by changing the puzzle. ;-)

Your example is valid and would be improved by the patch and work and no error
should be logged. Okay?

Do you agree that in *my* example:
<vhost A>
SSLProtocol TLSv1.2
</vhost>

<vhost B>
SSLProtocol TLSv1.3
</vhost>

the configuration is in error and the admin should at least be WARNED that a
connection to vhost B is not possible at all?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-04-12 17:17:03 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #13 from Mike Haller <***@webscale.com> ---
I made a mistake earlier in mentioning the default host. The default setting
appears to come from the root configuration ap_server_conf and not the default
server. The built-in default config is "all -SSLv3" which is why I state you
can connect to vhost B above. If your example is based on my mistake of
mentioning the default host, and we adapt it to:

SSLProtocol TLSv1.1
<vhost B>
SSLProtocol TLSv1.2
</vhost>

Then this *does* lead to the situation where vhost B cannot be connected to.
And it does make sense to have a warning there.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-05-07 11:44:59 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

nsg-apache-httpd-***@sophos.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |nsg-apache-httpd-maintenanc
| |***@sophos.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-05-28 07:55:35 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #14 from Dennis Clarke <***@blastwave.org> ---


Is testing possible with TLSv1.3 and Apache/2.4.33 (Unix) OpenSSL/1.1.1-pre6 ?

I see the following error if I attempt to use a new tls 1.3 cipher from
latest beta openssl :

AH00526: Syntax error on line 19 of /usr/local/www/conf/extra/httpd-ssl.conf:
SSLProtocol: Illegal protocol 'TLSv1.3'


# /usr/local/bin/openssl version
OpenSSL 1.1.1-pre6 (beta) 1 May 2018

# /usr/local/bin/openssl ciphers -V -tls1_3 -s
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any
Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any
Enc=AESGCM(128) Mac=AEAD


However I should be able to run tests?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-06-01 17:34:10 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #15 from Dennis Clarke <***@blastwave.org> ---
I am doing tests with TLSv1.3 on httpd-2.5-trunk per :

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

also :

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

Thus far everything seems to be working fine with the obvious exception
that no browser can connect to the site. Yet. May be a CipherSuite
issue wherein Mozilla FireFox ver 62.0a1 does support TLS1.3 and I have
tested this via https://tls13.crypto.mozilla.org/ which works fine and
offers TLS 1.3 (draft 28) which seems to offer TLS_AES_128_GCM_SHA256
as the cipher.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-11-21 03:04:03 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Dan McLaughlin <***@danshome.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@danshome.net
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-11-21 05:55:00 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #16 from Dan McLaughlin <***@danshome.net> ---
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-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-11-21 05:57:50 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

--- Comment #17 from Dan McLaughlin <***@danshome.net> ---
(In reply to Dan McLaughlin from comment #16)
Post by b***@apache.org
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.
...
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
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-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
b***@apache.org
2018-11-21 21:56:11 UTC
Permalink
https://bz.apache.org/bugzilla/show_bug.cgi?id=55707

Dan McLaughlin <***@danshome.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|2.4.6 |2.4.37
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-***@httpd.apache.org
For additional commands, e-mail: bugs-***@httpd.apache.org
Loading...