I just installed an SSL Certificate on my server.

It then set up a redirect for all traffic on my domain on Port 80 to redirect it to Port 443.

In other words, all my http://example.com traffic is now redirected to the appropriate https://example.com version of the page.

The redirect is done in my Apache Virtual Hosts file with something like this...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

My question is, are there any drawbacks to using SSL?

Since this is not a 301 Redirect, will I lose link juice/ranking in search engines by switching to https?

I appreciate the help. I have always wanted to set up SSL on a server, just for the practice of doing it, and I finally decided to do it tonight. It seems to be working well so far, but I am not sure if it's a good idea to use this on every page. My site is not eCommerce and doesn't handle sensitive data; it's mainly for looks and the thrill of installing it for learning.


Strangely Bing creates this screenshot from my site now that it is using HTTPS everywhere...

enter image description here

  • 53,795
  • 33
  • 135
  • 209
  • 2,658
  • 6
  • 25
  • 32
  • 14
    [WTF - I can't add answer (though seems I have enough rep).] My answer would (in part) be that __SOMETIMES IT IS BAD__. Consider passing a COOKIE or API Key in a GET over HTTP. If your site redirects HTTP requests to HTTPS requests, these calls would work, but the COOKIE or API Key would be transmitted in the clear - exposed. Some APIs turn HTTP off, a more robust approach - no HTTP at all so you can't even get it working unless you use HTTPS. Example: "All API requests must be made over HTTPS. Calls made over plain HTTP will fail" from https://stripe.com/docs/api?lang=php#authentication – codingoutloud Jan 28 '14 at 20:06
  • 9
    @codingoutloud - the alternative is that the *whole thing* happens over HTTP with no HTTPS at all. How is that any better? – Mark Henderson Jan 28 '14 at 20:42
  • 1
    I've seen sites that put up a site over http saying this site must be accessed over SSL and provide a linky with the https:// part – PsychoData Jan 28 '14 at 20:45
  • Google started doing this last year. This seems to have led to the following problem on the wifi network at the college where I work. You pop up a browser and type google.com in the URL bar. It redirects you to a login page where you're supposed to provide your credentials for using the wifi network. But this then leads to an error, apparently because the redirect is detected as some kind of attempt to subvert the ssl connection. I don't claim to understand the full technical analysis of this situation, but it is a real-world problem that has occurred because of redirecting http to https. – Ben Crowell Jan 28 '14 at 21:03
  • 1
    @codingoutloud if you don't have more than 10 reputation **in [sf]** you can't answer protected questions. – Braiam Jan 29 '14 at 01:40
  • 3
    @BenCrowell, that's because a [captive portal](http://en.wikipedia.org/wiki/Captive_portal) looks an awful lot like an [`sslstrip`](http://www.thoughtcrime.org/software/sslstrip/)-style redirect attack (they're both man-in-the-middle request hijacks) so [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)-aware browsers will block them both. – Jeffrey Hantin Jan 29 '14 at 03:17
  • 3
    be aware that using https means everything you include should also be https or it might not load - eg load jquery using `src="://example.com/jquery.js"` - note the lack of `http` or `https` so the browser loads the appropriate one. I had a nightmare trying to get some embedded Amazon stuff to load properly as the API (loaded via https) produced http links - meaning they didn't work properly until I found the undocumented parameter to toggle https links – Basic Jan 29 '14 at 18:44
  • 3
    Jason; your update should be a new question, probably on [webmasters.se] as it's unrelated (technically) to your original question. But it's probably that your style sheets are coming from an insecure domain. – Mark Henderson Jan 29 '14 at 20:09
  • 1
    This is an added comment on an old thread, but there's some misinformation here. If you follow the best practice of marking sensitive cookies (API keys, etc.) as `SECURE`, the browser *will not* send them to the server *unless* the request is made over SSL. This makes the first comment misleading and incorrect. If you have properly marked the cookie as `SECURE` when it is set (and, obviously, set it while in an SSL channel) then redirecting HTTP to HTTPS is perfectly safe. – David Hoelzer Nov 20 '15 at 13:21

11 Answers11


The [R] flag on its own is a 302 redirection (Moved Temporarily). If you really want people using the HTTPS version of your site (hint: you do), then you should be using [R=301] for a permanent redirect:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301 keeps all your google-fu and hard-earned pageranks intact. Make sure mod_rewrite is enabled:

