I've read contradicting advice about forcing https connections in the following way:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

To me it seems this wouldn't allow anyone to pass a http request. Is there any disadvantage to this approach?

What security does adding


to the <directory /> part add? I know it will force Apache to bounce non-https requests but will they ever get through anyways?

Or in other words: What is the best way of implementing a https-only site, if not this?

We do not have an EV certificate, neither do we have a large user base. What we have is a series of survey sites where we want to make http impossible.

  • Be aware that REQUEST_URI does not include a query string, if one exists. If you go this route use another matching pattern.
    – Erica Kane
    Commented Jan 19, 2016 at 22:29
  • The biggest problem I have with using a Rewrite for setting up a SSL-only area of a server, is that it does not work when used with authentication. For example adding this to a ".htaccess" file and settup you Basic Authentication, does not work. The authentication happens BEFORE the user is redirected! The only way I have found to do it properly is to restrict the redirect to a HTTP virtualhost and the authentication to the HTTPS virtual host. You can do it together in the same virtual host, or even the same ".htaccess" file. Arrrggghhh....
    – anthony
    Commented Jan 24, 2018 at 6:23

3 Answers 3


What is the best way of implementing a https-only site, if not this?

Use a separate virtual server for the HTTP, not linked to any of the resources of the 'real' HTTPS site.

To ensure that modern browsers will refuse to use plain HTTP for your site in the future, use the Strict Transport Security header.


<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/

<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"
    ...site settings...

What does SSLRequireSSL add?

It can be useful to protect particular resources if you're in a virtualhost with SSLEngine optional, or in a piece of included config shared by both an HTTP and HTTPS virtualhost.

  • Oh hey bobince, you're here too, I know you from good answers on SO. Will this solution make a difference regarding the MITM problem, @sourcejedi mentioned? Commented Oct 19, 2012 at 11:52
  • Only partially - HTTP Strict Transport Security solves that problem but only when the browser supports it (IE doesn't yet), and when the browser has been to the site in question before so knows it has to use HTTPS.
    – bobince
    Commented Oct 19, 2012 at 12:04
  • Ok, just read the Wikipedia article too, I guess this is the best way then and the rest of the risk has to be solved differently, like the correct CipherSuits against BEAST, etc. Commented Oct 19, 2012 at 12:09
  • SSLEngine optional is for RFC 2817, i.e. it's never used (apart from print servers). This has nothing to do with HTTPS.
    – Bruno
    Commented Oct 19, 2012 at 15:01
  • Using a separate host for HTTP and HTTPS can help find bugs in the development process, but like turning off plain HTTP, it doesn't prevent MITM attacks. If the user tries the plain HTTP http://secure-only.example.com/ and there's a MITM, the request could still be intercepted.
    – Bruno
    Commented Oct 19, 2012 at 15:07

As I was saying in this answer on Webmasters.SE, the only general solution to this problem is to give your users the https:// address only and make sure that they expect to use that only. It is ultimately the responsibility of the user to check that they are using SSL/TLS, as they expect.

One way to try to enforce this automatically is to encourage the users to use a browser that supports HTTP Strict Transport Security (again, until all browsers support it, this requires user awareness).

Other forms of server-forced upgrades (including shutting down the plain HTTP port) will be vulnerable to MITM attacks. This being said:

  • Forced redirections from http:// to https:// will protect the user against eavesdropping passive attacks. It may also help raise awareness of the issue to the user (i.e. if they connect from a network they can trust, they'll get used to it, and may find it odd not to see https:// on other networks). For those reasons, it's worth doing anyway; you're at least mitigating the risk.
  • It would be ideal to get more sites into the pre-loaded HSTS list, so as not to be vulnerable, even on the first connection. However, when using HSTS, a connection on a trusted network once with that browser configuration should be sufficient to tell the browsers to keep using HTTPS for that site.

Once this is done, you still need to tell users not to ignore certificate warnings.

(It's always better to combine all this with secure cookies, if cookies are used.)

  • You can redirect the user from HTTP to HTTPS, then do the authentication. That way you can ensure they only authenticate using HTTPS, but the two have to be done by separate virtual hosts for it to work!
    – anthony
    Commented Jan 24, 2018 at 6:25

The http redirect is not as secure as simply denying access through http.

People who use the HTTP address will still be vulnerable to an active MITM. I can intercept the redirect to HTTPS, and modify it. I could keep them on HTTP, or I could redirect to my own HTTPS site (to match the "padlock" you show when I'm not intercepting). I can use a domain name that looks very much like your own, or some plausible alternative.

Admittedly, my attack would be easier for users to spot if you use an EV certificate. But if it was worth paying for an EV certificate, you probably have high security requirements and a large user base, so you should still be disabling the HTTP access in order to provide some defence in depth.

  • And how can I disable the HTTP access? Commented Oct 19, 2012 at 10:03
  • 3
    "People who use the HTTP address will still be vulnerable to an active MITM" That's also true if you deny http traffic on the server. Commented Oct 19, 2012 at 11:41
  • @markus-tharkun isn't that what adding SSLRequireSSL would do?
    – sourcejedi
    Commented Oct 19, 2012 at 14:11
  • @CodesInChaos Very good point. What I'm trying to say is there's a risk that people "learn" that the HTTP url works, and then keep on using it. (And it ends up in bookmarks, links, etc). If the HTTP url doesn't work, that won't happen. The assumption is it's unusual for a computer to suffer MITM over a long period. (Or at least that the opposite common enough to be worth defending against). It may be a weak argument, I don't know - but I'm sure I've seen it made, so it may answer the question "why would anyone choose to use this option".
    – sourcejedi
    Commented Oct 19, 2012 at 14:26
  • I don't catch your drift... SSLRequireSSL would tell Apache to bounce http requests, is that what I want? I don't know, wouldn't rewriting everything to https be the same protection as bouncing http requests? My main question is, what is the best way of allowing https only? Commented Oct 19, 2012 at 14:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .