Google Offers Encrypted Web Search Option

alphadogg writes "People who want to shield their use of Google's Web search engine from network snoops now have the option of encrypting the session with SSL protection. In the case of Google search, SSL will protect the transmission of search queries entered by users and the search results returned by Google servers. Google began rolling out the encrypted version of its Web search engine on Friday. 'We think users will appreciate this new option for searching. It's a helpful addition to users' online privacy and security, and we'll continue to add encryption support for more search offerings,' wrote Evan Roseman, a Google software engineer, in an official blog post."

Comments

The real reason

[Anonymous Coward]

The real reason is that internet hacking people have been figuring out how to monetize the traffic they sniff. This is merely Google reclaiming the market that is rightfully theirs.

Re:The real reason

[Jackie_Chan_Fan]

Exactly right. This is not about your privacy... Its about Google protecting their market from say Verizon who could be packet sniffing anything you search on Google, and then selling that data... which then competes with Google.

Google is simply protecting their business. It has nothing to do with user rights or privacy.

But it is a welcomed addition. Its certainly a good thing... but it is also more for Google, than for you.

Re:The real reason

[Z00L00K]

It's an enhancement that isn't a disadvantage for the user, so we should welcome it.

And if it also prevents man in the middle hacking of web pages it's a good thing.

Re:The real reason

[MistrBlank]

Don't care if it is. I don't know why all of our internet traffic these days isn't encrypted. Good job Google for stepping up even on the simplest of things.

Re:The real reason

[FuckingNickName]

Agreed, we all know that in a free market economy

Where?

It's what we'd all do if given the chance.

Speak for yourself.

Re:The real reason

[mlts]

I see this also useful against Phorm, and other in-transit ad-insertion mechanisms.

All and all, the good guys benefit here. Google doesn't have ISPs modifying their ads in transit, replacing their ads with their own. The user gets search results that have not been tampered with (where a site for product "A" takes you to a different company, or associate IDs are replaced so different parties get credit for ad responses), and have potentially malicious ads thrown in. ISPs can't passively log the connection and sell the data (just like the parent said.)

Re:The real reason

[mlts]

It is apparent that you don't like Google. That's fine. However, that is beside the point. What is important is that the connection between the Google user and Google is only belonging to those two. A third party can slow down or block the SSL transaction, but unless they jack a root CA, compromise one of the endpoints, or break one of the encryption algorithms, they are not going to be seeing what is going on.

To reiterate: Regardless of opinions of Google, this is a good thing. A search query with Google is my business and Google's business. Not the ISP's, not Phorm's, not a MITM watching the traffic go by. I'm sure as time goes on, less scrupulous ISPs will be slavering over ad revenue from in-transit ads.

Re:The real reason

[FuckingNickName]

I once misspelled "harass" as "harrass". I fixed this by recalling that I should not "har-ass her-ass". This has both everything and nothing to do with embarrassment, so embarrassment works the other way.

Re:The real reason

[slack_prad]

You can pay for a slashdot subscription for https access...

Re:The real reason

[Anonymous Coward]

But from the PoV of storage and datamining, it's as much Google's business as it is Phorm's.

Uhm, no it isn't. You went to google to do a search. You didn't go anywhere else. Therefore, it isn't anyone else's business. And if you don't want google to have your search data, you can opt out of that by not using them at all. Phorm isn't even in the equation, they are interlopers. Encrypting the traffic cuts those types out completely. That way you only have Google to worry about.

Re:The real reason

[FireFury03]

No. Kids don't have instinctive responses to particular web pages

If you think this then you haven't dealt with many teenage kids.

adults who think that implied disgust and taking away of information are correct ways of providing education.

Who said anything about providing education?

I'm pretty anti-censorship and think that people should have access to whatever information they like. *However* I'm not crazy enough to believe that the very young are capable of dealing with all that information - they should only get access to some of it when they have matured to the point of being able to deal with it.

There are 3 things that kids need protecting against:
1. accidentally stumbling across content. Do you really want primary school kids accidentally stumbling across the likes of 2g1c? Plenty of adults find it quite traumatising, let alone kids who haven't been prepared through life experience.
2. intentionally finding content. Do you want kids to know how to set up their own drugs lab before they have the life experience to understand the consequences of drug use? Also, things like electronic bullying are real problems causing real harm.
3. distracting content. When kids are in lessons, they frequently do need access to the internet. But giving them access to the likes of facebook is really distracting (even employers have a problem with this, let alone schools!). There is a certain amount of policing that can be done by the teachers, but filtering systems help a lot.

