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.
Related
I am having a problem with HTTPS on my domain. fashiontex.co
Across all browsers on (Linux Desktop), it sometimes loads as https without the Not Secured Warning or
"Your connection is not private"
on chrome and its other variation on different browsers.
On, mobile IOS 14, Android, and others it is 100% not secured no matter the configuration.
For the records, I am using PossitiveSSL certificate which isn't free.
here is a snippet of the relevant ssl and virtual host config
Listen 443
<VirtualHost *:443>
ServerName example.co
ServerAlias www.example.co
ServerAdmin webmaster#example.co
DocumentRoot /var/www/example.co/public_html
....
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL
SSLHonorCipherOrder on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
SSLCACertificateFile /etc/pki/tls/certs/fashiontex.ca-bundle
</VirtaulHost>
For the SSLCipherSuite, I'm not going to exaggerate, I have used over 50 values searching the internet.
and on https://www.ssllabs.com/ssltest/analyze.html?d=fashiontex.co I have gotten ratings of A, B but still, it still doesn't work even after clearing the cache on both windows, iPhone, and ubuntu.
PS: Before writing this entire post, it was showing not secured, when I was done with the above, I refreshed and it showed without the warning and tried again 10 seconds later and it is the same problem of not secured one more time. Please what am I missing?
It turns out that it was truly the Layer 7 SSL Protection which was enabled that was interfering with requests because it intercepts https requests for DDoS protection.
Depending on your hosting provider, mine recommended switching protection to Sensor Mode unless I am been attacked frequently.
So now it works
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
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.
*
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.
We are using apache http server 2.2.29 and jboss 6.4.
We are using Mod proxy for communication between web server and jboss application server.
We are planning to disable TLSv1.0 in mod proxy configuration. After disabling tlsv1.0, the mod_proxy's ssl configuration looks like below.
SSLProxyEngine on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ALL:HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateFile /app/certificates/star_rpmi.cer
SSLCertificateKeyFile /app/certificates/rpmi.key
SSLProxyMachineCertificateFile /app/jboss.keystore
SSLProxyProtocol all -SSLv2 -SSLv3 -TLSv1
However, once we disable the tlsv1.0, the communication between mod proxy and jboss application server fails.
In apache's debug logs, we have found that the ciphers suits being negotiated is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
This cipher suit have been added in jboss application server configuration file as well. However, the connection is still failing.
What could be the reason behind this?