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.
Filed Under: encryption, rankings, search results
Companies: google
Comments on “Google May Consider Giving A Boost To Encrypted Sites”
bad idea
A big bowl of bad idea. What of sites that carry no sensitive information or content and no forms to fill out, just a classic series of webpages? Even web apps like jsfiddle.net where it really doesn’t need encryption because of the low risk to any sensitive information. 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? I also see it as a way of putting SSL up on a pedestal that it doesn’t deserve, in turn giving people a false impression of security when they surf an encrypted site. As Heartbleed has proven, SSL is a tenuous solution at best and has neither earned nor deserves such credibility and trust.
Re: bad idea
Encrypting those websites would increase the amount of encrypted traffic hurting the collect everything mentalities, that and if ranked higher for encryption then why not down for using a faulty implementation?
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.
Re: bad idea
“Even web apps like jsfiddle.net where it really doesn’t need encryption because of the low risk to any sensitive information.”
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?
Re: Re: bad idea
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.
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?
Re: Re: Re: bad idea
Yep, I thought of that as well. Many complaints on this kind of thing can be easily defused by making new features optional rather than mandatory. I’m not sure that Google really has a great track record with this when making changes to their search ranking, so we’ll have to see what they choose.
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.
Re: SSL is *not* just confidentiality
You’re thinking narrowly. SSL/TLS does more than confidentiality. It also, as an unavoidable side effect, authenticates the content.
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”.)
Re: Re: SSL is *not* just confidentiality
Government agencies could force either the site or the signing authority to give them a copy of the certificate. All can be proven is that the content was signed by, or encrypted by a copy of an identified certificate, which is not the same as verifying its origination. This is the fundamental flaw of certificates, they do not prove who used them.
Re: Re: Re: SSL is *not* just confidentiality
Indeed. But this is based on trust. Diginotar was kind of destroyed a while back when somebody issued bogus certificates from the inside. Their certificates were quickly revoked from the inside in all major browsers and as far as I know business took a nose dive. If such practices come to light it’ll be a very serious hit against such entities and not in their best interests. Though it would probably spawn a much needed rush for decentralized certification or something that would replace the current “flawed” system. Although, truth be said, the real flaw is that it’s based on trust. And trust seems to be on route to extinction nowadays.
Still, it does give much better guarantees for the authenticity of the content.
Re: Re: Re:2 SSL is *not* just confidentiality
Remember, the reason Lavabit folded was a government agency demanding their master keys. The alphabet soup agencies are so arrogant that they think they could get away with demanding keys, or embedding agents so that they can get the keys.
Re: Re: Re:3 SSL is *not* just confidentiality
Ah, but they have to get the keys! They have to do the work, for each site they want to impersonate. And not all sites are in the USA, so they cannot simply demand the keys from these sites; they have to hack into them.
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.
Re: Re: Re:4 SSL is *not* just confidentiality
They don’t have to get keys from each site. All they have to do is compromise a trusted CA. They can they generate their own keys and do a MITM. Kindof makes you want to use non-US CA’s, doesn’t it?
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).
Re: Re: Re:5 SSL is *not* just confidentiality
“If a site suddenly starts using a cert from a different CA, issue a warning”
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.
Re: Re: Re:6 SSL is *not* just confidentiality
Unless a database of valid site certificates is preinstalled, how do you determine whether or not the first certificate you see for a site is its own, or from a man in the middle?
Re: Re: Re:7 SSL is *not* just confidentiality
That preinstalled database of site certificates actually breaks the trust chain as prescribed by good public key crytptographic principles. That was an intentional tradeoff between convenience and security, so it’s no wonder that it opens an avenue for a MITM attack.
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.
Re: Re: Re:8 SSL is *not* just confidentiality
Well, I think part of the point is that the public keys are publicly available. I 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. 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. So, in a sense, while it’s not perfect at the very least it makes a huge man in the middle conspiracy very difficult.
Re: Re: Re:9 SSL is *not* just confidentiality
“Well, I think part of the point is that the public keys are publicly available.”
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.
Re: Re: Re:10 SSL is *not* just confidentiality
“but the problem I arises”
I meant to say “but the problem I’m talking about arises”
My stupid fingers.
Re: Re: Re:10 SSL is *not* just confidentiality
“as that would mean checking literally hundreds of keys on a regular basis.”
Just the root key, from that point on the chain of trust can fall from there.
Re: Re: Re:11 SSL is *not* just confidentiality
Or the root certificates but are there really hundreds of them? I was under the impression that there are only like a hand full of root certificates and branch certificates can be checked from the root ones and those branch ones can then verify the specific author.
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?
Re: Re: Re:11 SSL is *not* just confidentiality
In my opinion, that would be insufficient. However, you’re right, there aren’t hundreds of root keys. More like dozens.
Re: Re: Re:10 SSL is *not* just confidentiality
Also, why would they need to be checked on a regular basis. You only need to check the keys that came with your operating system once. As far as checking a hundred certs that’s no problem, just write an app for that (if one doesn’t already exist, which is probably does). Who is going to do this one by one by hand? You can write an app that gathers a large list of certs from the Internet and saves it to a file. Take that app to a different location and do the same. Have the app compare the two.
Re: Re: Re:11 SSL is *not* just confidentiality
it probably does *
Re: Re: Re:11 SSL is *not* just confidentiality
“why would they need to be checked on a regular basis”
Because keys get updated and replaced.
Re: Re: Re:10 SSL is *not* just confidentiality
“The issue is “how do you know the public key you have is really from who you think it’s from.”
…
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.
Re: Re: Re:11 SSL is *not* just confidentiality
The question isn’t if your OS CD has been compromised. Fraudulent keys can be, and have been, distributed in these databases without the OS makers knowing that they were fraudulent (since they pass the chain of trust test).
“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.
Re: Re: Re:5 SSL is *not* just confidentiality
It takes just one person using Certificate Patrol or similar to notice the certificate has changed.
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.
Re: Re: Re: SSL is *not* just confidentiality
A small nitpick: the signing authority does not have a copy of the certificate’s private key. They can’t give what they don’t have. Without the private key, you can’t sign.
(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.)
Re: Re: Re:2 SSL is *not* just confidentiality
But they could generate a new cert with new keys with the signing authority. Your browsers likely wouldn’t notice. They could do a MITM with their trusted key/cert, and your server key/cert.
Re: bad idea
Every little bit of data tells a tale about you. Each piece, on its own, is a piece of a larger puzzle that describes your life. Allowing a government, whose goal is to store all data about you forever, access to small pieces of your life is insanity.
Re: bad idea
Well, I notice that even Techdirt, when visiting it using https, seems to have unencrypted or at least unvalidated elements. I guess the issue maybe that Techidrt has ads and some of those ad services don’t support encryption.
“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).
Re: Re: bad idea
(and I know that there is a difference between validate and verify but if you try to run something as administrator the operating system, windows, uses the word verified publisher. The operating system should really use the word validated publisher).
Re: Re: Re: bad idea
Well, I guess I’m wrong now that I think of it. I guess the whole point is that it’s been verified by the certificate authority. Checking the authenticity of a digital signature validates who the sender is but actually investigating identification cards, social security cards, maybe passports, etc.. and ensuring that the person requesting the certificate is who they claim to be is verification.
Re: Re: Re:2 bad idea
In fact, if the source is validated it makes even easier to avoid ad-networks serving malware.
Re: Re: Re:3 bad idea
Or it could give you a false sense of security.
Re: Re: Re:4 bad idea
Nah, I’d still block scripts and ads by default ;/
Re: Re: Re: bad idea
The idea is to ensure that you know who you are communicating with and that the communications are not decipherable by others. No cryptographic scheme can ensure that the entity you’re communicating with is a good one who won’t, for example, send malware your way.
Re: Re: Re:2 bad idea
but I think you’re still missing the point. If I visit Bank of America, for example, my browser maybe loading content from multiple different sources. Most average users aren’t going to check every validated source that the browser gets information from and verify that they are all trustworthy. The browser is simply going to tell users that all of the information sent to your browser is signed by someone (with that locked symbol). Who’s going to investigate past that point and stop their transaction if they think one of those sources is not trustworthy?
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.
Re: Re: Re:3 bad idea
I fully understand the point. I’m just saying that this isn’t a problem cryptography can address. Cryptography can only confirm who you’re talking with, that what you’re getting is actually what they sent, and that nobody can listen in. That’s it.
Re: bad idea
-What of sites that carry no sensitive information or content and no forms to fill out, just a classic series of webpages?
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?
Re: bad idea
It’s not expensive to get an SSL cert. I could get SSL inexpensively for my personal blog, for example, if Tumblr did not actively prevent the use of services such as CloudFlare and Incapsula (note that I’m using my .com).
I would argue that page load time isn’t an indicator of quality of what’s on the web page any more than encryption is. They’re both indicators of how the page is delivered.
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.
Google already plays favorites
“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.”
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.
This attempt at spin is hilarious.
Google and Mike Masnick have now become my go-to source for comedy.
Re: Re:
…but of course you won’t tell us why it’s wrong or open any discussion on the subject. Oh well, at least you’re not diving into a hilarious bad poor attempt at constructing a conspiracy this time.
Re: Re:
This attempt at spin is hilarious.
What spin?
Care to elaborate on that a bit because I’m not seeing any “spin” in any direction on this article whatsoever.
Oh my, Google *is* pissed
Google always had a bit of an “inmates running the asylum” mentality (their techies have a lot of voice).
It seems Google’s “fuck you” to the NSA is not finished yet…
Re: Oh my, Google *is* pissed
Good luck with that.
Google believes they’ve bought Congress to the point of impunity…
Let’s watch!
Re: Re: Oh my, Google *is* pissed
While I think this AC’s comment is incorrect, I don’t think it should have been flagged.
Re: Re: Re: Oh my, Google *is* pissed
Is there any way to undo a “flagging”?
I never registered an account here, but I assume members can upvote or downvote a comment, as on other sites.
Re: Re: Re:2 Oh my, Google *is* pissed
…but I assume members can upvote or downvote a comment, as on other sites.
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.
Re: Re: Re:2 Oh my, Google *is* pissed
If you click the report button a second time, it takes back your vote. I think I read somewhere, though, that once a comment has received enough votes to be hidden, undoing votes won’t make it unhidden again. But I’m not sure.
Makes sense
An encrypted site is more likely to be what the user wants because it’s less likely there’s an intermediary doing a man-in-the-middle attack (e.g. a government).