Acknowledgement sent
to Santiago Garcia Mantinan <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian Apache Maintainers <[email protected]>.
(Fri, 05 Feb 2016 15:42:06 GMT) (full text, mbox, link).
Package: apache2
Version: 2.4.10-10+deb8u4
Severity: normal
Tags: patch
Dear Maintainers,
After migrating from Wheezy to Jessie we found out that the connections from
the apache frontend to some https backends was broken. After investigating
this we found out that this was happening on virtualhosts with
ProxyPreserveHost set to On, which means, with a setup like this:
ProxyPreserveHost On
SSLProxyEngine on
SSLProxyCACertificateFile /etc/ssl/certs/ca-certificates.crt
SSLProxyCheckPeerCN on
SSLProxyCheckPeerName on
SSLProxyCheckPeerExpire on
SSLProxyVerify require
SSlProxyVerifyDepth 2
ProxyPass / https://internal.website.com/
These virtualhosts were working perfectly on apache 2.2 under wheezy but
stopped working under apache 2.4.10 on jessie (I have tested 2.4.18 with the
same results).
The problem is that when ProxyPreserveHost is On apache proxy sets the SSL
name to that of the original Host and thus it expects to find a certificate
with that name, not the one you specify on your proxy url, while the
backends really have their own certificate for their own name, thus it can't
verify the certificate and the connection is not done.
I have mailed about this to the httpd-users mailing list without any reply:
http://mail-archives.apache.org/mod_mbox/httpd-users/201511.mbox/%[email protected]%3E
Looking at the code changes in 2.4 I have found that the funcion
ap_proxy_determine_connection is the one that is now setting ssl_hostname
defined on mod_proxy.h as:
const char *ssl_hostname;/* Hostname (SNI) in use by SSL connection */
to the value of the original host request which to me is not what you want
when you are making a secure connection to another host, not even if you
have ProxyPreserveHost set.
These are patches to restore the old behaviour that we used to have on 2.2
both for stable and unstable versions:
--- apache2-2.4.10.orig/modules/proxy/proxy_util.c
+++ apache2-2.4.10/modules/proxy/proxy_util.c
@@ -2361,12 +2361,12 @@ ap_proxy_determine_connection(apr_pool_t
* backend request URI.
*/
dconf = ap_get_module_config(r->per_dir_config, &proxy_module);
- if (dconf->preserve_host) {
- ssl_hostname = r->hostname;
- }
- else {
+// if (dconf->preserve_host) {
+// ssl_hostname = r->hostname;
+// }
+// else {
ssl_hostname = conn->hostname;
- }
+// }
/*
* Close if a SNI is in use but this request requires no or
* a different one, or no SNI is in use but one is required.
--- apache2-2.4.18.orig/modules/proxy/proxy_util.c
+++ apache2-2.4.18/modules/proxy/proxy_util.c
@@ -2394,10 +2394,11 @@ ap_proxy_determine_connection(apr_pool_t
* backend request URI.
*/
dconf = ap_get_module_config(r->per_dir_config, &proxy_module);
- if (dconf->preserve_host) {
- ssl_hostname = r->hostname;
- }
- else if (conn->forward
+// if (dconf->preserve_host) {
+// ssl_hostname = r->hostname;
+// }
+// else
+ if (conn->forward
&& ((forward_info *)(conn->forward))->use_http_connect) {
ssl_hostname = ((forward_info *)conn->forward)->target_host;
}
I haven't found any Apache doc commenting anything on this behaviour change,
however I have found mails from people that have also found this problem and
that were disabling the ssl checks so that apache would make the connections
to the backend anyway, I consider this a bug and I think we should go back
to the old behaviour, if the old behaviour is no longer considered Ok by
apache I suggest that a new option is added to select weather we want the
new or the old behaviour.
If anything is not clear please ask.
Thanks in advance.
-- Package-specific info:
-- System Information:
Debian Release: 8.3
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages apache2 depends on:
ii apache2-bin 2.4.10-10+deb8u4
ii apache2-data 2.4.10-10+deb8u4
ii apache2-utils 2.4.10-10+deb8u4
ii dpkg 1.17.26
ii lsb-base 4.1+Debian13+nmu1
ii mime-support 3.58
ii perl 5.20.2-3+deb8u3
ii procps 2:3.3.9-9
Versions of packages apache2 recommends:
ii ssl-cert 1.0.35
Versions of packages apache2 suggests:
pn apache2-doc <none>
pn apache2-suexec-pristine | apache2-suexec-custom <none>
ii chromium [www-browser] 48.0.2564.82-1~deb8u1
ii google-chrome-stable [www-browser] 47.0.2526.111-1
ii iceweasel [www-browser] 38.6.0esr-1~deb8u1
ii links [www-browser] 2.8-2+b3
ii lynx-cur [www-browser] 2.8.9dev1-2+deb8u1
ii midori [www-browser] 0.5.11-ds1-2
ii w3m [www-browser] 0.5.3-19
Versions of packages apache2-bin depends on:
ii libapr1 1.5.1-3
ii libaprutil1 1.5.4-1
ii libaprutil1-dbd-sqlite3 1.5.4-1
ii libaprutil1-ldap 1.5.4-1
ii libc6 2.19-18+deb8u2
ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii liblua5.1-0 5.1.5-7.1
ii libpcre3 2:8.35-3.3+deb8u2
ii libssl1.0.0 1.0.1k-3+deb8u2
ii libxml2 2.9.1+dfsg1-5+deb8u1
ii perl 5.20.2-3+deb8u3
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages apache2-bin suggests:
pn apache2-doc <none>
pn apache2-suexec-pristine | apache2-suexec-custom <none>
ii chromium [www-browser] 48.0.2564.82-1~deb8u1
ii google-chrome-stable [www-browser] 47.0.2526.111-1
ii iceweasel [www-browser] 38.6.0esr-1~deb8u1
ii links [www-browser] 2.8-2+b3
ii lynx-cur [www-browser] 2.8.9dev1-2+deb8u1
ii midori [www-browser] 0.5.11-ds1-2
ii w3m [www-browser] 0.5.3-19
Versions of packages apache2 is related to:
ii apache2 2.4.10-10+deb8u4
ii apache2-bin 2.4.10-10+deb8u4
-- Configuration Files:
/etc/apache2/mods-available/http2.load e18e0c7e38196e7d7580ecedaaa72e3b [Errno 2] Non hai tal ficheiro ou directorio: u'/etc/apache2/mods-available/http2.load e18e0c7e38196e7d7580ecedaaa72e3b'
/etc/apache2/mods-available/proxy_html.conf 5b60af3b1796f2db4b5f7a8a7941f1bc [Errno 2] Non hai tal ficheiro ou directorio: u'/etc/apache2/mods-available/proxy_html.conf 5b60af3b1796f2db4b5f7a8a7941f1bc'
/etc/apache2/sites-available/000-default.conf changed [not included]
-- no debconf information
Acknowledgement sent
to Santiago Garcia Mantinan <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Apache Maintainers <[email protected]>.
(Wed, 16 Mar 2016 14:57:07 GMT) (full text, mbox, link).
After sending the patch I did more tests with different backend real servers
and found out that apache 2.4 as a server doesn't like to be asked for a SNI
hostname different than the hostname on the Host header and gives an error.
I've found a more complete patch available here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=54656
But the discussion seems to have ended there, for what I see, if you want
ProxyPreserveHost you must have the frontend certs available at the backend,
at least with apache backend servers, as that's how they are implementing
this, the Host header must match the certificate name.
Before SNI on apache you could have a backend server with its own
certificate serving a Host of another domain, but this is no longer allowed.
I really think they should think about this again, IMHO the backend server
should allow a mismatch if they are coming through a proxy or if a directive
tells it to do so, something like SSLStrictSNIVHostCheck but that relaxes
the check. Not allowing this will mean that people won't check or use
certificates from the frontend to the backend, which means lower security
:-(
Regards.
--
Manty/BestiaTester -> http://manty.net