In a blog post dated August 6th, Google’s head of Webmaster Trends Analysis, Gary Illyes announced that effective immediately, Google rankings will favour sites serving content from an HTTPS address. This form of communication is encrypted between the server and the client, and so discourages snooping by those with malicious intentions:

For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

This all sounds pretty decent so far, right? Still, I’m not sure that it actually is a good thing, when you step back and look at the full picture. In the most positive light, it could be construed as an ineffective distraction to real security. In a more negative light, Google’s new tactic could be seen as strong-arming the Internet, to the detriment of low-income Internet properties.

What is HTTPS?

HTTP stands for HyperText Transfer Protocol, and is the vehicle by which the majority of what people think of as the Internet is delivered. If you look at the address bar for this website, you’ll see that the first few characters are http://. That tells the browser to use HTTP.

If the same traffic is encrypted, which means scrambled so as to be unreadable by anybody but the server and you, the first few characters will be “http*s*://.” The “s,” you see, is for “secure.”

It is fairly routine for your email, your bank and increasingly, your social networks to all be served up in this way. Encrypting your communications ensures some level of privacy from criminals, particularly encrypting the transmission of username/password challenges for logging in.

For the website in question, the price of admission to this secret world is what is known as an “SSL Certificate.” This is a set of secure data that only that server has, with which they encrypt the data they’ll be sharing with you. Basic SSL Certs with barebones support come in around $9 a year, which is a very affordable bar to entry for most Americans.

Now for the bad news

All of this sounds great, it really does. A more-secure website, especially one with usernames and logins, is a better one. But does that make one website a more authoritative voice or a better resource? Because that is what Google’s mission is supposed to be about, if we’re still concerned with that sort of thing.

Search is about content, not someone else’s priorities

If I wanted Google to make the decision for me where I “should” spend my time, as opposed to who has the content I’m looking for, I’d probably be asking for it. But that’s not why I use Google and that’s not why, as a publisher, I rely on Google’s rules to get my pages in front of your ocular tissues.

Where spam pages are concerned, Google is well within it’s mission to cull the herd. I don’t need to find myself in spam hell because I searched for a common term, nor do I want my site listed among the sleazy crop of Russian honey pots. But security is a personal matter about which I can make my own decisions.

Security is a state of mind

While we’re on the issue of the ambiguous term “security,” let’s keep in mind that, just because someone else can’t snoop your communications with a website, that in no way presupposes that visiting the site is “safe.” What’s to say the site itself isn’t doing dodgy things with your data? Google can’t guarantee that, nor should it try.

Wait. Google is talking secure communications, now?

Whether or not it was their fault; whether or not Google was pressured by the government to allow holes in their security that the NSA could snoop through, the fact remains that they did exactly that. To hear Google now carping about secure communications on the Internet is rich, to say the least.

Wait. SSL Certificates are secure, now?

Perhaps you recall, and perhaps you do not recall, the big security freak-out of a few months back? Heartbleed? Yeah, that whole thing. That’s when the world’s most affordable SSL Certificate system, OpenSSL, was found to have a gigantic hole in what was supposed to be it’s encryption.

No one with any knowledge of Internet security found it surprising that Heartbleed was discovered in the era of NSA snooping. It was exactly the kind of back-door intrusion loophole the NSA must have been employing. So now, Google wants us to trust certificates that they themselves helped undermine.

The “Google Tax”? $9 a year doesn’t sound like a lot to Middle Class America.

But any new cost of doing business matters, especially for those with lower incomes. And regardless of how much of a burden it is or is not, there is something counterproductive to the “free and open Internet” Google claims to want in requiring yet another fee to pay.

It seems to me that Google’s HTTPS plan is too disruptive in all the wrong ways, and not disruptive enough in the ways they would prefer it. I’m hoping this is another Google Wave-esque idea that goes the way of the dinosaur sooner rather than later.

There doesn’t seem to be a tech, a hacker or a tech-savvy food service employee out there who isn’t sounding the alarm about a threat called Heartbleed. I’ve been doing a lot of liveblogging of my discoveries re: various institutions and companies and their preparations for Heartbleed. But I’ve not yet had the opportunity to sit down and summarize what we know about the threat so my audience can understand it.

