Apache ProxyPass - Error during SSL Handshake with remote server - apache

Im using proxy pass to redirect http to https backend server (tomcat)
Error im getting is : Error during SSL Handshake with remote server
My Configuration :
<VirtualHost *:80>
ServerName mypersonal.server.com
ProxyRequests Off
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPass /publisher https://localhost:9443/publisher
ProxyPassReverse /publisher https://localhost:9443/publisher
</VirtualHost>
I'm trying to find a way to overcome the verification of SSL, but the following commands appears in grey in my config
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
Im using Server version: Apache/2.4.6 (CentOS)
Appreciate your assistance

Late to the party here, but somebody might find this useful.
Check your SSLProxyProtocol directive. If, for security purposes, you have disabled the protocol that your backend is using, then the handshake will fail.
For example, I was using SSLProxyProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 but had to relax it to SSLProxyProtocol all -SSLv2 -SSLv3 -TLSv1 because my backend is still using TLS v1.1.
EDIT in 2023: I just saw this was upvoted recently. If you're still having problems, also check your values for SSLProxyCipherSuite (see apache docs and values recommended by Mozilla)

Related

How to hide weak SSL behind a Proxy?

So im having the following Setup:
Weak TLS 1.0 Application <--> DMZ Reverse Proxy <--> The Client
The Apache-Vhost is configured like that:
HTTP:
<VirtualHost x.x.x.x:80>
ServerName weak.application.de
Redirect / https://weak.application.de/
</VirtualHost>
HTTPS:
<VirtualHost x.x.x.x:443>
ServerName weak.application.de:443
SSLEngine on
SSLCipherSuite AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
SSLCompression off
SSLCertificateFile /actual/cert/of/the/application
SSLCertificateKeyFile /actual/key/of/the/application
SSLCertificateChainFile /actual/intermediate_chain/of/the/application
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
ProxyRequests Off
ProxyPass / https://weak.application.de/
ProxyPassReverse / https://weak.application.de/
</VirtualHost>
And is working fine. But i just noticed the following:
When connecting using openssl s_client on the Proxy IP for this Application, i get connected with TLS 1.2, like intended
But when im accessing the same IP with my Browser, the Certificate Details tells me that im Connected using TLS 1.0 which is weak.
Is there a proper Way to hide the weak TLS behind the Proxy? Did i missed out something?
I would like to have something like this:
Weak Application <- TLS 1.0 -> DMZ Reverse Proxy <- TLS 1.2 -> The Client
i am using Apache/2.4.6 on Centos 7.8.
Thanks in advance
Cheers, Tomasz
I just figured out that this was some kind caching/session issue.
The config is correct, and after reloading httpd and using Private-Surfing i was able to connect with the weak server via proxy, but it looks like we are using TLS 1.2.
Since i am sending Requests to the Server using the Proxy IP as Hostname, i additionally had to add the following lines in order to prevent Server Errors:
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
Simply because the Proxy IP is not a CN or SAN in the Certificate of the Weak Server. So there would be a mismatch. When going live, these Options should be removed.
I Hope this helps someone. Correct me if im Wrong.
Bye

Apache 2.4.37 with openssl 1.1.1: cannot perform post-handshake authentication

