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.
Related
I'm setting up a forward proxy on Apache 2.4, and I'm finding that every request for an HTTPS url results in a 400 response.
The apache error log shows:
[ssl:error] AH02032: Hostname my.example.net provided via SNI and hostname stanford.edu provided via HTTP are different
What could I be doing wrong? My config is as follows:
Listen 3443
<VirtualHost *:3443>
SSLEngine on
ProxyRequests on
ProxyVia off
<Proxy *>
Allow from all
</Proxy>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/my.example.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my.example.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/my.example.net/chain.pem
ErrorLog /var/log/httpd/myerr.log
</VirtualHost>
I've tried adding all of the following but to no effect:
SSLProxyEngine with both on and off
SSLProxyVerify none
AllowCONNECT 443
I test the proxy by running:
https_proxy='https://my.example.net:3443/' curl 'https://stanford.edu/'
My server my.example.net is running Apache 2.4 on CentOS 7
The curl command appears to be the issue: instead of using an https scheme for the https_proxy variable, use http (so that there is only one TLS connection, and it goes right through to the destination host):
https_proxy='http://my.example.net:3443/' curl 'https://stanford.edu/'
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 decided to post about my situation after many days of troubleshooting. I recently installed NextCloud as snap on Ubuntu 18.04 and everything worked fine. I did the port forwarding and used Let’s Encrypt (from snap commands) to create the certificates for NC.
Then I decided to install Collabora server on the same machine to use the office functionality. I used the official Collaboration guides for installation mentioned here. However, in this guide, it is assumed that NC is installed manually (not snap). According to guides, I had to install Apache (or any other proxy/web server) to proxy the traffic to whether NC or Collabora.
I think there is a problem with my proxy configuration or something wrong with SSL certificates. When both Apache and snap are running, I can get to Apache page and Collabora should be running, but cannot get to NC page.
I can go to (port 443) link below and get to the page (meaning Collabora is responding?)
https://collabora.domain.com/loleaflet/dist/admin/admin.html
But when accessing the NC domain, the browser says “Did Not Connect: Potential Security Issue” and complain that the certificates are not for that NC domain I am trying to connect but the certificate is for Collabora domain. If I stop the Apache and let Snap running, I can access the NC domain with no issues (except I need to set the ports to 443 and 80 again! Is this problematic?)
My Apache proxy config file (located under /etc/apache2/sites-available/) is as follows:
<VirtualHost *:444>
ServerName nextcloud.domain.com:444
ProxyPreserveHost On
ProxyPass / https://192.168.1.50/
ProxyPassReverse / https://192.168.1.50/
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/nextcloud.domain.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/nextcloud.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.domain.com/privkey.pem
</VirtualHost>
<VirtualHost *:443>
ServerName collabora.domain.com:443
# SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/collabora.domain.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/collabora.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/collabora.domain.com/privkey.pem
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-$
SSLHonorCipherOrder on
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode
# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On
# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet
# WOPI discovery URL
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery$
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery
# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon
# Admin Console websocket
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws
# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool
# Endpoint with information about availability of various features
ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
</VirtualHost>
To be honest, this is first time I am setting up proxy server that do not know how it works. Most of my config file is copied and think that is the issue :) If someone can have a look at it and guide me to the right direction, that would save me lots of headache and time.
I went through the same pain for a similar amount of time and eventaully got a simple solution.
The online instructions for docker here are correct except that they omit enabling proxy for websockets.
a2enmod proxy
a2enmod proxy_wstunnel
a2enmod proxy_http
a2enmod ssl
The only other change I had to make were to add --cap-add MKNOD to the docker start.
In Nextcloud I then only needed to add https://collab.example.com to the WAPI server address configuration after creating LetsEncrypt certs for my domain (obviously example.com is not my real domain).
Hope someone can point me in the right direction. I've been trying to get this to work for many hours :(
Scenario - I have a DMZ where I've set up the Apache server. I need to securely talk to the internal server where I have set up another Apache server which is reverse proxied again to a localhost app within the server.. So, basically..
outside world > internet (https://app1.com) > dmz (apache reverse proxy) > internal server (apache reverse proxy - https://app1prod.com) > (http) > localhost:8080
Now, in dmz, I can directly access https://app1prod.com without issues. But, I can't for the life of me get https://app1.com to work from dmz. I get a '503 service unavailable' message :( Here is my apache config in dmz..
<VirtualHost *:443>
ServerName app1.com
ProxyRequests off
SSLProxyCheckPeerName off
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off
LogLevel debug
SSLEngine on
SSLProxyEngine on
SSLCertificateFile "xxx/cert.crt"
SSLCertificateKeyFile "xxx/key.key"
SSLCertificateChainFile "xxx/certchain.crt"
ProxyPass / https://app1prod.com/
ProxyPassReverse / https://app1prod.com/
<Proxy *>
order deny,allow
Allow from all
</Proxy>
ProxyPreserveHost on
ProxyTimeout 1200
</VirtualHost>
On my httpd.conf, I have the following modules loaded in addition to the defaults..
mod_proxy.so
mod_proxy_connect.so
mod_proxy_http.so
mod_ssl
mod_rewrite.so
mod_socache_shmcb.so
mod_ssl.so
What am I doing wrong? Please help! Thanks a lot..
Try removing ProxyPreserveHost on.
With that directive enabled, the proxied requests will be send to server defined in ProxyPass directive, but the HTTP Host: header will be preserved from initial request. In your case, the requests sent by Apache to app1prod.com will have Host: app1.com header, and app1prod.com i not configured (probably deliberately) to respond to such request.
I want to proxy a website – let’s call it “APP” - through Apache 2.4 using two different reverse proxies with different host names (virtual hosts). Let’s call those proxies “Alfa” and “Beta”. I want Alfa to be the “public proxy” which will show the normal version of the website. The Beta proxy will limit public access to certain client IPs, but here I want to show – on top of each page of the website – some type of sensitive information. Let’s call those portions of sensitive information “SENS”.
Here’s my current apache config.
Listen 443
NameVirtualHost *:443
SSLStrictSNIVHostCheck off
## Virtual host for the Alfa Proxy
<VirtualHost *:443>
ServerName alfa.mysite.org
RewriteEngine On
<Location /app/>
ProxyPass http://x.x.x.x:8080/app/
ProxyPassReverse http://x.x.x.x:8080/app/
</Location>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile conf/alfa.crt
SSLCertificateKeyFile conf/alfa.key
</VirtualHost>
## Virtual host for the Beta Proxy
<VirtualHost *:443>
ServerName beta.mysite.org
RewriteEngine On
<Location /app/>
Require ip 192.168.0
ProxyPass http://x.x.x.x:8080/app/
ProxyPassReverse http://x.x.x.x:8080/app/
</Location>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile conf/beta.crt
SSLCertificateKeyFile conf/beta.key
</VirtualHost>
In order to show SENS only to the users of Beta, I need to programmatically detect which proxy requests come from. Now, I’ve looked into the use of Reverse Proxy Request Headers such as “X-Forwarded-Server”. Let’s say I define some kind of security filter in APP (e.g Spring Filter) that allows SENS to be rendered on page only if X-Forwarded-Server equals “beta.mysite.org”. This should work just fine.
But my question is this: Can I be sure not some kind of tampering with the proxy headers occur that would allow users of the alfa.mysite.org actually view the SENS-portions of my website?
If so, are there any other ways of doing this a “secure manner”.
Having two different versions of APP or deploying APP on two different containers is something I want to avoid here.
Any comments or suggestions are appreciated.
According to the Apache documentation, the x-forwarded-server header can be a comma separated list when multiple proxies are used. So I wouldn't consider it safe from a security point of view.
Under the assumption that your backend server is not directly access, you could try the following.
Set your own HTTP Header which value changes depending on which VirtualHost it passes.
You only have to check then for the existence of the header in the backend.
ServerName alfa.mysite.org
RewriteEngine On
<Location /app/>
#Set - The request header is set, replacing any previous header with this name
RequestHeader set MyCustomHeader "remote"
</Location>
ServerName beta.mysite.org
RewriteEngine On
<Location /app/>
Require ip 192.168.0
#The request header is set, replacing any previous header with this name
RequestHeader set MyCustomHeader "local"
..
</Location>