First and foremost, Heartbleed is not a virus, malware or spyware. It’s not a “bug” in the sense that we discuss various threats these days. Running McAfee on your system will not help. Instead, Heartbleed is a vulnerability in the fabric of what allows for confidential communications over the Internet. In other words, those websites you access with https:// in the address, rather than http:// When exploited, Heartbleed has the power to render visible the information that was supposed to be confidential, including usernames and passwords, confidential data and worst of all, the keys a given service uses to make all future communications secure.

Well, damn. That certainly sounds bad. And it is: Heartbleed attacks a form of communication that is nearly ubiquitous on the modern Internet where security is a concern.

But before you go to all the trouble of refreshing the potpourri and washing the doilies in the bomb shelter, let’s talk about what it can and cannot do, and how you can protect yourself without going broke on duct tape.

The Whole Internet is Not Busted

When a security vulnerability like this comes around, often people find themselves trapped between blase attitudes and hair-on-fire panic of their friends and neighbors. But to be clear: only websites that you browse using https:// are affected, and not all of them, either.

An example of an https:// website.

An example of an https:// website.

Any site you browse using http:// is the same as it ever was. What makes the difference between the https sites that are and are not affected? Well, let’s talk about that.

How Heartbleed works

The heart of the problem is something called Secure Sockets Layers (SSL), which creates encrypted “tunnels” of information between you and the service you are connecting too. When communicating through these tunnels, all information is scrambled in a way that is unreadable to a would-be snoop. Examples of SSL tunnels would include https sites, SSH shells, FTPS and the ubiquitous VPS connections many employees have to their employers’ systems.

Heartbleed is a vulnerability in one common Open Source implementation of SSL, called OpenSSL. In this implementation, there is a means for completely unauthenticated users – complete strangers on the Internet – to be able to read the information held on the memory of servers that deliver SSH content. Worse than simply seeing the actual confidential data you meant to hide, this new vulnerability provides the “keys to the kingdom,” allowing an attacker to see the username and password of a legitimate user and also the keys by which the server provides secure content. That means any further connections to that server using those keys will be compromised.

So, yeah. Its pretty damned serious, indeed. And because use of OpenSSL is so ubiquitous, the potential harm to the online community is pretty vast and staggering.

There’s Good News, Too

But there are many more sites that do not use the OpenSSL system to encrypt their data, and as of the time of this writing, those SSL systems remain unaffected by Heartbleed. In particular, your bank, PayPal and anyone dealing with PCI-compliant eCommerce (which should be just about everyone doing eCommerce, we hope) are all unaffected by Heartbleed.

There are many more encryption algorithms that are not related to OpenSSL and do not require any kind of patching or security fixes. And the fix for OpenSSL is also freely available; most credible services are already locking down their SSL connections. Therefore, even a site that is currently using OpenSSL isn’t any less secure by nature than any other.

What is the Solution?

Because the fix for OpenSSL’s Heartbleed bug, server admins are busily patching their systems and where necessary, reissuing keys for affected systems. And you can bet that OpenSSL’s next build will come with the patch already implemented.

However, once a server has been patched, the next step is to reissue keys and have users encrypt their passwords with those new keys. That’s why you may have gotten emails from stuff you do online recommending you reset your password.

Should I Just Start Resetting Passwords, Then?

No. First of all, while it’s always recommended that you update passwords on a regular basis and I’ve even given you a handy guide to creating secure ones, doing so en masse promises to create confusion. There’s no sense making the situation worse by forgetting new passwords or creating a bunch of duplicates.

But secondly and much more important in this case, resetting your password will only be effective after the SSL keys are regenerated. So if Company X is affected by Heartbleed – and hasn’t yet secured their servers – resetting your password changes nothing. And after they’ve secured their servers, they’re just going to ask you to change your password again, because that’s exactly what is required.

Your best bet if you’re concerned about your security online is ask, ask, ask. Find out if your bank or social network is affected by Heartbleed by asking them. Check your list of sites you frequent and find out what you should do about them.