Is it bad to redirect http to https?

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.

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.

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.

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 [email protected]
  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).

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.

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>

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.

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.

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.

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/
</VirtualHost>

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

</VirtualHost>