I have an autoscaling application, which uses an ELB to terminate SSL, and forward 443 requests to http 80 on the instances.
This works fine, except that if I do a redirect within apache, it implicitly uses http rather than https.
for example, I have the following rewrite rule...
RewriteRule ^/v10/(.*) /v11/$1 [R]
If I do the following...
curl -v "https://[mydomain.com]/v10/somescript.js"
I get a 302 response like this...
Location: http://[mydomain.com]/v11/somescript.js
... which then breaks my application, as the browser won't load the script via http.
Of course this makes sense, since as far as apache is concerned, it is http. However aside from re-writing all my redirect rules, I'm wondering if there is some way to convince apache to implicitly generate https redirects, even though it isn't terminating the SSL?
Related
I have a web application running on Apache/Tomcat on a cloud with Linux (Digital Ocean). It had a domain name - example.com. I've encrypted both example.com and www.example.com using Let's Encrypt and now requests to https://example.com and to https://www.example.com work.
Then I wanted to redirect HTTP requests to HTTPS. But noticed that for some reason requests to http://example.com and to http://www.example.com do not work, and I'm not getting any response from my server. I tried to play with Apache configuration files of VirtualHost, but nothing worked for me so far.
Using tcpdump I see that I am receiving requests on port 80 on the server, but nothing happens except that.
What might be the reason for requests to HTTPS to work while requests to HTTP not to work?
Thanks.
Well, if someone else encounters this behavior - the reason for it was the firewall - port 443 (used by HTTPS) was open but port 80 (used for HTTP) was simply closed. Opening it solved it.
Apache 2.2.15 on RHELS 6.1
Using mod_pagespeed on a server behind https (implemented by the network's Reverse Proxy).
All html urls are written as "//server.example.com/path/to/file.css" (so, without the protocol specified).
Problem : using the default configuration, pagespeed rewrites the urls as "http://server.example.com/path/to/file.css"
I'm trying to figure out how to have it rewrite the urls as https (or leave it unspecified as //).
After reading the documentation, I tried using ModPagespeedMapOriginDomain like this
ModPagespeedMapOriginDomain http://localhost https://server.example.com
Also tried
ModPagespeedMapOriginDomain http://localhost //server.example.com
ModPagespeedMapOriginDomain localhost server.example.com
... To no avail. Urls keep being rewritten with "http://".
Question: how can I have pagespeed use https instead of http in its urls?
Full pagespeed config here, if needed
It turns out mod_pagespeed does not work with "protocol-relative" urls.
Still, the issue is bypassed if you enable trim_urls
ModPagespeedEnableFilters trim_urls
Be mindful of the potential risks (depending on your javascript codebase, ajax calls could break or produce unexpected html).
Adding this to your configuration might work:
ModPagespeedRespectXForwardedProto on
That works, if your reverse proxy forwards the X-Forwarded-Proto header in its requests.
That request header tells PageSpeed what the original protocol was that was used for the request at the loadbalancer, and thereby hands it all it needs to know to correctly rewrite urls.
I'm a bit out of my depth here and nothing I have found quite addresses my problem. Si any and all suggestions are most welcome.
I've got tomcat6 running on CentOS 6.5 hidden behind an apache server (v2.2.15) and I am using Apache's mod_proxy to expose the tomcat webapps, which are running on port 8080. The tomcat hosts one production application and several development applications. On the apache side, both a Drupal site and the aforementioned tomcat production application are on the same domain and, thanks to rewrite rules, all requests to this domain are changed to https. The development sites are reached via subdomains and do not get re-written as https requests.
For the most part, this arrangement works fine. But parts of the tomcat apps are AJAX (calling a Java Struts 1.2 backend). Most of those requests are handled OK. But a few AJAX requests result in redirects (i.e., forward.setRedirect(true)) and that redirect is http (I guess because the container itself is not secure). As a result, I run into cross site scripting issues. I imagine I can use CORS headers to avoid the problem. But that seems like a hack. Is there a relatively painless way I can use to have tomcat send redirects back as https without making tomcat handle ssl directly?
Cris
You could configure the RemoteIpValve in Tomcat:
Another feature of this valve is to replace the apparent scheme
(http/https) and server port with the scheme presented by a proxy or a
load balancer via a request header (e.g. "X-Forwarded-Proto").
To configure Apache to forward the original protocol in the X-Forwarded-Proto header, add a RequestHeader directive in your Apache config, e.g.:
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
...
Note that in Tomcat 7, there is also a RemoteIpFilter.
You don't need to do anything special. It already works. Make sure you set the "redirectPort" in server.xml to Apache's HTTPS port, usually 443, and add the following to your <security-constraint> sections for resources you want secured by HTTPS:
<user-data-constraint>
<description>HTTPS</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Late to the game here but others may find this-- we had a similar setup and issue where everything worked fine until the application started using ajax posts which did redirects for the response. The fix was to use mod_header in apache to rewrite redirects using "Header edit Location"
http://httpd.apache.org/docs/current/mod/mod_headers.html
Header edit Location ^http://www.example.com/ https://www.example.com/
This went unnoticed prior to the ajax redirects because the browser has no problem doing page level redirects to http (which apache would then redirect back to https). But the ajax cross-site prevention halts at the initial http missing out on that would then be redirected to https by a subsequent request.
I have Apache installed on my server and I need to redirect from http to https. The reason for this is our load balancer solution cannot hand https so requests come in on http and then we transfer them to https using the below lines in the httpd.conf file.
<VirtualHost 10.1.2.91:80>
Redirect 302 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>
This works fine for GET requests but POST requests will lose the parameters passed on the URL. What would be the easiest way to perform this redirect and maintain POST params?
I need to get from http://glad-test.com/GladQE/link.do to here https://glad-test.com/GladQE/link.do maintaining POST params
Thanks
Tom
You can try with the HTTP status code 307, a RFC compilant browser should repeat the post request.
Reference: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
In contrast to how 302 was historically implemented, the request
method is not allowed to be changed when reissuing the original
request. For instance, a POST request should be repeated using another
POST request.
To change from 302 to 307, do that:
<VirtualHost 10.1.2.91:80>
Redirect 307 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>
Standard Apache redirects will not be able to handle POST data as they work on the URL level. POST data is passed in the body of the request, which gets dropped if you do a standard redirect.
You have an option of either using a PHP script to transparently forward the POST request, or using a combination of Rewrite (mod_rewrite) and Proxy (mod_proxy) modules for Apache like follows:
RewriteEngine On
RewriteRule /proxy/(.*)$ http://www.example.com/$1 [P,L]
P flag passes the request to the Proxy module, so anything that comes to your site (via GET or POST doesn't matter) with a URL path starting with a /proxy/ will transparently be handled as a proxy redirect to http://www.example.com/.
For the reference:
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
http://httpd.apache.org/docs/current/mod/mod_proxy.html
Either your public facing website MUST use SSL to protect confidentiality or there is no sensitive data enver passing through it, and no possibility that your site will ever be used for a lauinchboard for sslstripping (there's a very good reason why Google serve up search results over HTTPS).
If you are not encrypting traffic between browser and your site then why are you trying to encrypt them between your load balancer and your webserver? If you do happen to have a SSL termination outside the load balancer (a very silly approach) then using HTTPS between the load balancer and the webserver is far from efficient. The question also implies lots of other security problems like session fixation/sniffing and SSLStripping vulnerabilities.
I'm trying to figure out how to properly setup apache redirect rules for back-end CherryPy server which implements websocket (done via ws4py module). The problem is that if you use rewrite engine or proxypass it strips off Upgrade header in redirected request and therefore CherryPy server complaints about it and fails at handshake step.
The scenario I have is the following. I have CherryPy server with ws4py module which setup WebSockets. It runs on localhost:9000. I want to have apache front-end which just redirect incoming request to back-end server (it does more than that, but for simplicity it should do just that).
The apache rule I have is simple
RewriteRule ^(/websocket(/.*)?)$ http://some_host:9000$1 [P,L]
so for all requests starting with /websocket it redirects them to back-end server running on port 9000. The P flag stands for Proxy, the L stops rewriting process (see http://borkweb.com/story/apache-rewrite-cheatsheet)
If client sends request with HTTP header Upgrade:websocket the apache engine (rewrite module) strips it off, which causes WebSocket handshake fails.
Is there are any way to fix rewrite rule to allow presence of Upgrade header?
Unfortunately, Apache doesn't have the capability to reverse proxy WebSocket connections yet (it absolutely should!). But there is a solution that allows web requests to be handled using Apache and WebSocket connections to be handled by something else. This solution involves using HAProxy as the front end to both apache and your WebSocket server.
Here are a couple of relevant links to get you started:
http://lheurt.blogspot.com/2011/12/reverse-proxy-nodejs-websockets-with.html
HAProxy + WebSocket Disconnection