Google May Consider Giving A Boost To Encrypted Sites
from the a-good-move,-but-would-it-work? dept
Interesting report over at the WSJ noting that some at Google are considering if they should boost the search results for sites that are encrypted as an attempt to encourage more widespread use of encryption. I would be a bit surprised if the company did this, as Google always claims that it's focus is entirely on the quality of the content of sites, and delivering people to what they're looking for. While the search algorithms do take into account things like page load time, it seems like encryption status might not be seen as a real indicator of quality. Still, I hope that Google does seriously consider such a move, because it could (very quickly) drive many more sites to encrypt -- and, it would probably (finally) drive more services that refuse to make encryption work to figure it out. For example, almost no media sites will do full encryption because it would effectively break most ad networks. So, for most media properties, going full encryption automatically means taking a huge hit in ad revenue. The various ad networks could do things to fix this, but very few of them seem interested (actually, very few of them seem to even understand the issue). If Google were to make this change, then the pressure coming from media properties (many of whom live and die based on their Google rankings) to ad networks to figure this out, would hopefully be enough to create a real shift.Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: encryption, rankings, search results
Companies: google
Reader Comments
Subscribe: RSS
View by: Time | Thread
bad idea
[ link to this | view in chronology ]
Re: bad idea
still it seems like unlikely Google would do such a thing but they could do the same for torch and burn/ salt the earth policies, as that would help services re-establish elsewhere after burning the original to the ground.
[ link to this | view in chronology ]
Re: bad idea
I'm not familiar with that site, but even at a glance I can see it asks for a login with username, email and password. Many people reuse these for multiple sites. If they are compromised on the site with no sensitive data, they can be used to log into sites which do have such data.
You may argue that those people are fools and that the risk is still low, but the risk exists.
"Why should they carry the cost of an SSL cert when they have no logical need for it but if only to be penalized by Google otherwise?"
Depending on vendor, SSL certificates can be bought for around $50, or if you must use a major vendor like Thawte, $300 maximum. That's an annual charge, not monthly. If that's a business cost that can make or break them, their business has more problems than Google's decision.
They're free not to get one, of course. But, Google has to do what they believe is best for their business. If they believe that their customers want to see SSL sites returned first, that's what they'll do. If jsfiddle.net believe they are losing more than $300/year from this decision, they can justify the SSL cert quite easily. If not, they have many other ways to advertise their site than search rankings.
"As Heartbleed has proven, SSL is a tenuous solution at best and has neither earned nor deserves such credibility and trust."
So, rather than whining, why don't you offer a better solution that you prefer? What is your alternative suggestion?
[ link to this | view in chronology ]
Re: Re: bad idea
Make it opt-in?
I really like the idea of giving priority to encryption enabled sites but I can see there may be downsides so why not make it opt-in with one of those explanatory info graphics?
[ link to this | view in chronology ]
Re: Re: Re: bad idea
But, if Google decide to make this change, and make it mandatory, people will have to go further than the price of a cert to get any sympathy from me.
[ link to this | view in chronology ]
SSL is *not* just confidentiality
Every non-https page is vulnerable to being modified in flight by a MITM attack to inject malicious Javascript (or other exploits). It might seem far-fetched, but it has been reported that the NSA has done precisely that (it's a MITM variant of a "watering hole attack"). With https, the number of places which can do that kind of injection is limited.
So yeah, even plain static HTML sites with fully public information should be protected by SSL/TLS. Because then, you know the page came from a server authenticated by the certificate. And unless the bad guys invaded the server or somehow got a faked certificate (which can be detected with monitoring tools like Certificate Patrol or EFF's SSL Observatory), it's the original page, which should be devoid of injected malicious Javascript.
(See also: "upside-down-ternet".)
[ link to this | view in chronology ]
Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: SSL is *not* just confidentiality
Still, it does give much better guarantees for the authenticity of the content.
[ link to this | view in chronology ]
Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: SSL is *not* just confidentiality
And forcing a certificate authority to certify a bogus key is a non-starter; it's too easy to detect, and when detected it causes a huge shitstorm.
The point is not to have a perfect solution; the point is to put a roadblock against their attempts. There are many ways for them to get around these roadblocks, but the more effort they have to spend, the less sites they can compromise, and the greater the chance that some sites will slip through their fingers.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: SSL is *not* just confidentiality
Most browsers won't complain that the certificate comes from a different CA than it previously did, as long as the CA's are trusted.
Perhaps we need browsers to track the certificate's it has encountered. If a site suddenly starts using a cert from a different CA, issue a warning (unless the previously known cert has expired).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
That's all fine and good, but people routinely ignore those warnings as it is. We need a better solution, although I confess that I don't have one to offer -- only a couple of proto-ideas.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
Technically, the way it's supposed to work is that you obtain the initial root CA in a secure manner. This means that you should get those certificates in person from the source and that you have personally confirmed that the person handing you the cert is, in fact, who they say they are.
Obviously, this presents some logistical problems when you want to do things on a large scale. This is an incredibly difficult problem, and is the primary weakness of public key cryptography. Nobody has really come up with a better way yet.
Every crypto scheme has this problem of secure key exchange. Public key cryptography is much better at minimizing the problem than any other scheme to date. But it's imperfect.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
Yes, that's not the issue at all. The issue is "how do you know the public key you have is really from who you think it's from." This question is answered in one of two ways -- you've personally confirmed it in a secure fashion (making it a "trusted key", or someone else you trust confirms it and indicates so by signing it with their trusted key.
The "trust chain" is the chain of these signatures -- untrusted key A can become trusted because it was signed by key B, which was signed by key C, which was signed by key D (and so on). If you trust key D, then you're good and can consider key A trusted.
There's a few problems with this, but the problem I arises with people obtaining key D (the root CA) in an untrusted way -- such as being included in a default database that gets shipped with an OS or piece of software. This is what allows MITM attacks to happen. If key D is fraudulent, then you'll mistakenly trust all the keys signed by it, allowing the frauds to generate trusted keys that misrepresent themselves (as, say, belonging to your bank).
"can look at the root certificate on my computer and, say, visit the website on another computer in a different location and compare. If they don't match I can notice the difference and investigate."
You technically can. But do you? I'll bet not, as that would mean checking literally hundreds of keys on a regular basis.
"The certificate authority can also go online and check that various different locations and ISP's are giving the correct keys when they are looked up and take action if not."
They could, but none do, nor are they likely to start.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
I meant to say "but the problem I'm talking about arises"
My stupid fingers.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
Just the root key, from that point on the chain of trust can fall from there.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
and can't you just check a hand full of root certificates and then have a computer app or something check the rest of them through the ones that you checked or something? Can't root certificates also verify each other?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
Because keys get updated and replaced.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
...
such as being included in a default database that gets shipped with an OS or piece of software."
As I've stated, you can simply write an app to get the certs off the Internet from various different locations and compare them with each other and the certs on your computer.
I think the bigger issue is if the operating system CD is compromised then how do you know that it doesn't ship with a hidden rootkit trojan or that the operating system files haven't been tampered with somehow? Ideally the information on the installation disk should be digitally signed by the operating system manufacturer so that you can potentially check the files using a cert you've gone through some trouble ensuring was trustworthy (ie: by checking that Internet connections at various locations return the same keys). A deeper question is how do you even trust your hardware not to spy on you.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
"A deeper question is how do you even trust your hardware not to spy on you."
I don't, personally, just as I don't consider having a key signed by a CA Authority to be "trusted". I am admittedly a huge nerd, but I watch all the outgoing traffic from my network specifically to catch that sort of thing.
This fold back into the point you're making, and you're quite correct: huge nerds can regularly vet keys for an increased level of confidence (it will still not be 100%, but what is?) The bigger security problem is with people who don't know how, or don't want to bother, to do these things.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: SSL is *not* just confidentiality
It takes just one person using HTTPS Everywhere with the SSL Observatory enabled or similar to send the changed certificate to a third party.
It takes just one proven faked certificate to generate a huge outcry, which has in the past been enough to remove whole CAs from the trusted lists of all the major browsers.
This means that a compromised trusted CAs cannot be used for casual MITM of everyone. It will be used only for the most important targets, and even then there is a risk of losing that CA.
The whole point is not to make it impossible for them to MITM. The whole point is to make it *harder* for them to MITM, hard enough that abusing it becomes too costly for them.
[ link to this | view in chronology ]
Re: Re: SSL is *not* just confidentiality
(If you never generated a SSL certificate, the basic flow is as follows: generate private key -> generate CSR from the private key -> send CSR to certificate authority -> certificate authority returns a certificate -> put the private key and the certificate on your server. The private key never leaves your possession, the CSR and certificate both have only the corresponding public key, which as its name says is public.)
[ link to this | view in chronology ]
Re: Re: Re: SSL is *not* just confidentiality
[ link to this | view in chronology ]
Re: bad idea
[ link to this | view in chronology ]
Re: bad idea
"The various ad networks could do things to fix this, but very few of them seem interested (actually, very few of them seem to even understand the issue). If Google were to make this change, then the pressure coming from media properties (many of whom live and die based on their Google rankings) to ad networks to figure this out, would hopefully be enough to create a real shift."
On firefox if I visit https://www.techdirt.com I notice that the lock icon doesn't appear next to the URL on the left. If you click the exclamation mark it says the connection to this website is not fully secure because it contains unencrypted elements.
So I guess what he's trying to say is that if the ad networks support encryption then Techdirt would be able to fully encrypt everything and ensure a more secure experience. Otherwise certain elements in the website might fool a user into sending information to the wrong party if those elements are unvalidated.
But even then do you really trust a validated ad network? Heck, I've downloaded 'malware' or spyware or ad-aware or whatever they want to call it (programs that integrate ad bars and other stuff into your browser and operating system in a way that's intended to be difficult to remove and they try to fool the user into installing something they don't want) from validated sources where the setup files were digitally signed by the offending party and verified by my operating system (ie: the certs were valid). If the person digitally signing something is receiving information you don't want them to receive then even if your browser can validate that this person is who they claim to be does that really mean you want that person to potentially get your information (though at least in the case of a validated certificate the offending party faces less anonymity and that may discourage some bad behavior).
[ link to this | view in chronology ]
Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: Re: Re: Re: bad idea
So if techdirt works with ad networks even if all those ad networks have signed certs that your browser can verify they could potentially insert content in your browser that could do something you don't want it to (like track you in some way). The government might even be working with those ad networks maybe. Your browser will just smile and nod telling the user that all certificates are validated.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: bad idea
[ link to this | view in chronology ]
Re: bad idea
If its encrypted that makes it harder to illegally spy on me.
-Why should they carry the cost of an SSL cert when they have no logical need for it but if only to be penalized by Google otherwise?
You can get ssl certificates from many places for under $10/year, heck there is at least one CA that gives them away for free.
-As Heartbleed has proven, SSL is a tenuous solution at best and has neither earned nor deserves such credibility and trust.
Do you always throw out the baby with the bathwater?
[ link to this | view in chronology ]
Re: bad idea
[ link to this | view in chronology ]
With page load time, google is saying that they will promote pages which are optimised or delivered efficiently. Promoting pages which are encrypted is a similar deal.
[ link to this | view in chronology ]
Google already plays favorites
Although the search engine might have originally started out that way, it's no secret that Google now engages in outright censorship in order to appease Hollywood's copyright-enforcement brigade. Since Google is already actively manipulating search results, the principle of non-interference simply falls flat. Giving HTTPS sites an automatic bump would be a lot more "content agnostic" than Google's present policy of de-listing highly-popular sites that Hollywood doesn't like.
[ link to this | view in chronology ]
Google and Mike Masnick have now become my go-to source for comedy.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
What spin?
Care to elaborate on that a bit because I'm not seeing any "spin" in any direction on this article whatsoever.
[ link to this | view in chronology ]
Oh my, Google *is* pissed
It seems Google's "fuck you" to the NSA is not finished yet...
[ link to this | view in chronology ]
Re: Oh my, Google *is* pissed
Google believes they've bought Congress to the point of impunity...
Let's watch!
[ link to this | view in chronology ]
Re: Re: Oh my, Google *is* pissed
[ link to this | view in chronology ]
Re: Re: Re: Oh my, Google *is* pissed
I never registered an account here, but I assume members can upvote or downvote a comment, as on other sites.
[ link to this | view in chronology ]
Re: Re: Re: Re: Oh my, Google *is* pissed
I think the "insightful", "funny" and "report" votes are all independent of each other.
I'm not 100% sure of this, but I suspect this is true because I've seen comments that were hidden which also had the insightful or funny icons lit up also.
[ link to this | view in chronology ]
Re: Re: Re: Re: Oh my, Google *is* pissed
[ link to this | view in chronology ]
Makes sense
[ link to this | view in chronology ]