Google SSL Search
For those that aren’t aware, Google made an announcement earlier this month that seemed to go unnoticed for a little while – an announcement which has fairly serious repercussions for those involved in content filtering and monitoring. Â Google have announced that from some point in December, all Google searches will be made over a secure connection.
This change which was dealyed has now been confirmed for the 23rd of June 2015 -Â Link
Google have been under immense pressure for some time to go extra lengths to protect users privacy – a move I generally believe in. Â Where practical we should be able to secure our interaction with a service to ensure our stuff is safe and the organisations we entrust should do everything that is reasonable to ensure that they play their part. Â However it’s not always as simple and straight forward as that…
Those of us tasked with the responsibility of ensuring young people’s use of the internet is ‘safe’ (explore my blog for more thoughts on what is safe, and how sometimes we need to expose young people to a small amount of risk) this poses an issue. Â If the connection is secure between the service (google search) and the user (a pupil) the technology between the two can’t see what the user is requesting. Â This is the same for any secure only site. Â So if you allow you users to access twitter for example, you can’t block https://twitter.com/UserIDontLike.
You have to go all the way back to 2011 to find when Google announced that most searches would be completed over a secure connection (SSL). Â However at that time they also came up with a fix for those not fully comfortable with Google’s decision. Â Through a change in a DNS server, you can force all computers on your network to nosslsearch.google.com when the user requests google.com. Â Many organisations won’t realise this was going on because the end user doesn’t see any difference, except for the lack of an ‘s’ and a padlock.
Using theÂ insecure example search above your filter can see quite a bit of information, and determine whether itÂ is going to allow the result or not (as well as log the request). Â They can determine if the domain (google.co.uk) is allowed, they can determine if the query is appropriate (q=google+blog+announce+only+secure+search) and they can also see that safe search is implemented (safe=active). Your filter will use these and numerous other paramators to block or allow the request.
When a user makes a secure search, the information after the domain (google.co.uk) is encrypted, and therefore hidden from the filter. Â It’s filtering results are now black or white – is google.co.uk allowed or blocked? Â Furthermore, the filter isn’t able to log much either.
Depending on your filter of choice (or the one that someone else chose for you) and how that filter is implemented, thereÂ might be more the filter can do and I’ll talk about that a little later in the post.
Googles safe search is unaffected by this change. Â There is another DNS trick that you, or your provider can implement to ensure safe search is active. Â However those of us who regularly scrutinise google results probably won’t find too much comfort in that. Â Which brings me onto google images…
When a user searches for a google image most filters are able to examine the URL where the image comes from – not because the image is displayed directly from the host site, but because of the way google shows the originating URL in the google URL. Â In the case the image is hosted on turnoffsafesearch.com and your filter can probably determine whether this domain is blocked or not and whether the image should be shown.
Schools need to decide how comfortable they are with the google changes, andÂ come to their own decisions. Â Some will have local authority or commerical suppliers who will make that decision for them. Â If you are the decision maker, here are a few options…
You can assume that Google’s own safe search is doing enough to safeguard your users. Â Review regularly and be prepared to reassess that decision.
Full proxy based filters can probably view the secure traffic as it is. Â Clients configured to use a proxy expect that the encryption is not as it should be and therefore don’t flag a security risk to the end user. Â This however isn’t easy to implement to none owned devices, I’ve blogged before on mobile devices and proxies.
Transparent proxies sit (supposedly silently) between the user and the service. Â However the device is expecting a secure connection, and the certificate meant to secure the connection gets mangled by the proxy. The device throws up it’s hands and warns the user that the connection may not be as secure as they thought it wasÂ – which of cause, it isn’t. Â To rectify this issue, you can get your own secure certificate, and install it to your filter – unfortunately it will still need to be trusted by your devices – easier on devices you own, much harder on others you don’t.
You might decide to proxy just google traffic, and leave other traffic to go via your normal route. Â A wpad.dat file would help here, but again it’s no magic bullet.
Or you could block Google search…
I think Google need to offer more of a solution for those of us tasked with safeguarding. Â I’d like to see a Youtube for Schools type solution personally. Â Allow schoolsÂ to register and enable us to make an informed choice for ourselves, with the best interest of our users at heart and adaptable to our current technology.
- Bloxx -Â Bloxx Products & Google Safe Search
- e2bn -Â Google to withdraw nosslsearch option
- Lightspeed -Â Update on Google Encrypted Search
- RM -Â Important issues affecting your filtering service – requires your attention and action
- Smoothwall -Â Important Information for Customers Filtering Google Searches
Padlock image licensed under Creative Commons 2.0 Â – Attribution 2.0 GenericÂ https://www.flickr.com/photos/mssarakelly/10248675643