Google to Offer Encrypted Search This Week

[Arthur]

You may want to start blocking https://google.com/ before the students (and teachers) start using it to evade your proxy server(s).

 

Source: http://www.wired.com/threatlevel/2010/05/google-encrypted-search/

 

Google will begin letting users run encrypted searches on its flagship search site Google.com starting next week, the company said in a blog post Thursday.

 

Allowing users to search using https - the web security system which many associate with online banking and shopping — would mark a first for a major search engine, and could begin a move by web services such as social networks to begin offering encryption for more than just log-ins. Such increased adoption would cut down on network eavesdropping and also have the added benefit of preventing some online attacks.

 

Google turned on encryption — better known as https:// — as a default for Gmail users earlier this year. That encrypts the data sent between a user’s browser and Google’s servers, making it nearly impossible for someone in the middle to read the contents of that e-mail. When not using SSL, a user of a school or corporate network can have their e-mail and web traffic content read by authorities who control the network, while anyone using an open Wi-Fi connection can have their traffic sniffed by a hacker using simple tools.

[AngryTechnician]

Handily, I'm pretty sure the RM SmartCache doesn't have the ability to differentiate between HTTP and HTTPS. If it does have such a setting, I can't find it.

 

At least they won't be able to get through to the actual results, since those will still be via HTTP; Google is only presenting it's own pages via HTTPS, not proxying the sites it finds, unless I'm mistaken. That said, anyone know if the cache servers will also be HTTPS?

[Arthur]

The SmartCache is pretty rubbish when it comes to HTTPS. The way I understand it is that once a user signs into the encrypted Google search engine (or any SSL website for that matter) it would be impossible to block things like search terms because nothing after https://google.com/ would be shown. In the case of the SmartCache I don't think it logs any HTTPS URLs. This is one of the reasons we are looking at alternative proxies like SmoothWall.

 

Unless you add exceptions like the ones listed below it would also mean things such as Google Calendar would be filtered too. I know my headteacher uses this so he wouldn't be too happy if I blocked https://google.*/*.

 