Once they have the life experience to deal with this stuff then by all means, let them access it. If you, as a parent, disagree with this sort of censorship then you are well within your rights to allow your kids to access this content in their own time from home, but they certainly shouldn't be accessing it in school where they can inflict it on other kids, whose parents almost certainly disagree with you.

Re:Security != privacy.

[drinkypoo]

In other words, you still trade your privacy for the service provided by Google; the difference is the trade being less likely to be interrupted now.

Google has never shown any tendency towards abuse of my private data. My government, on the other hand, has repeatedly demonstrated its willingness to break its own laws whenever it's convenient for any of their actual constituents, i.e. corporations. I'm much more worried about my government watching my search history than google doing it. Of course, they'll give that information to my government any old time, but that's not the same thing as having it continually logged where it can fire off triggers.

No, I'm not doing anything that I feel my government would attack me for. But then, I'm not doing anything google would attack me for, either. Google continually stands in opposition to the corporations that I am concerned about. The enemy of my enemy may or may not be my friend, but odds are better than if he's my enemy's friend. Contrarily, much of what the U.S. government does makes it the enemy of any right-thinking citizen, where right-thinking is defined as "freedom-loving". (I may have a bias, but I certainly don't hide it.)

Now I can Google my SSN and CC#!!!

[AmazinglySmooth]

I really wanted to know if any site are posting my SSN and CC#. Thanks you, Google.

Re:Now I can Google my SSN and CC#!!!

[hedwards]

I know you're joking, but the way you do that is by googling the first 5 or 6 digits of your SSN, then manually comparing the last 4. The first 5 or 6 aren't unique and can be relatively easily guessed based upon the location and date of birth. Similar searches are great for finding CC#s that might be posted online.

Re:Now I can Google my SSN and CC#!!!

[thijsh]

Better yet google for the a range of 10000 numbers by adding two dots between the lower and upper number:
Google: 123450000..123459999

This way you can search for SSN, CC numbers etc.

Re:Now I can Google my SSN and CC#!!!

[Kozz]

Better yet google for the a range of 10000 numbers by adding two dots between the lower and upper number:

Google: 123450000..123459999

This way you can search for SSN, CC numbers etc.

When I try that, all I get is a message from Google that accuses me of being a bot, and they won't process my request in order to protect their users.

Re:Scroogle is better

[XPeter]

Yes, but Scroogle has recently been shut down by Google, so this is their alternative.

Implications on China

[dncsky1530]

This could be an interesting development for Google's efforts in China. If the traffic between google and the client is encrypted then the firewall of China *shouldn't* be able to analyse the search results coming back. The only option for China might be to block Google SSL completely but that might be a bit too risky politically.

Re:Implications on China

[gzipped_tar]

It's meaningless. You search for some keywords over SSL and click on a non-https link in the result page. BAM, the Referer now points to the result page, which contains the keywords you just used in its URL.

Of course Referer is easily spoofed, but you get the idea: Google search is only one aspect of a person's online activities, and the secret hiding in it can be analysed using side channels.

Re:Implications on China

[Nukenin]

You search for some keywords over SSL and click on a non-https link in the result page. BAM, the Referer now points to the result page, which contains the keywords you just used in its URL.

According to RFC2616 (HTTP/1.1) section 15.1.3 "Encoding Sensitive Information in URI's", "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

Re:Implications on China

[IamTheRealMike]

If you read the FAQ it says the referer header is being stripped. Not sure how, but apparently it is.

Re:Who is this for?

[gzipped_tar]

SSL adds protection to both ends of the communication. This may look like a circus from the user's perspective; but for Google themselves, it's better self-defense.

Re:Who is this for?

[euyis]

At least it's nice for Google users in China like me. The government has been actively disrupting Google's service in mainland China since they moved to Hong Kong, restting your connection if certain words/characters (yes characters!) are detected. An encrypted connection surely makes using Google in China less painful.

Re:Security != privacy.

[BhaKi]

My government, on the other hand, has repeatedly demonstrated its willingness to break its own laws whenever it's convenient for any of their actual constituents, i.e. corporations.

You do realize that Google is a corporation too, don't you?

All HTTP traffic should be encrypted

[swillden]

As a matter of course, we should use SSL on all connections. In some rare cases the computation may be too much of a burden, but in the vast majority of situations it's trivial and there's no reason not to do it.

IMO, the only reason we don't do it more is because the way browsers handle self-signed certificates is broken.

There's no reason for a browser to throw up nasty error dialogs when it encounters a self-signed certificate. Instead, browsers should silently accept such certificates and record the public key fingerprint. Browsers shouldn't turn on the lock icon when using a self-signed cert, or do anything else to make the user think they're browsing on a secure connection, because they're really not, but they should go ahead and encrypt the traffic.

Not only would that provide some measure of security against eavesdropping, but it would also assist with detection of phishing attacks. Browsers could and should throw up nasty warnings/errors when connecting to a site whose certificate has inexplicably changed. This is similar to how SSH handles trust of server keys, a system that works very well in practice.

Regarding this move by Google, I think it's great. I applauded their decision to make Gmail and Google Apps HTTPS-only, and providing the option for Google Search is great, too. Hopefully they'll eventually go to HTTPS-only for search as well. Their page volumes are such that they'll have to seriously consider the impact of the encryption overhead, but I think they'll get there.

Re:All HTTP traffic should be encrypted

[swillden]

Either you're trolling or you honestly have no idea why it's a good idea to throw up all sorts of errors on encountering a self-signed certificate.

Clue: SSL is intended to guarantee that nobody can eavesdrop on your connection. As soon as you start to see anomalies in the certificate chain (such as a self-signed certificate), that guarantee cannot be upheld.

Did you read my post? That's why the user shouldn't be given any indication that the connection is secured when a self-signed cert has been presented, because it's really not.

Sites where sensitive data is managed should not used self-signed certs, so that the certificate chain can be verified, to defeat MITM attacks. But sites that would currently not use any encryption could increase their security by a non-negligible amount by using HTTPS and a self-signed cert -- but the way browsers handle self-signed certificates is stupid and broken.

Re:All HTTP traffic should be encrypted

[jellyfrog]

What?

Of course the browser doesn't know the difference between a site that uses signed certificates that is being MITM'd and one that uses a self-signed certificate. That's why neither of these should be advertised as being "secure". Because they're not. And when you go to https://my.bank/ and notice that the lock isn't there because someone's doing a MITM with a self-signed cert you should realise "whoa, hey, this isn't a secure connection" and proceed to not give your bank details to whoever is at the other end.

On the other hand, when you go to https://porn.site/ and it uses a self-signed certificate, well no, it's not secure. Maybe someone is doing a MITM attack. But at least some random person with a passive network sniffer can't see everything you're watching, and furthermore no-one even with an active MITM attack can affect your connection once it's been established.

Re:All HTTP traffic should be encrypted

[j-beda]

How's the browser meant to know the difference?

The browser is not meant to (and cannot) know the difference between sites using a self-signed-certificate and those that should use a "real" certificate. That is what the user is supposed to do. What the original poster was suggesting was that sites using a self-signed-certificate display the site AS IF no security was present. Thus when you visited "Chris's House of Fly Fishing Forums" with a self-signed-certificate, you would not be presented with an obtrusive "watch out! this might be phony!" notification, but you would also not be presented with lots of flashing padlocks and icons indicating your high security. Such a system would not penalize websites which used self-signed-certificates IN COMPARISON TO sites which use NO certificate at all. Users however would have some actual benefit in that their fly fishing discussions would be more well secured from third parties. If people use the same or similar account names and passwords on lots of websites, identity theft would be a bit harder than just sniffing their unencrypted web traffic if all of it was secured with self-signed-certificates.

It does seem as though there would be some non-zero positive effects to more "regular" sites using encrypted sessions, and encouraging use of self-signed certificates in cases sign as these.

For a real-world example: a cheap-ass lock discourages the good-for-nothing-neighbourhood-punk-kids from rummaging through the garden shed. There is little benefit to also putting up a big sign in the drawer where we keep the key saying "the lock on the shed is a piece of shit and provides no real security".

Re:All HTTP traffic should be encrypted

[bodan]

From the user’s point of view, the suggestion wasn’t to add a new level of security. The suggestion was that a SSL connection with a self-signed certificate should be presented to the user _exactly_ the same as a normal HTTP connection. Which makes sense, as the user still doesn’t have any sort of guarantee about who they’re connected to.

Again: for the user, there’s secure (which means properly certified SSL, and a lock, and whatever other visual indicators), or insecure (anything else; no lock, no other visual indication).

The advantages of this are two-fold:
* the data is encrypted; you still can intercept it, but you need to work much harder; with HTTP you can just passively listen with Wireshark
* the browser can detect when the self-signed certificate changes, and only _then_ make a fuss. Someone who starts to intercept your traffic (that is, they didn’t do it from the beginning) will be severely inconvenienced when intercepting sites you’ve already visited before they started intercepting

It’s doesn’t make everything perfectly safe, but it certainly increases safety.

Re:All HTTP traffic should be encrypted

[swillden]

Certainly, if the browser receives a self-signed certificate from a formerly-secure site, it should complain loudly. Also, browsers should make the secured status of sites very obvious, and sites with self-signed certs are not secure.

Re:All HTTP traffic should be encrypted

[something_wicked_thi]

The real problem with allowing self-signed certs is that it means that https doesn't mean you're secure anymore.

Yes, technical users might be able to use them safely, but I wouldn't trust myself to be that attentive. Consider if I clear all my local browser state, or if I'm using a new computer and I go to my bank's web site. I've entered https so I think I'm safe. Do you think I'm going to notice the lack of a lock in the browser window? What about sites like facebook where I don't even see https, even though it's authenticated over https? For situations like these, the only warning you get that something is up is the self-signed cert problem.

Of course, with facebook, a mitm attack could remove all ssl and nobody would know, which is why it's a bad idea not to put your login page on ssl. However, for most users, simply seeing or typing https means "I'm secure." Allowing self-signed certs breaks that.

Re:Scroogle is better

[Anonymous Coward]

Scroogle was never shut down by google. Google changed the layout of their results page, and scroogle had to update its scraping software in order to be able to read the new format.

here is the article where Scroogle claims they'll have to shut down forever, and here is scroogle, working fine.

One last note, for the truly paranoid: how do you know scroogle isn't a front, run by google?

Re:Scroogle is better

[James_Duncan8181]

Yes, but Scroogle has recently been shut down by Google, so this is their alternative.

http://www.scroogle.org/scrapen8.html - well, it certainly didn't take much research to work out that isn't true.

Re:Security != privacy.

[drinkypoo]

My government, on the other hand, has repeatedly demonstrated its willingness to break its own laws whenever it's convenient for any of their actual constituents, i.e. corporations.
[...]
No, I'm not doing anything that I feel my government would attack me for. But then, I'm not doing anything google would attack me for, either. Google continually stands in opposition to the corporations that I am concerned about. The enemy of my enemy may or may not be my friend, but odds are better than if he's my enemy's friend.

You do realize that Google is a corporation too, don't you?

You just failed your CTBS reading comprehension test. Back to elementary school with you! (If you are in elementary school now, I apologize. I do not want to be ageist.)

Re:Chrome/Firefox address bar still not SSL tho.

[Kilrah_il]

Actually, you can find instructions on setting Google SSL as your search engine here: http://googlesystem.blogspot.com/2010/05/google-secure-search.html
Have fun!

I got a glimpse of this early yesterday

[sootman]

After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

IP tracking

[nurb432]

But google still knows what you did.

think logically

[yyxx]

In other words, you still trade your privacy for the service provided by Google; the difference is the trade being less likely to be interrupted now.

Privacy isn't an all or nothing proposition. I don't "trade in" my privacy, I disclose information selectively. When I search on a search engine, necessarily that search engine know what I searched for. Google has defined retention policies, and there is no reason to believe that they don't comply with them.

However, there are other aspects of privacy I don't have control over. There's a good chance my ISP is sniffing my packets and my government is digging through them to find whatever the political hangup of the day is, and there's a good chance that what ever they are doing, they are doing incompetently.

Now, I'd like to be able to do web searches without having to second guess whether those searches (innocuous and legal as they are) trigger some stupid keyword alert in some badly written network surveillance system. Hence, I like my connections to my search engine to be encrypted.

What Google does with those searches isn't much of a concern for me: there are no known instances of Google doing data mining on behalf of governments (all they do is respond to specific requests), and all they want to do is show me ads.

So, an encrypted connection to Google protects my privacy in exactly the way I want it to: it keeps the people who have no business looking at my web searches from looking at my web searches. Simple, eh?

Re:Who is this for?

[yyxx]

(given google's questionable record on privacy issues)?

Really? Like what?

moved to other search engines

Like which one? Bing? What reason do I have to trust them any more than Google?

I can't help but question who this feature is for.

Pretty much anybody. Right now, your ISP and your government likely are scanning your unencrypted web communications for keywords and prohibited content. Even if you don't do anything wrong, you may trigger those systems, with potentially unpleasant consequences. An SSL connection makes that harder for them.

And it's a matter of principle: my web searches are nobody's business other than my own and my search engine's.

SSL will only protect against man-in-the-middle attacks;

SSL protects against eavesdropping.

Re:Adjusting search boxes

[CronoCloud]

https://addons.mozilla.org/en-US/firefox/addon/161901/

Check that fingerprint... especially at WORK

[yup2000]

but be sure to write down google's ssl fingerprint... and check it every now and then yourself. You never know when your place of work decides to start intercepting https! Mine did recently until I pointed out issues with HIPAA compliance in conjunction with our limited personal use policy! They (work) installed their own certificate on everyone's computers (but they didn't do Firefox which is why i noticed)... and then they modified the proxy servers to start taking a peek before re-encrypting and sending it along :(

Re:Security != privacy.

[Veramocor]

Google clearly states this on their page. There is no such thing as 'free'.

"few notes to remember: Google will still maintain search data to improve your search quality and to provide better service. Searching over SSL doesn't reduce the data sent to Google -- it only hides that data from third parties who seek it. And clicking on any of the web results, including Google universal search results for unsupported services like Google Images, could take you out of SSL mode. Our hope is that more websites and services will add support for SSL to help create a better and more consistent experience for you.

We think users will appreciate this new option for searching. It's a helpful addition to users' online privacy and security, and we'll continue to add encryption support for more search offerings. To learn more about using the feature, refer to our help article on search over SSL."

They make there money by monetizing your search and with ads. You are free not to use their service.

Re:Security != privacy.

[fustakrakich]

Google has never shown any tendency towards abuse of my private data...Of course, they'll give that information to my government any old time, but that's not the same thing as having it continually logged where it can fire off triggers.

How do you know it's not being done automatically now? You don't.. My advice is simply to trust no one. The internet is a party line, any anybody can hear what you're doing. And government and corporation are the same. That's the way the majority wants it. The cool thing is that you can vote in a different government if you like. You don't have to vote for your spoon fed candidates if you don't want to. That means the problem is your friends and neighbors, not the government itself. It takes a bit more effort to drive a corporation into bankruptcy. Wall Street has turned that into a game of whack-a-mole.

The feature we really need

[dawilcox]

I've been waiting for google to provide a button on their search page "Don't connect this search with my IP address". It's not the me vs my peer privacy that I care about the most, it's the me vs google privacy that scares me.

Good

[Gonoff]

This will stop nosey people in the middle sniffing my searches.

Is there a way of doing an "advanced search" that only brings up HTTPS results - apart from putting that as a part of the search string?

Close... but what about auto-suggests

[poind3xt3r]

While Googles searches are secure, it would appear autosuggests? I use FF's search bar and set the search engine to use SSL. Forcing the autosuggest url to https redirects back to http which means anyone sniffing for suggestqueries.google.com can still find out my queries

Google's We're sorry page

[tepples]

I tried it, but all I got was

We're sorry...

... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now.

I had to wait a couple minutes, log in using my Google account, and then search for various antispyware-related keywords before Google would let me run a query like this again.

Re:It doesn't.

[asserted]

actually, your browser will do this for you anyway:

RFC 2616, 15.1.3:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Interesting side effect

[mysidia]

Corporate IT will no longer be able to monitor Google search activity merely by intercepting port 80 traffic.

They also cannot implement a webfilter that simply monitors port 80 traffic, and denies your ability to search, based on keyword.

They can't block SSL either, since Google requires SSL for certain things (login to Google accounts, google webmaster tools, google checkout) that Enterprise users may require.

Re:Security != privacy.

[DragonWriter]

It means MITM attacks are more unlikely, but your data is still in Google's hand.

Well, yeah, the queries you actively send to Google are in Google's hands.

The privacy benefit is directly linked to the security benefit, in that people other than the one to whom you are choosing to give your data to provide you with a service don't have quite as easy access to it in transit.

Privacy doesn't mean no one has your information, it means that only the people you choose to give your information to have it.

Re:and in other news...

[grmoc]

In this case you need to put a root cert on the school's computers, and do a MITM for SSL.
SSL doesn't mean no MITM. It means no *unauthorized* MITM...