I updated apache to last version 2.4.37 and openssl to 1.1.1 and now, when client authenticates, I get this error only with Firefox 63, but not in Chrome:
[ssl:error] AH: verify client post handshake, referer: https://******/login
[ssl:error] AH10158: cannot perform post-handshake authentication, referer: https://******/login
[ssl:error]SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received
I used wireshark to try to find the problem, and I apreciate Firefox uses TLS 1.3, while Chrome uses TLS 1.2. In fact, if I set TLS max version in FF to TLS 1.2, it works fine.
I would like to get TLS 1.3 compatibility or, if it is not yet possible, to force, in my Apache configuration, the client always uses TLS 1.2, but I don't get it :(
This is my apache vhost config file:
[...]
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt
SSLCACertificateFile /etc/apache2/ssl/ca.pem
SSLVerifyDepth 3
SSLProtocol TLSv1.2
SSLHonorCipherOrder on
<Directory /var/www/html/>
Options -Indexes +FollowSymLinks -MultiViews
AllowOverride All
Order deny,allow
Allow from 10.55.12.0/24
Deny from all
</Directory>
<Files "login-ssl.php">
SSLVerifyClient optional
SSLOptions +StdEnvVars +StrictRequire
</Files>
[...]
Can someone help me, please?
Thanks.
Edited
I found the solution. SSLProtocol directive should be in /etc/apache2/mods-enabled/ssl.conf.
The problem is that Firefox doesn't support TLS 1.3 post-handshake authentication. I've reported this issue to Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1511989
I'm not suggesting a workaround or fix here; I'm merely telling others who come across this page (as it is high up for this error message in the search results) what the situation is and where to find the latest information as Firefox works to resolve this issue.
In case this helps other, for my reverse proxy test configuration with Apache HTTP 2.4.41 on Windows, I wanted to protect only the balancer-manager URI with client certificate authentication, that I had generated using OpenSSL with CA certs, server certs signed by CA and client cert signed by CA, imported the P12 in my browser.
For my other back end URLs (Spring Boot with AJP enabled and running same application on 2 different set of ports to test balancing via Apache HTTP) that were being proxied, configuration was to do not perform any client certificate authentication.
Accessing https://myhostname.com was working and hitting my back end
via balancer, returning the expected response.
Accessing https://myhostname.com/balancer-manager was expected to
prompt me for selecting client certificate that I imported earlier,
but gave this error on Chrome 80.0 ( and did not work for other
browsers as well).
Forbidden You don't have permission to access this resource.Reason:
Cannot perform Post-Handshake Authentication.
In Apache error log, it showed:
SSL Library Error: error:14268117:SSL
routines:SSL_verify_client_post_handshake:extension not received
In Apache access log, it showed:
GET /balancer-manager HTTP/1.1" 403 199
Non working configuration for Virtual host config in httpd.conf looked like:
<VirtualHost *:443>
ServerName myhostname.com
ServerAlias myhostname.com
SSLEngine on
SSLCipherSuite ALL:!EXP:!eNULL:!aNULL:!MD5:-LOW:-RC4:-SSLv2:+HIGH:+MEDIUM
#no certificate authentication required except balancer manager
SSLVerifyClient none
SSLVerifyDepth 5
SSLProtocol all -SSLv3
SSLCertificateFile "path/to/server/certificate"
SSLCertificateKeyFile "path/to/server/key"
SSLCACertificateFile "path/to/CA/certificate"
<Location "/balancer-manager">
SSLVerifyClient require
SetHandler balancer-manager
Require host myhostname.com
</Location>
<Proxy balancer://cluster>
BalancerMember ajp://localhost:9090/ loadfactor=25 timeout=1
BalancerMember ajp://localhost:9091/ loadfactor=75 timeout=1
ProxySet lbmethod=byrequests
</Proxy>
ProxyPreserveHost off
ProxyRequests Off
ProxyPass / balancer://cluster/ stickysession=JSESSIONID
ProxyPassReverse / balancer://cluster/ stickysession=JSESSIONID
</VirtualHost>
To fix the issue, change SSLProtocol directive to use:
SSLProtocol -all +TLSv1.2
See these links also
Enable TLS in Apache
TLS-1-2
I used TLS 1.2 for tests (TLS 1.1 also worked but recommended to use TLS 1.2 or higher version).
Note:The Apache version 2.4.38 or higher versions support TLS v1.3. You
must upgrade Apache packages before enabled TLS 1.3 in SSL settings.
*

Apache reverse proxy and Wicket CsrfPreventionRequestCycleListener

