Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I just installed an SSL Certificate on my server. I use a web hosting panel called ZPanel that is an open source project.

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.


UPDATED ISSUE

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

enter image description here

share|improve this question
6  
[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 stripe.com/docs/api?lang=php#authentication –  codingoutloud Jan 28 at 20:06
3  
@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 at 20:42
3  
@BenCrowell, that's because a captive portal looks an awful lot like an sslstrip-style redirect attack (they're both man-in-the-middle request hijacks) so HSTS-aware browsers will block them both. –  Jeffrey Hantin Jan 29 at 3: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 at 18:44
3  
Jason; your update should be a new question, probably on Webmasters 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 at 20:09

11 Answers 11

up vote 219 down vote accepted

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.

share|improve this answer
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 at 2:00
7  
@jasondavis Only if you don't spend a few minutes to optimize it. –  Michael Hampton Jan 28 at 2:03
9  
"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 at 4:24
36  
@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 at 7: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 at 11:02

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.

share|improve this answer
    
SPDY is a good suggestion; there even appears to be a module adding SPDY support to Apache 2.x. –  Calrion Jan 28 at 2:25
13  
Using "//yourserver.com/some-uri" instead of "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 at 8:21
    
@MauganRa Unless, of course, it's a link from http article page to https login page, for example. –  Mołot Jan 28 at 11:01
3  
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). –  tampis Jan 28 at 16:31
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 at 18:13

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 to 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.

share|improve this answer
    
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 at 12:07
2  
@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: stackoverflow.com/questions/323200/… POST payloads are also protected, while also not vulnerable to logging and referrer headers. –  codingoutloud Jan 28 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 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 at 2:21
    
@Brilliand Fair point, but a weak point in security makes the entire thing weak. Always worth considering. –  Velox Jan 29 at 8:32

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:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 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"
</IfModule>

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).

share|improve this answer
    
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 at 6: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.

share|improve this answer

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/
  </IfModule>
</VirtualHost>
share|improve this answer

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 ;) )

Also: I'm not a big fan of encrypting pages like for example cooking recepies. Every single SSL handshake takes up time, bandwidth, cpu power and one major point: Entropy. Especially small vServers can't get hold of a lot of entropy because they don't have any physical hardware that could generate such.

That could get a major problem if you are for example getting DDOSed.

Anyway: Turn on SSL, its a good thing. The downsides are negligible.

share|improve this answer
    
Entropy doesn't get used up (at least if you're defending against Earth-based attackers rather than doing voodoo). 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 Jan 28 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 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.

share|improve this answer

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.

  • 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.

share|improve this answer

This isn't technically an answer to your original question, but if you use the Google Chrome extension HTTPSEverywhere (I'm sure there are similar extensions on other browsers), the extension automatically redirects sites with HTTP to the same site with HTTPS. I've been using it for awhile, and I haven't had any problems (except maybe slowdown, but I haven't tested that). HTTPSEverywhere can be changed by certain rules on the server side, but since I haven't done much in that area, I'm not sure of the exact details.

Going back to your actual question, if you use something like HTTPSEverywhere, there is even less incentive to use HTTP-only, although I imagine it's hard to set up correct rules for when you need them.

share|improve this answer

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.

share|improve this answer
    
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 Apr 19 at 10:26

protected by Tom O'Connor Jan 28 at 10:22

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.