docs.google.*/*
groups.google.*/*
knol.google.*/*
mail.google.com/*
sites.google.*/*
spreadsheets.google.*/*
google.*/bookmarks/*
google.*/calendar/*
google.*/contacts
google.*/dictionary*
google.*/finance*
google.*/history/*
google.*/notebook/*
google.*/reader/*
google.*/voice/*
google.*/webmasters/tools/*

 

 

Google is only presenting it's own pages via HTTPS, not proxying the sites it finds.

That's true. It will be interesting to see if they do the Cache URLs too.

[john]

I would expect my lovely Smoothwall to be able to not suffer with this as it unencrypts the SSL traffic to analyse it Go Smoothwall

[AngryTechnician]

I would expect my lovely Smoothwall to be able to not suffer with this as it unencrypts the SSL traffic to analyse it Go Smoothwall

 

Out of technical curiosity, how does that work in Smoothwall? Do they use CA subversion or some other mysterious method?

[john]

Its wizardy, but it works I put a CA from the Smoothwall on all my clients (using GPOs) and when users who are set to have SSL intercepted hit SSL sites it shows secured by Smoothwall and not by, say Amazon or Barclays, they are secure though! I don't want you thinking that it stops the SSL bit, it is secure just it reads the data to stop SSL proxy sites as now a days genuine SSL certificates are £20 a go so its not that expensive to put real ones on that are valid.

 

As for a more techy explanation the Smoothwall guys on here are probably best to explain it rather than me as all I know is it works and stops the kids getting onto proxies (I don't SSL filter my staff just students)

[SimpleSi]

I'm just laughing at the whole concept.

 

Google preventing "man-in-the-middle" eavesdropping.

 

THEY ARE the "men-in-the-middle"!

 

Si

[AngryTechnician]

I put a CA from the Smoothwall on all my clients (using GPOs) and when users who are set to have SSL intercepted hit SSL sites it shows secured by Smoothwall

OK, that's exactly how I thought it would work, thanks.

[ICT_GUY]

About time that encrypted searches were offered. I would be happier if the default for everything was https.

 

[pete]

About time that encrypted searches were offered. I would be happier if the default for everything was https.

 

 

Yeah, cause .gov wouldn't require ISPs to do MITM attacks would they? "As part of your Broadband setup, just run this handy utility to configure your network settings." < -- Boom, cert installed.

[Jamo]

Handily, I'm pretty sure the RM SmartCache doesn't have the ability to differentiate between HTTP and HTTPS. If it does have such a setting, I can't find it.

 

At least they won't be able to get through to the actual results, since those will still be via HTTP; Google is only presenting it's own pages via HTTPS, not proxying the sites it finds, unless I'm mistaken. That said, anyone know if the cache servers will also be HTTPS?

 

 

The RM Smartcache cant see any search strings in a HTTPS site. They even did an update recently becuase it didn't show any HTTPS sites at all.

 

You cannot create a deny rule for https://google.com on the smartcache as it would come out as http://https://google.com I would think. I can only think of changing the host file maybe?

[enjay]

At least they won't be able to get through to the actual results, since those will still be via HTTP; Google is only presenting it's own pages via HTTPS, not proxying the sites it finds, unless I'm mistaken. That said, anyone know if the cache servers will also be HTTPS?

 

That was my understanding too - it will permit them to hide what they're searching for, but not hide their activity thereafter. IE8's InPrivate Browsing (by default, enabled on RM's config of it), on the other hand...

[AngryTechnician]

IE8's InPrivate Browsing (by default, enabled on RM's config of it), on the other hand...

InPrivate only stops history being stored on the browser. The traffic still has to go through your proxy, and will still be picked up by central filtering and logging systems.

[Jamo]

It will be very interesting how this pans out for filtering, as we will be totally stuck if they implement this as all we can do is block addresses such as google.com not specific variants eg google.com:443

 

If the results are delivered in plain text, it would be pointless as a lot of the time the search query is obvious from the web address. I expect that if the whole site is HTTPS then parts such as the 'cached' section could prove interesting as could the ability to remove the safesearch filters!

[SimpleSi]

About time that encrypted searches were offered. I would be happier if the default for everything was https.

 

And what information are YOU searching for then?

Si

[enjay]

InPrivate only stops history being stored on the browser. The traffic still has to go through your proxy, and will still be picked up by central filtering and logging systems.

 

We use an upstream proxy, so all we have for traffic monitoring is RM's Web Monitor product, and that can't see any activity while using InPrivate.

[Arthur]

SSL has been enabled.

 

[tom_newton]

Missed this thread earlier...

Looks like Google have done the sensible thing and kept images out (for now!) and indeed a cursory check shows that the handful of images you get with text search don't get included for searches for "big boobs" etc.

 

As John says - you're going to have to do full interception to get 100% performance - however we Smoothwall folk are working on a way to get more out of the HTTPS transatction without having to MITM, even in transparent mode. This may give us URLs - wether it lets us see search terms is site-dependant.

[Arthur]

Google have now moved their encrypted search page to a new domain: https://encrypted.google.com/.

 

Blocking this will not affect any other Google services.

[enjay]

I'm maybe missing something here, but what's the harm in people running an encrypted search? The results will still be filtering, so all we would lose is the ability to see what search strings people are using, and I can't say I have the time to go through our logs looking at that. Correct me if I'm wrong on this though...

[diggory]

I'm maybe missing something here, but what's the harm in people running an encrypted search? The results will still be filtering, so all we would lose is the ability to see what search strings people are using, and I can't say I have the time to go through our logs looking at that. Correct me if I'm wrong on this though...

 

Despite the best efforts of the grid filtering services and whatever web filters you have, google trawl a lot of sites, so blocking students searching for particular phrases is fairly useful in stopping them access to harmful sites, before they can find one that has escaped the filters.

 

Flash gaming sites are a harmless (usually) example of websites that constantly change their domain names to side step filters...

[enjay]

so blocking students searching for particular phrases is fairly useful in stopping them access to harmful sites, before they can find one that has escaped the filters.

 

Fair point, but do you have time to go through your web logs looking at all the search terms which people have entered?

[diggory]

No, but you can get a filter to block searches, like 'boobies' or 'flash gamez'

[pete]

Fair point, but do you have time to go through your web logs looking at all the search terms which people have entered?

 

No, but I do get a daily "top search terms", "top blocked users" etc report emailled from the proxy every day. So trends for things that should be blocked but aren't (or are blocked, but shouldn't be) show up pretty quickly.