Home / server / Questions / 477236
Accepted
peelman
Asked: 2013-02-10 14:09:08 +0800 CST

Apache: insecure request sent to secure port...want to redirect

  • 772

Preface

Firstly: A simply Port 80 -> Port 443 Rewrite WILL NOT fix this. In almost every previous question, mail thread, forum thread, etc., I have found this was the first ignorant response and was parroted several times.

Secondly: Yes I know you cannot serve HTTP and HTTPS traffic on the same port. This is not that.

Scenario:

Apache Server hosting multiple sites via port multiplication. Port 80 serves a public site. Port 443 serves the secure version of that site.

Ports 7443, 8443, and 9443 each serve separate SSL-Secured sites.

If a user mistypes the URL, or is given a link that isn't valid, say http://hostname.tld:7443, they are given the following ridiculous page:

Apache Bad Request error message

Instead of the server just redirecting them over to https://hostname.tld:7443.

My Question is, how in the name of Zeus's butthole can you modify Apache's behavior or this error message to redirect the user automagically?

Apache is obviously serving a non-https request (to display that error message) even though it is configured for HTTPS. It seems remarkably dumb to me to not just do the redirect by default, but I can understand why they went with the behavior they did, even if I don't agree with it. So my question is: can you change it? They are handling the error SOMEWHERE, and with Apache being the configuration cornucopia that it is, it stands to reason there is some directive somewhere to handle this behavior, but I have been unable to find it in several hours of tinkering so far.

Update:

I have attempted a variety of things including:

  • using ErrorDocument 400 directives to get to a CGI and a PHP script that just send Status 301 and Location headers. This results in a blank page. Using ErrorDocument 400 https://hostname.tld:7443 simply results in that link being displayed on the page.

  • Using almost every combination of mod_rewrite I or Google can come up with, including blanket statements that direct the site entirely; these never work. Literally, they do nothing. I'm surmising that Apache is kicking to the above error before even attempting to process the rewrite directives.

I can't use port-based redirects, because of the custom port use. I can't use script-based redirects because they never get served because of the http/https mismatch. I'm almost willing to chalk this up to a bug, or an unintended behavior, but somebody had the forethought to put a very custom error message in there, they didn't bother thinking that maybe you'd want to just cart to the URL they are already providing?

apache-2.2

2 Answers

  1. Best Answer

    I think this is probably a bug in how Apache 2.2 and lower handles this particular circumstance.

    It seems that on an SSL read 400 Bad Request error, Apache 2.2 doesn't return the HTTP response code or headers, only the HTTP response body. I test by telnetting to port 443 and sending:

    GET / HTTP/1.1

    The server immediately returns (for me):

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://server.tld/"><b>https://server.tld/</b></a></blockquote></p>
</body></html>

    Note the lack of an HTTP response code or any HTTP headers.

    When I do this to an Apache 2.4 server, I get:

    HTTP/1.1 400 Bad Request
Date: Sun, 10 Feb 2013 00:47:23 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0g
Content-Length: 462
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<hr>
<address>Apache/2.4.3 (Unix) OpenSSL/1.0.0g Server at server.tld Port 443</address>
</body></html>

    If I setup an ErrorDocument line like you did:

    ErrorDocument 400 https://server.tld/

    Then I get the HTML for a 302 redirect, but again, none of the headers. Without the 302 redirect response code and the Location: header, the browser won't redirect.

    Try upgrading to Apache 2.4 and see if it works. I've tested and confirmed with at least Apache 2.4.3, but I haven't gone through the effort of finding exactly when this was behavior was updated. I suspect that in the large amount of work they did preparing 2.4, they corrected the undesirable behavior as a side-effect.

    Relevant Apache httpd bugs:

    UPDATE

    You can force a buggy Apache to give you the behavior you want (the redirect) by having the script print out its headers (which will not be sent to the client), and then manually print out again the headers you want. Here's a basic Perl script that works under Apache 2.2.22:

    #!/usr/bin/perl

use strict;
use CGI;

my $q = CGI->new();

# this will cause Apache to handle the response properly, but is meaningless otherwise
print $q->redirect("https://localhost/");

# this actually performs the redirect
print "HTTP/1.1 302 Found\r\n";
print "Location: https://localhost/\r\n";
print "\r\n";

# you can do whatever you want here; this will be the HTML body

    You should be aware that there are other reasons a 400 may be generated besides just talking to an SSL port without SSL. The easy way to determine this is to look for the HTTPS environment variable. If it's set, then SSL was negotiated properly and something else is causing the 400 (don't do the double header trick if that's the case). If HTTPS is not set, return your redirect as above.

    • 7

  2. You can fix this with mod-rewrite. Set a rule to match anything. See this answer on Stackoverflow

    • -1