a2enmod rewrite

To answer your exact question:

Is it bad to redirect http to https?

Hell no. It's very good.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • 3
    Thanks for the information, my boss is telling me the reason he only runs https on certain pages of his site, is that it uses a lot more server resources to run it on every page. Do you know anything about that or if that's true? – JasonDavis Jan 28 '14 at 02:00
  • Mark, doesn't the comments on the article that you linked to agree that you _do_ lose something in the redirect - just not _more_ than in a normal link (ie, if your page had a 'forward' link)? – Joe Jan 28 '14 at 02:03
  • 9
    @jasondavis Only if you don't spend a few minutes to [optimize it](https://insouciant.org/tech/ssl-performance-case-study/). – Michael Hampton Jan 28 '14 at 02:03
  • @jasondavis The overhead of encryption is unlikely to make much of a difference, especially now that the SSL negotiation is usually cached for a time. The advantage of encryption is that you're not letting the world see your data, passwords, etc. – Andy Jan 28 '14 at 02:44
  • 10
    *"it uses a lot more server resources to run it on every page."* Modern CPUs have encryption acceleration features that make SSL nearly free. Don't worry about overhead. – Adam Davis Jan 28 '14 at 04:24
  • 42
    @AdamDavis The crypto algorithm may be lightweight, but the handshake overhead still exists. Also, HTTPS prevents HTTP proxies from caching your content. In _most_ cases, the overhead of HTTPS is minimal and worthwhile, but be careful about over-generalizing. – 200_success Jan 28 '14 at 07:22
  • 6
    It kills shared caching, which is useful for some site's usage patterns, and often protects little (is it important that people can know you visited the site, but not the details of what you did? That's the only situation where SSL is useful). The main advantage of SSL on every resource isn't that you need to "secure" e.g. people looking at "about us", but that you can't slip up and fail to use it in a case where you should. – Jon Hanna Jan 28 '14 at 11:02
  • 1
    Upvote for the last line.. well said – major-mann Jan 28 '14 at 11:17
  • From a security perspective, it's actually a bad practice. There are tools like sslstrip that are specifically designed to take advantage of servers that create an http connection and redirect the victim to the malicious server, while the malicious server plays MitM with the victim and the real server. In this case, it doesn't matter if the malicious redirect is http or https because if it's https, it's a valid, secure connection to the malicious server, who creates their own valid, secure connection to the real server. – atk Jan 28 '14 at 13:34
  • 1
    If you *really* want people to use HTTPS, shouldn't you also set an HSTS header? – Nick T Jan 28 '14 at 23:45
  • @NickT - sure, but that's way outside the scope of the question. Anders covers that in his excellent answer below: http://serverfault.com/a/570353/7709 – Mark Henderson Jan 29 '14 at 00:24
  • 1
    @atk - Actually, SSLStrip is defeated by an existing bookmark that goes to an HTTPS page in the first place. It works by intercepting an HTTP connection first, and preventing it from ever going to HTTPS. A connection that starts out as HTTPS can only be defeated by a corrupt CA. – Brilliand Jan 29 '14 at 01:07
  • 1
    @Brilliand, you are correct about that, but that wasn't my point ;-). The original question is if it is ok to redirect from http to https, which is exactly what sslstrip was designed to exploit. – atk Jan 29 '14 at 02:29
  • 2
    +1 for the `Hell no. It's very good.` That was my immediate thought when I read the question title. – Code Maverick Jan 29 '14 at 16:26
  • @JonHanna : SSL has a huge advantage: it prevents selective blocking by places like China. Plaintext is routinely sniffed and your connection is automatically cut off when sensitive keywords go over the wire. With HTTPS, China needs to manually block the whole site, which they would generally be reluctant to do (collateral damage to the vast majority of non-sensitive things on your site). I would say things like news sites may find this useful. – ithisa Jan 29 '14 at 20:02
  • @user54609 one doesn't need to force SSL for that scenario, though. – Jon Hanna Jan 29 '14 at 21:11
  • @user54609 and the case you give is in the set of cases where I said SSL is useful. – Jon Hanna Jan 29 '14 at 21:12
  • I would say, as a person who have many *personal and tiny* websites getting autoblocked by the GFW (my friends and I are all in China but I host everything overseas (way cheaper, censorship cannot delete your stuff permanently)), that set of cases is close to "all websites". – ithisa Jan 29 '14 at 22:19
  • @200_success HTTPS isn't the real problem there, it's not using proper Cache-Control headers. HTTPS is fully cacheable when the appropriate headers are present; if they're absent it's assumed that the page is not cacheable. – Michael Hampton Jan 30 '14 at 03:33
  • @MichaelHampton I think he is referring to Squid intercepting caches at the ISP which saves bandwidth by intercepting HTTP entities and forcing a shared cache on its customers. I don't think those are popular outside of Australia (latency) or Chinese schools (more rigid censorship) though. – ithisa Jan 31 '14 at 17:28
  • @user54609 He didn't _mention_ an intercepting cache... – Michael Hampton Jan 31 '14 at 17:39
  • Why use `mod_rewrite` when you can use the simpler `Redirect permanent / https://domain.tld/` in the vhost for the domain's port 80 listener? – warren Apr 11 '16 at 18:53
  • why not `RewriteCond %{HTTPS} off` instead of matching on port number? – Janus Troelsen Jul 08 '16 at 11:30

