Sophos Cloud Optix
Today Google announced that websites using HTTPS, the secure version of HTTP, will have a better chance of ranking well in Google searches than those that don’t.
In the vernacular, HTTPS is now a ranking signal for SEO (Search Engine Optimisation). It could be an inflection point for web security.
Security is a top priority ... 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.
By making HTTPS something that impacts search results Google are applying the stick to an enormous security push that’s been all carrots up to now.
Everywhere you look, from better SSL to the tricky business of end-to-end email security, Google are busy rolling out encryption or giving people ways to encrypt things.
Anyone who doubts the energy and seriousness that Google applies to this kind of thing or the effect that it can have need only wind the clock back five years.
In 2009, Google announced they wanted to make the web faster.
It wasn’t a soundbite, a speech, a project or a campaign – it was a sea change.
Since then Google has created, amongst many other things, a fast public DNS service, a faster web protocol, tools to speed up websites, tools to make code smaller, an image format to make images download faster and a global content distribution network for commonly used code.
They even built their own web browser with a very fast javascript engine and spent millions and millions of dollars banging on about how fast it was.
Most importantly of all they made speed a ranking signal for SEO.
Making speed a ranking signal punished slowness. It’s what made organisations care.
To understand why, you need to understand a little of how search engines work and how companies approach getting their websites noticed.
Google uses computer programs (referred to as spiders) to read the world’s web pages and index them. The spiders try to determine the subject and quality of each page by measuring a multitude of different factors, known as signals.
The strength of the signals determines where those pages will rank when somebody types a search into the Google search engine.
Good signals means high rankings, more traffic and more revenue. Poor signals can put you out of business.
There are hundreds of signals but they aren’t all equally important – some have far more impact than others. To prevent people from gaming their system Google is deliberately vague about how many signals it cares about, what they are and how much each one matters.
Thanks to a lot of research and some vague pronouncements from Google we have a pretty good idea of what some of the signals are and some idea of their weighting.
According to their blog, HTTPS will start off as a weak 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.
In reality, in my experience at least, even low strength signals get plenty of attention.
Because Google is cagey about what signals are worth, because organisations can’t easily test and isolate their website’s signals and because there is intense competition for good Google rankings those that care about SEO will generally act on any ranking factors that are well defined, regardless of how small their effect.
Companies like nothing better than lists with ticks next to them so if a ranking factor comes down to a simple yes or no choice it gets done.
Before Google made site speed a ranking factor I hardly ever had conversations with organisations about how fast their websites were. Now we always talk about it.
From now on they’ll have something else to talk about – a simple binary choice: “Does our website use HTTPS?”
Increasingly the answer will be yes.
The generall question is: why encrypt and authenticate everything. I mean, EVERYTHING. Sure, there is no doubt that sites that transmit sensitive data absolutely must use encryption in order to protect it. But: is it really necessary to encrypt information that is publicly available anyway, say, without a user having to sign in to a service in order to view it? As long as DNS requests are not encrypted and even with https network administrators are still able to see which domains you visit. And what’s worse: Google and Facebook with their tracking cookies still get the information, which exact URLs you visit each time one or their banners or scripts are invoked even when this site uses https. In my opinion, encryption does not always equal to more privacy. Encryption also means even increased traceability due to even more exchanged information such as supported encryption algorithms of the devices websites are accessed with. And this benefits the advertisers, and eventually, Google itself., it certanly helps in making your webbrowser more unique and therefore, you, yourself, traceable. Encryption is not the solution to the privacy problem. Encryption can make it much worse, once even client computers have to authenticate themselves.
One reason why it’s handy to encrypt everything is that then you don’t have to worry if you’ve left confidential stuff unencrypted 🙂
It’s the same reason why we recommend full disk encryption on your laptop, rather than just encryption of your home folder. Saves you worrying about stray TEMP files, stuff that gets saved into the wrong directory, or data leaked inadvertently in the swap file…
A good question, and probably worth separating out privacy and security to understand why this is potentially a good thing for both.
The stated objective is to improve security rather than privacy – two related but different concepts. Security of information assets is generally taken to mean the level confidence one has of the confidentiality, integrity and availability of such an asset, and perhaps authenticity and non-repudiation (deniability – “it wasn’t me’). Privacy may rely on some of these properties but doesn’t encompass all the objectives of information security. For example, disclosure of a prepay credit card’s details may not affect my privacy as it doesn’t uniquely identify me, but could certainly affect my ability to rely on funds being there when I need them.
First, it’s correct that encryption isn’t a panacea – it provides assurance of confidentiality and integrity, not availability – but it affords protection even when integrity alone, not confidentiality, is directly at issue. When someone requests publicly available information over HTTP, a suitably positioned attacker can inject malicious content e.g. a Java exploit, and potentially use this to then gain access to otherwise confidential information on the target machine and the other sites it authenticated to. The attacker could be on the same local network or somewhere further along the network route to the destination site; maybe they have set up a malicious wireless router offering ‘Free Wi-Fi’ expressly for this purpose.
With mandatory HTTPS, the attacker is limited to e.g. having already compromised one of the two ends of the conversation, or the SSL client or server be vulnerable to attack, or a trusted Certificate Authority be compromised or abused, or controlling some content that the site references etc. Although not a panacea, encryption reduces the opportunities an attacker has to succeed from an untrusted position (i.e. not being an intended party to the conversation or vendor of the security controls relied upon)
Regarding the use of SSL / TLS cipher selection for profiling, unless someone is actively customising their permitted cipher settings to make them more unique, the best that could likely be achieved is to determine browser platform in use and certainly have less impact on privacy than access to plaintext requests to public sites implies. DNS queries are more telling, but this is not an argument against HTTPS as it is a separate protocol, nor is DNS as revealing as the additional metadata available in a HTTP request such as full path, user agent and query strings.
I believe Google will positively influence the general security of internet use by making this announcement; not safe, but safer.
I can think of two reasons outside the obvious privacy benefits:
1. You get ranked better by google.
2. TLS is the underlying layer that allows SPDY, which makes a site load faster.
It just gets more and more difficult for organizations that are required by law to filter Internet traffic.
Good!
Filtering websites is a bad solution to the wrong problem. In most cases anyone who cares can get past filters anyway.
If this change leads to the repeal of laws and corporate policies requiring filters, then so much the better.
Well done Google! That’s a very clever move. This will make bulk collection of internet traffic inefficient and thus soon obsolete. A bad day for the NSA, their worst nightmare becoming true… (I think that this is Google’s revenge for having their internal network tapped hehe!)
<<>>
Hopefully this will the case also for links within the Sophos pages – which currently do not all land on https …