Since integrating CsrfPreventionRequestCycleListener into our Apache Wicket (7.6.0) application, we have a problem operating the application behind an Apache reverse proxy.
Our configuration terminates SSL at Apache, and the reverse proxy passes the requests via http to our Wildfly 10 application server. This allows us to offload TLS/SSL among other things.
But since adding the CsrfPreventionRequestCycleListener, we are seeing the following in the server.log file and connections are aborted:
[org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener]
(default task-12) Possible CSRF attack, request URL:
http://example.com/example/portal/wicket/page,
Origin: https://example.com, action: aborted with error
400 Origin does not correspond to request
The problematic Apache config:
<VirtualHost example.com:443>
ServerName example.com
LogLevel debug
SSLEngine On
SSLCertificateFile /var/example/example.com/signed.crt
SSLCertificateKeyFile /var/example/example.com/domain.key
SSLCACertificateFile /var/example/example.com/intermediate.pem
SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLOpenSSLConfCmd DHParameters "/usr/local/apache2/1024dhparams.pem"
SSLProxyEngine on
ProxyPass / http://localhost:8390/ timeout=600
ProxyPassReverse / http://localhost:8390/ timeout=600
ProxyPreserveHost On
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Credentials "true"
Header edit Location ^http(\:\/\/.*)$ https$1
We found a solution using http2 but would prefer one without http2 (for reasons, see in https://http2.pro/doc/Apache).
The working Apache configuration using http2
<VirtualHost example.com:443>
ServerName example.com
LogLevel debug
SSLEngine On
SSLCertificateFile /var/example/example.com/signed.crt
SSLCertificateKeyFile /var/example/example.com/domain.key
SSLCACertificateFile /var/example/example.com/intermediate.pem
SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLOpenSSLConfCmd DHParameters "/usr/local/apache2/1024dhparams.pem"
SSLProxyEngine On
ProxyPreserveHost On
# Settings for http2 communication
Protocols h2 http/1.1
ProxyPass / https://localhost:8754/ timeout=600
ProxyPassReverse / https://localhost:8754/ timeout=600
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Credentials "true"
# Header edit Location ^http(\:\/\/.*)$ https$1
</VirtualHost>
Can anyone help us create a valid apache reverse proxy configuration that works with the CsrfPreventionRequestCycleListener without the http2 module?
I think I had a similar issue here and solved it just now. I think you might have solved your issue by now but maybe anyone else is falling over this topic.
You might want to look into a network dump to verify the problem. For me, apache sent requests to the locally running service (your case to http://localhost:8754) while some request headers were still referring the public name https://example.com. This was detected as a security risk and the connection refused by the underlying service.
I made sure, that mod_headers was enabled in apache and added the line
RequestHeader edit Referer "https://example.com" "http://localhost:8754"
After that no more references to anything related to example.com was in my tcp dumps and the connection was opened successfully.
You might need to adopt according to your setup (maybe you need multiple headers corrected or something similar). I cannot try it out at the moment.

Apache 2.4 issue on proxypass balancing on two BalancerMember [Weblogic 12c]

I have an Apache 2.4.12 on a dedicated machine (RedHat 6.x) that must balance on another machine with two Weblogic Managed Servers (port: 9101 and 9102. Weblogic 12c on RedHat 6.x) where I have deployed the application "Pega".
I have implemented the configuration below on the Apache VirtualHost (myvirtualhost.conf) but if I have both BalancerMember active it doesn't work. If I comment one of the two BalancerMember it works fine.
Do you have any suggestion to fix it?
thanks in advance for your collaboration
<VirtualHost myvirtualhost:443>
SSLEngine on
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProtocol all -SSLv2
#Server certificate
SSLCertificateFile /opt/rh/httpd24/root/etc/httpd/ssl/xxx.cer
#chiave privata del server:
SSLCertificateKeyFile /opt/rh/httpd24/root/etc/httpd/ssl/xxx.key
#chain del certificato del server:
SSLCertificateChainFile /opt/rh/httpd24/root/etc/httpd/ssl/xxx.crt
#Certificate Authority (CA):
#SSLCACertificateFile /opt/rh/httpd24/root/etc/httpd/ssl/xxx.crt
################################
<Proxy balancer://mybalancing>
BalancerMember https://myweblogicserver:9101
BalancerMember https://myweblogicserver:9102
</Proxy>
ProxyRequests on
ProxyPreserveHost on
##########Disable URL ############
ProxyPass /myexcludedpath !
##################################
ProxyPass "/" "balancer://mybalancing/"
ProxyPassReverse "/" "balancer://mybalancing/"
</VirtualHost>
Edit:
Yes i set correctly parameters.
I reach the login page (both when it works and when it doesn't) but when it doesn't work, if i enter my credential, i see:
Status fail
Message There has been an issue; please consult your system administrator
Operator ID Unauthenticated or not available
Requestor ID No ID available
Timestamp Thu Feb 25 12:37:36 CET 2016
Engine Version PegaRULES 7.10 ML9 (coreAssemblyCached_719_730)
But if i comment one of the BalancerMember:
<Proxy balancer://mybalancing>
# BalancerMember https://myweblogicserver:9101
BalancerMember https://myweblogicserver:9102
</Proxy>
It works fine.
So i guess i miss something in the declaration of 'balancer' , or maybe i miss some directive..
Any suggestion would be really appreciated.
Thanks
EDIT2:
Yes the session replication works well between the two servers. I'm able to login using a direct URL to a server (actually a Node in a server, the machine is the same, what changes is the port : 9101 and 9102) and then switch the other server (other node) maintaining my current session..
I guess it's some directive of proxypass but its the first time i face it
To use the WebLogic Web Server plugins, these are the basic steps:
Download the .so file and copy to /etc/httpd/modules.
Create a file called /etc/httpd/conf.d/weblogic.conf with the following content:
LoadModule weblogic_module modules/mod_wl_24.so
<IfModule weblogic_module>
WebLogicCluster myweblogicserver:9101,myweblogicserver:9102
DebugConfigInfo ON
MatchExpression *
</IfModule>

Apache 2.4 SSL Config

I've got a question regarding ssl config for apache 2.4. I got the following ssl settings for my vhost. There are more than 1 Directory but the config is mostly the same, only IPs are different. If I active the the three commented lines the apache should check the requests against the cert and not just pass the request through, correct? I assume the apache breakts the encryption for all requests from the internet and re-encrypts again to pass the request on. Am I right? Is there a way to not break the encryption and just delegate the cert checks to the next system?
RequestHeader set ClientProtocol HTTPS
SSLEngine On
SSLProtocol ALL -SSLv2 -SSLv3
SSLProxyEngine On
SSLProxyProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH
SSLCertificateFile /path/to/file.crt
SSLCertificateKeyFile /path/to/file.key
<Directory /folder-name>
#SSLVerifyClient optional_no_ca
#SSLVerifyDepth 1
#SSLOptions +OptRenegotiate +ExportCertData
ProxyPass https://10.20.30.40:8443/
ProxyPassReverse https://10.20.30.40:8443/
</Directory>
Thanks for your help guys and regards. Sebastian
Yes, this Apache acting as a proxy terminates SSL. It then makes or reuses a pooled SSL connection to the backend.
There's no way to truly let the backend think it's handshaking with the client unless it accessed apache as a forward proxy using the mod_proxy_connect module.
Some application servers accept the body of the client certificate in a proprietary header, making that identity available in the backend server. But they are not actually authenticating it in the handshake like the proxy/apache has done.