Whilst I support the idea of SSL only sites, I would say one drawback is overheads depending on your site design. I mean for example if you are serving lots of individual images in img tags, this could cause your site to run a lot slower. I would advise anyone using SSL only servers to make sure they work on the following.

  1. Check the entire site for internal links and ensure they are all using HTTPS if you specific your own domain name in links, so you are not causing your own redirects.
  2. Update your <meta property="og:url" to using the https version of your domain.
  3. If you use <base href= again update to use HTTPS.
  4. Install SPDY protocol if possible
  5. Make sure to use CSS Image sprites where possible, to reduce numbers of request.
  6. Update your sitemaps to indicate https status, so spiders over time learn this change.
  7. Change Search Engine preferences like Google Webmaster Tools to prefer HTTPS
  8. Where possible off-load any stactic media to HTTPS CDN servers.

If the above is addressed, then I doubt you will have many issues.

  • 101
  • 3
  • 595
  • 3
  • 3
  • SPDY is a good suggestion; there even appears to be a module [adding SPDY support to Apache 2.x](https://code.google.com/p/mod-spdy/). – Calrion Jan 28 '14 at 02:25
  • 19
    Using "//yourserver.com/some-uri" instead of "http://yourserver.com/some-uri" resolves issue (1) because the browser will pick the appropriate schema (http or https) depending on the schema the page was loaded with. – MauganRa Jan 28 '14 at 08:21
  • 1
    @MauganRa Unless, of course, it's a link from http article page to https login page, for example. – Mołot Jan 28 '14 at 11:01
  • A question about the 8th point: One reason to use HTTPS only Servers is to protect the visitor's privacy. So I have to use a CDN which also respect it, right? For example, if I decide to use a HTTPS only server, I should not use [Google hosted libraries](https://developers.google.com/speed/libraries/devguide?hl=de). Do you think this reasoning is right? – Stephan Kulla Jan 28 '14 at 15:11
  • @tampis I don't see it as a privacy issue - Google Hosted Libraries or other public CDNs improve speed and caching, and they aren't provided any data about the site you are visiting (if your site includes jQuery from, for example, Google's CDN, google don't see the URL). Further, the use of jQuery itself or other libraries is not a privacy risk as they aren't incriminating in any way, users do not choose them and have no awareness of them, and the resources tend to be extremely common and provide a large number of use cases, so cannot be tied to specific functionality either. – Ada Jan 28 '14 at 16:05
  • 4
    Google sees the URL someone is visiting via the `Referer` header. For example this site uses jQuery from Google's CDN and my browser sends a request to Google every time I reload the site. Thereby a `Referer` header is also send to Google which is set to the URL of this site. So Google can track the sites I visit during the time my IP address does not change (and if I use a Google service during this time, Google can also connect this information with my Google account). – Stephan Kulla Jan 28 '14 at 16:31
  • I installed the Apache module for SPDY, it caused complete chaos on my server though as you have to disable mod_php anbd instead use fcgid I think it's called...anyways trying to use that handler for PHP was a no go for my site as it broke all my virtualhosts files – JasonDavis Jan 29 '14 at 18:10
  • 1
    For 1) I just did a search and replace in my MySQL database http to https...i'm using WordPress so it made it real easy to update hundreds of links – JasonDavis Jan 29 '14 at 18:13
  • @jasondavis For absolute links to your own site, you could also use the protocol-relative `://` prefix. (I.e. without the leading `http` or `https`.) Just in case you ever decide to change this back, or someone invents a new web protocol with a different scheme ;) – millimoose Jan 30 '14 at 03:36

