Traditionally we've published anonymous web sites on http (port 80). This is unencrypted, and the logic is we don't want to incur the overhead of encrypting and unencrypting what is essentially public information. This saves resources on both the server and the client browser. Authenticated or payment sites generally use https, which is encrypted and secure.
The reality today is that SSL encryption is no longer an expensive operation, and both the web servers and client browsers have more than enough horsepower to deal with it. Yes you can offload the SSL encryption off the web server to improve its performance, but I don't generally see the need for that.
There have been recent changes in the treatment of http web sites by Google. According to eWeek (www.eweek.com/cloud/google-chrome-browser-to-warn-users-of-sites-that-dont-use-https.html) Google is planning to start warning Chrome users that any http is "Non-secure". Google also stated that it is considering using a website's use of https as part of its ranking of sites. This means there will be an SEO advantage to having your site on https.
As a result of this, I've decided to re-publish my blog site on SSL. I followed my own steps at Changing the FQDN of a SharePoint site to republish http://blog.petercarson.ca to https://blog.petercarson.ca. I made sure to create the redirect site as well, so that I wouldn't lose my SEO page ranking by changing the URLs of all the pages.
When you've done all of this, it's important to validate that everything is working properly. It's not enough to just see that the http site redirects over. You need to validate that the deep URLs redirect properly, using a 301 permanent redirect. This is what Google and Bing need to see to bring your valuable page rank over to the new URLs.
You can see this below. I've used Fiddler to watch a browser session going to http://blog.petercarson.ca/Pages/Public-Website-Azure-Architecture.aspx. Of course SharePoint outsmarts me and makes this a relative link, so you won't see the redirect. You actually have to cut and paste the URL into the browser. You can see the results below. The 301 in the result is the important thing to see.
I've got another post planned to go deeper into the workings of custom redirects. We're planning an update to our Custom 404 product to deal with permanent redirects that I'll talk about here.