Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Google Encryption Privacy Security News Technology

Google Offers Encrypted Web Search Option 288

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."
This discussion has been archived. No new comments can be posted.

Google Offers Encrypted Web Search Option

Comments Filter:
  • The real reason (Score:5, Interesting)

    by Anonymous Coward on Saturday May 22, 2010 @10:21AM (#32305316)
    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 (Score:5, Interesting)

      by Jackie_Chan_Fan ( 730745 ) on Saturday May 22, 2010 @10:41AM (#32305438)

      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 (Score:5, Insightful)

        by Z00L00K ( 682162 ) on Saturday May 22, 2010 @10:57AM (#32305574) Homepage Journal

        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.

        • Unless I'm missing something, this is only for the search itself. As soon as you actually click on of those results, you're at the mercy of whatever server you're connecting to -- and probably no longer encrypted.

          • by Z00L00K ( 682162 )

            It would be very interesting to see how you think that Google would resolve that problem. But of course - they could at least have provided a padlock icon or something for every link that is referring to a page using HTTPS.

            But at least - now it's not that easy to snoop on the net what a certain person searches for. "Ice Cream Bomb" or "Nuclear Bomb"?

          • Nope... the results are also running through the secure site.

            Give it a shot and see.

          • And I'm sure they don't prevent the query from leaking in the REFERER header, which would be trivial for them to do if they would take the time.
        • Agreed, also now nobody else will know which words I need to look-up the spelling of, relieving my virtual embarrassment!

          (Did you know there are two "r"s in "embarrassment"?)

          • by Z00L00K ( 682162 )

            That's why I use FireFox - it has a spell checker! :p

          • Re: (Score:3, Funny)

            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 (Score:5, Insightful)

        by mlts ( 1038732 ) * on Saturday May 22, 2010 @12:21PM (#32306124)

        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.)

      • i've just tested https://google.com/ [google.com] ... the query parameter is sent as GET request and therefore unencrypted. What am I missing? Isn't the query and not the response the valuable part of google search ?

        -S

    • Re:The real reason (Score:4, Insightful)

      by MistrBlank ( 1183469 ) on Saturday May 22, 2010 @11:18AM (#32305722)

      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: (Score:2, Insightful)

        All useful sites offer complete SSL access, but I guess Google - as with IPv6 - gets to be congratulated when it makes a half hearted attempt to do what real technology pioneers have been doing for a good decade.

        In other news, everything Apple's ever done is original.

  • by AmazinglySmooth ( 1668735 ) on Saturday May 22, 2010 @10:34AM (#32305392)
    I really wanted to know if any site are posting my SSN and CC#. Thanks you, Google.
    • by hedwards ( 940851 ) on Saturday May 22, 2010 @10:42AM (#32305446)
      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.
      • by thijsh ( 910751 ) on Saturday May 22, 2010 @10:59AM (#32305588) Journal
        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.
        • by Kozz ( 7764 ) on Saturday May 22, 2010 @12:32PM (#32306228)

          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.

        • 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.

          • by thijsh ( 910751 )
            I guess Google has some measures in place to prevent people from abusing this now (a while back you could still search this way). But still, when you specify either a really small range or a really big range you'll get the results. They probably filter this query because it appears as a distributed botnet doing an SSN/CC/other search...
        • by caseih ( 160668 )

          Doesn't seem to work. Google comes back and says "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 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.

        That depends on how old you are - those of us born before the IRS started requiring SSNs for all dependents claimed on the tax forms often have SSNs acquired years after and miles away from where we were born. I didn't get an SSN until I was in the 8th grade, when we

  • by dncsky1530 ( 711564 ) on Saturday May 22, 2010 @10:40AM (#32305428) Homepage
    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: (Score:2, Informative)

      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.

      • There is a fix for that, look at what Opera is doing, they are allowing you to browse in a mode, that first caches the pages on Opera side and then pre-processes them and sends them to the browser. This could also be used to surf all the found sites through an SSL encrypted connection.

      • by Nukenin ( 646365 ) on Saturday May 22, 2010 @11:35AM (#32305838)

        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" [ietf.org], "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: (Score:3, Informative)

        If you read the FAQ it says the referer header is being stripped. Not sure how, but apparently it is.
        • by Penguin ( 4919 )
          The most common way is to use a meta refresh "header". When redirected this way browsers don't include the referer header.

          Some forum software use such a feature when making URLs clickable.

          Other methods include javascript tricks.

          The actual output from Google when searching for slashdot is this and clicking the link is the following, which is primary javascript with fallback to the html meta header:

          <script>var a=parent,b=parent.google,c=location;
          if(a!=window&&b){if(b.r){b.r=0;a.location.href="ht
        • Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

          RFC2616, 15.1.3 [ietf.org]

          all browsers follow this.

      • Actually, from the Google information on their SSL search, "As another layer of privacy, SSL search turns off a browser's referrers. Web browsers typically turn off referrers when going from HTTPS to HTTP mode to provide extra privacy. By clicking on a search result that takes you to an HTTP site, you could disable any customizations that the website provides based on the referrer information."

      • It may not be perfect or up to date but you could access the cache page (via SSL) and still get to access (reference) material.

      • by cynyr ( 703126 )

        They mention that most good browsers, don't use HTTP_referrer for SSL sites.

        What can I expect from search over SSL?

        Here's how searching over SSL is different from regular Google search:

        • SSL encrypts the communication channel between Google and a searcher's computer. When search traffic is encrypted, it can't be read by third parties trying to access the connection between a searcher's computer and Google's servers. Note that the SSL protocol does have some limitations — more details are below.
        • As another layer of privacy, SSL search turns off a browser's referrers . Web browsers typically turn off referrers when going from HTTPS to HTTP mode to provide extra privacy. By clicking on a search result that takes you to an HTTP site, you could disable any customizations that the website provides based on the referrer information.
        • At this time, search over SSL is supported only on Google web search. We will continue to work to support other products like Images and Maps. All features that are not supported have been removed from the left panel and the row of links at the top. You'll continue to see integrated results like images and maps, and clicking those results will take you out of encrypted search mode.
        • Your Google experience using SSL search might be slighly slower than you're used to because your computer needs to first establish a secure connection with Google.

        Note that SSL search does not reduce the data that Google receives and logs when you search, or change the listing of these terms in your Web History.

        So you need to make sure your browser disables http_referrer for SSL sites, and otherwise behaves well.

    • There's not really such a thing as "risky politically" in China.
  • Most people today probably enter search through their address bars...

    That doesnt appear to go through SSL... yet at least.

  • by swillden ( 191260 ) <shawn-ds@willden.org> on Saturday May 22, 2010 @10:47AM (#32305500) Journal

    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: (Score:2, Interesting)

      by jimicus ( 737525 )

      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

      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. In fact, there was a bug filed against Firefox a while back now when it did flash up such an error and it transpired that the connection was being e

      • by swillden ( 191260 ) <shawn-ds@willden.org> on Saturday May 22, 2010 @11:08AM (#32305654) Journal

        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.

        • by jimicus ( 737525 )

          How's the browser meant to know the difference?

          • How's the browser meant to know the difference?

            The difference between what and what?

          • by cpghost ( 719344 )
            Parent poster probably meant to show an open lock for plaintext HTTP, a partially closed lock for self-certified certs that can't be tracked up to a trusted CA, and a closed lock for an unbroken chain of certs. This idea isn't so bad, IMHO.
            • by jimicus ( 737525 )

              Which is well and good, but remember most people don't really have the inclination to learn how the security works - they just want to know it's there. Such a suggestion means that you're essentially introducing a new level of security: "sort-of secure, fine if you're not doing anything important".

              IMV, this is introducing confusion. For most practical purposes, "refuse a self-signed certificate" is perfectly good advice and eliminates much of the confusion. If you're a company and you don't want to go o

              • Re: (Score:3, Interesting)

                by bodan ( 619290 )

                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 (anyth

          • Re: (Score:2, Informative)

            by jellyfrog ( 1645619 )

            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/ [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 oth

          • by j-beda ( 85386 ) on Saturday May 22, 2010 @11:53AM (#32305942) Homepage

            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".

        • by thijsh ( 910751 )
          There is a legitimate use for self signed certificates by adding transport encryption (works fine for SSH) for small sites that can't shell out the cash for the certificates. The only thing not present is verification, but that's already available in all 'qualities' (the cheapest certs. can be bought by anyone anyway, so for every site except the top 1000 this verification can also be very misleading). That is why users should be educated about the difference in encryption and verification (I'm pretty sure
        • Re: (Score:3, Insightful)

          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 tho

      • 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. In fact, there was a bug filed against Firefox a while back now when it did flash up such an error and it transpired that the connection was being eavesdropped.

        Yet you're using slashdot without encryption. Treating self-signed certificated as worse then HTTP traffic is broken. Self-signed does provide some protection that HTTP doesn't. Namely it no longer can be passively eavesdropped, it requires MITM. Now go look at how many CA's are in your browser, that's how many organizations you're giving permission to pretend to be whoever they want. There is no silver bullet in security. So you should take the 50% solution over the 0% solution. Yet right now we're

    • There are sites that allow you to get free SIGNED SSL certificates. I got a StartCom Certificate a number of months back, and people no longer get browser errors on my site. Sure, it's a little bit of a hassle, but in the long term it's worth it.

  • by sootman ( 158191 ) on Saturday May 22, 2010 @11:05AM (#32305638) Homepage Journal

    After typing in www.google.com to play some Pac-Man [slashdot.org] yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/ [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?

  • This protects your privacy from everyone but google. Having someone sniff your packets is theoretically possible, but extremely unlikely in reality. On the other hand, you are absolutely guaranteed that google will harvest and store the information from your searches in order to show you ads that they think you'll be interested in. This is why I habitally use the search engine clusty.com for web searches. Clusty's search results usually seem to be about the same quality as google's, and clusty has a better
    • by cynyr ( 703126 )
      my ISP could be doing so very very easily, and their upstream, and so on and so on.
  • IP tracking (Score:3, Insightful)

    by nurb432 ( 527695 ) on Saturday May 22, 2010 @11:09AM (#32305664) Homepage Journal

    But google still knows what you did.

    • by Yvanhoe ( 564877 )
      and if neither terrorist-turorial.org or wetpussies.com offer SSL connections, this is quite useless.
    • look, i'm all for privacy, but too many expect the impossible

      even if google publicly announced it was keeping no logs, this wouldn't be good enough for some people. you'd complain about something, anything. because you want to complain, not because you have anything useful to say

      some people's standards are too insane

      look: if you go to the store, and buy a can of coke, someone knows you went and bought a can of coke. deal wtih it, that's life: you leak personal info all the time in disjointed ways. there is

  • Does anyone know how to adjust Firefox's search bar to use the SSL version of Google?
  • Looks like google is just mocking [gabrielweinberg.com] DuckDuckGo.
    But the use of SSL on google does not offer you privacy: google still knows who you are and what you searched for.

  • by yup2000 ( 182755 ) on Saturday May 22, 2010 @11:32AM (#32305820) Homepage

    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 :(

  • 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 (Score:3, Interesting)

    by Gonoff ( 88518 ) on Saturday May 22, 2010 @12:15PM (#32306074)

    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?

  • by poind3xt3r ( 890661 ) on Saturday May 22, 2010 @12:21PM (#32306122)
    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
  • by mysidia ( 191772 ) on Saturday May 22, 2010 @03:05PM (#32307488)

    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.

"If it ain't broke, don't fix it." - Bert Lantz

Working...