I you've set up https then you should use it everywhere on the site. You will avoid the risk of mixed content issues and if you have the required tools in place, why not make the entire site secure?

Regarding redirection from http to https the answer is not that simple.

Redirecting will make it a lot easier for your users, they just type in whateversite.com and gets redirected to https.

But. What if the user is sometimes on an unsecure network (or is close to Troy Hunt and his Pineapple)? Then the user will request http://whateversite.com out of old habit. That is http. That can be compromised. The redirect could point to https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. To an ordinary user it would look quite legit. But the traffic can be intercepted.

So we have two competing requirements here: To be user friendly and be secure. Fortunately, there is a remedy called the HSTS header. With it you can enable the redirect. The browser will move over to the secure site, but thanks to the HSTS header also remember it. When the user types in whateversite.com sitting on that unsecure network, the browser will go to https right away, without jumping through the redirect over http. Unless you deal with very sensitive data, I think that's a fair tradeoff between security and usability for most sites. (When I recently set up an application handling medical records I went all https without a redirect). Unfortunately Internet Explorer has no support for HSTS (source), so if your target audience is mostly using IE and the data is sensitive you might want to disable redirects.

So if you're not targetting IE users, go ahead and use redirect, but enable the HSTS header as well.

Anders Abel
  • 569
  • 3
  • 7
  • More people need to pay attention to this as well. Another thing is that people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text. – Velox Jan 28 '14 at 12:07
  • 3
    @Velox - I don't think the implication of "people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text" is quite accurate. While there are some gotchas, GET query params don't travel in the clear during transport over HTTPS. See for example: http://stackoverflow.com/questions/323200/is-an-https-query-string-secure POST payloads are also protected, while also not vulnerable to logging and referrer headers. – codingoutloud Jan 28 '14 at 19:53
  • @codingoutloud That's my point. Over HTTPS they are encrypted, but in the initial request to the HTTP page they were not. – Velox Jan 28 '14 at 20:24
  • 1
    @Velox - If the whole site is redirecting to HTTPS, then it's unlikely that any GET parameters will get sent before HTTPS has kicked in (and everything will stay HTTPS after that point). There's still the one initial request where cookies will be sent, which can be remedied with HSTS... and a small attack window for SSLStrip, which could possibly be defeated by JavaScript, but that's an arms race of its own. – Brilliand Jan 29 '14 at 02:21
  • @Brilliand Fair point, but a weak point in security makes the entire thing weak. Always worth considering. – Velox Jan 29 '14 at 08:32
  • Thank you for bringing up the security implications, of which there are many to be aware. – joshperry May 04 '15 at 20:00
  • Getting your [HSTS settings preloaded](https://hstspreload.appspot.com/) is a further step that can be taken to address the issue of the very first request from a client possibly happening over HTTP. – Håkan Lindqvist Feb 24 '16 at 07:18

There's nothing wrong with this, and in fact it's best practice (for sites that should be served over a secure connection). In fact, what you're doing is pretty similar to the configuration I'm using:

  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1

# Insert virtual host here :)

The 301 status code indicates a permanent redirect, instructing capable clients to use the secure URL for future connections (e.g. update the bookmark).

If you'll only be serving the site over TLS/SSL, I'd recommend a further directive to enable HTTP Strict Transport Security (HSTS) in your secure virtual host:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"

This header instructs capable clients (most of them these days, I believe) that they should only use HTTPS with the provided domain (secure.example.com, in this case) for the next 1234 seconds. The ; includeSubdomains portion is optional and indicates that the directive applies not just to the current domain, but any under it (e.g. alpha.secure.example.com). Note that the HSTS header is only accepted by browsers when served over an SSL/TLS connection!

To test your server configuration against current best practice, a good free resource is Qualys' SSL Server Test service; I'd be aiming to score at least an A- (you can't get more than that with Apache 2.2 due to the lack of support for elliptic curve cryptography).

  • 570
  • 2
  • 11
  • I should add, sending the header `Strict-Transport-Security: max-age=0` will negate any previous directive; as always, this _must_ be sent over HTTPS to be accepted, but it's a handy way of cancelling things if you decide you also need to use HTTP on the domain. – Calrion Jan 28 '14 at 06:20

Wow ! redirect HTTP to HTTPS is a very good thing and i cannot see any drawbacks for that.

Just make sure your clients have the right CA to avoid non user-friendly warnings about certificate in browser.

In addition, the way you have setup Apache to redirect to HTTPS seems ok.

  • 13,280
  • 4
  • 36
  • 42

Is it bad to redirect http to https?

No, not at all. Actually, it is a good thing to do!

On redirects:

It could be more efficient, by completely eliminating the rewrites. Here's my config on a similar situation...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
Pothi Kalimuthu
  • 6,117
  • 2
  • 26
  • 38

HTTPS is not exactly foolproof. Of course, normally forcing HTTPS is a good thing. It prevents normal criminals from doing anything bad to your users.

But please remember to check you SSL Settings like the SSLCiphers setting. Disable things like RC4 crypto, the SSLv2 and SSLv3 protocol. Also, you should find out, whether the crypto-system libarys of your system support TLS1.2 (which is the thing you want to have ;) )

Turn on SSL, its a good thing.

  • 250
  • 1
  • 6
  • Entropy doesn't get used up ([at least if you're defending against Earth-based attackers](http://security.stackexchange.com/questions/89/feeding-dev-random-entropy-pool/7074#7074) rather than [doing voodoo](http://security.stackexchange.com/questions/2604/evaluating-the-entropy-gathering-in-a-prng/2605#2605)). Either you start with insufficient entropy, and you can't do anything that requires randomness, or you start with sufficient entropy, and you keep having sufficient entropy no matter how much randomness you generate. – Gilles 'SO- stop being evil' Jan 28 '14 at 11:23
  • Sorry, *what*? There are a number of operations on Linux that insist on hardware-derived strong entropy rather than PRNG-based probably-good-enough entropy, and those can indeed block if the pool depth is low. It is most certainly possible to start with sufficient entropy on a Linux system, but by overuse to drain the pool, causing some operations to block. – MadHatter Apr 19 '14 at 10:48

Personally I am all for the use of SSL to secure connections on the web, however I feel a point that all the other answers here have missed is that not every device and piece of software capable of an HTTP connection will be able to use SSL, thus I would consider providing some way for users to avoid it if it is not supported for them. It is also possible that people in some Countries where encryption tech is illegal will then not be allowed to access your site. I would consider adding an unencrypted landing page with a link to force the insecure version of the site but unless a user specifically selects such to do as you said and just forward them to the HTTPS version.

  • 53,795
  • 33
  • 135
  • 209
  • 346
  • 4
  • 13
  • A problem with solutions like having a plain HTTP landing page, even if properly separated, is that this page is left open to manipulation. Ie, there's no actual guarantee that the link for the HTTPS version of the site is delivered intact to visitors. – Håkan Lindqvist Feb 24 '16 at 07:27

Here are some of the broad brushstroke issues:

  • MITM/SSLSTRIP: This is a huge caveat. If you're going to serve your site over HTTPS, then disable HTTP on the site. Otherwise, you leave your users open to various man-in-the-middle attacks including SSLSTRIP, which will intercept requests and quietly serve them over HTTP, inserting their own malware script into the stream. If the user doesn't notice, then they'll think their session is secure when it actually isn't.

    • The issue with this, though, is that if your site is a public site and you just unceremoniously disable HTTP, you might lose a lot of visitors. It probably won't even occur to them to try HTTPS if the site won't load with HTTP.
  • If your site requires a secure login, then the entire user session should be secured. Don't authenticate over HTTPS, then redirect the user back to HTTP. If you do, again, you're leaving your users vulnerable to MITM attacks. The standard approach to authentication these days is to authenticate once, then pass an authentication token back and forth (in a cookie). But if you authenticate over HTTPS then redirect to HTTP then a man-in-the-middle can intercept that cookie and use the site as if they are your authenticated user, bypassing your security.

  • The "performance" issues with HTTPS are for all practical purposes limited to the handshake involved in creating a new connection. Do what you can to minimize the need for multiple HTTPS connections from a URL and you'll be miles ahead. And that's frankly true even if you're serving your content over HTTP. If you read up on SPDY, you'll realize that everything it does is oriented toward trying to serve all the content from a single URL over a single connection. Yes, using HTTPS affects caching. But how many web sites are just static, cacheable content these days, anyway? You're likely to get more bang for your buck using caching on your web server to minimize redundant database queries retrieving unchanged data over and over again, and preventing expensive code paths from executing more often than necessary.

Craig Tullis
  • 488
  • 3
  • 14
  • The thing you can do to actually address *sslstrip* is to use HSTS (preferrably [get your HSTS settings preloaded](https://hstspreload.appspot.com/)). Whether you accept requests over plain HTTP or not doesn't actually matter in this regard, a MITM can answer over plain HTTP (possibly proxying to your HTTPS site) even if you only accept HTTPS requests. – Håkan Lindqvist Feb 24 '16 at 07:10
  • @HåkanLindqvist I really earned a downvote from you? Did I give bad advice or good advice with regard to not authenticating over HTTPS then switching to HTTP for the rest of the session? Did I provide bad counsel with regard to HTTPS performance myths? Also, if the client initially attempts to connect using HTTPS, the MITM cannot intercept and respond without triggering an alert in the browser, because their cert won't match unless they have a stolen or successfully forged cert. On the other hand, if the site accepts an HTTP connection, interception is easier. Either way, HTTPS raises the bar. – Craig Tullis Feb 25 '16 at 01:40
  • ..and of course I agree wholeheartedly with using HSTS. – Craig Tullis Feb 25 '16 at 01:40
  • My problem with the answer is the first item in the list claiming to address sslstrip while it actually doesn't (speaking of myths). What I was trying to get at in my initial comment is that if you have an active MITM (which is what you need for sslstrip in the first place), the attacker can essentially be "the site" from the perspective of the client; it's the attacker that decides if they want to accept plain HTTP connections from the client, how your actual web server behaves in that regard doesn't affect what the attacker can or will do. – Håkan Lindqvist Feb 25 '16 at 07:44
  • @HåkanLindqvist Except that if the visitor is intentionally trying to connect with HTTPS, the attacker can't satisfy that request without throwing flags in the browser, unless they have managed to steal a server certificate or somehow successfully forge one, which they would have to do in order to switch the connection to HTTP. HTTPS *still* raises the bar. Of course if the visitor makes the initial connection attempt over HTTP, all bets are completely off. – Craig Tullis Feb 25 '16 at 15:41
  • Sure, if the client is using HTTPS from the beginning then the question as well as the first item (about sslstrip) in your answer are not applicable. I'm not sure that I understand the relevance of this argument, though. If you want to fix sslstrip you use HSTS (preferrably preloaded), then the client will know to never issue HTTP requests even if asked to do so, ie the "all bets are off" problem is solved. Disabling HTTP on the server doesn't have the same effect. – Håkan Lindqvist Feb 25 '16 at 17:24

It is very good to redirect to HTTPS, but I read it also depends on how you organize the redirecting.

Making a dedicated virtual host for redirecting the incoming HTTP requests to your HTTPS connection as suggested in this answer on security.stackexchange.com - sounds very smart and will close some additional security threats. A configuration in Apache would look something like this:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

  • 12,647
  • 4
  • 29
  • 41
  • 773
  • 9
  • 13

the only technical draw back to HTTPS over HTTP is that it is computationally more expensive to process HTTPS requests than plain HTTP

However given that most modern servers have high powered CPU's this impact is usually negligible unless you are at extremely high levels of traffic at which point you are more than likely using load balancers anyway

With the advent of protocols like SPDY which require SSL/TLS to work, this actually counteracts the aforementioned computational overhead by giving significant performance improvements with regards to multiple requests and getting assets to the client faster overall.

  • 4,233
  • 2
  • 21
  • 24
  • The issue with HTTPS performance is that establishing a new connection is more expensive because there are more round-trips involved and because asymmetrical encryption/decryption is a lot more expensive than symmetrical encryption/decryption. Once the connection handshake establishes a shared symmetrical encryption key, the ongoing overhead is virtually irrelevant (very small). If you read up on SPDY, you'll see that the goal of all the fancy stuff it does is essentially to serve all the content from a URL over a single connection, mitigating the connection handshake overhead. – Craig Tullis Apr 19 '14 at 10:26