Anybody else been taken by surprise as Google applications (Gmail, Picasa, Docs etc.) failed to work this morning? Found the article on the website explaining why they've done it (SSL searches on Google bypassing the filters) so appreciate why they've done it, but why do we only seem to find these things are happening afterwards, or is it just me?!
there is guidance that has been sent out by SWGFL regarding this, together with advise on what do regarding getting the block removed if required
We should have been sent the email notifying of this last week, but only received it today after complaining that our Google Apps services had all been filtered. Even if I had seen the email I wouldn't have realised that 443 would be blocked for every Google service.
I'm a bit stuck now, I've spent the last our testing squid rules, there doesn't seem to be a way to stop Google SSL searches without also stopping Google Apps. The both use the same domain name and the same port number.
Are there any options to work around this?
We got an email from Gloucestershire CC about it, but it was sent to the school's admin email adderess so it took a while to cross our desk.
Somerset CC sent out information about it this morning in their weekly bulletin (which I don't get, but someone in the office down here does).
Hi Folks. I've heard similar rumblings from E2BN and elsewhere in the country. Google have really put the cat amongst the flying rats here...
As we see it, there are 3 methods to remedy the filtering concerns:
1. Block google.com HTTP&HTTPS.
2. Block google.com HTTPS only.
3. Full HTTPS interception.
Methods 1 and 2 will break any web app that requires a Google Accounts logon and kill google.com in general. Boo :-(
Option 2 is lesser impact - it still allows search, toolbars, and custom search etc. to work properly over HTTP.
Option 3 is the most comprehensive - it allows your filter to work "as normal" with Google - just like 2 weeks ago :-)
We will be publishing a white paper on this topic Very Soon TM, but our current best practice advice for those of you with in-house smoothies is Option 3 - HTTPS interception.
Cheers all, have received copy of email via unofficial channels. Looks like the good old Smartcache is flummoxed again, bless it. Definitely looking like a secondary solution will be needed at some point (naming no alternatives (cof smoothwall cof)), or a serious clampdown on anybody found using https to access Google which at least I can do at moment...
Found this on the SWGfL website.
South West Grid for Learning Trust - GoogleSSL
diggory (25th June 2010)
Have you tried poking it, it's a simple being without aggression, which in my book makes it an idea candidate for poking.Originally Posted by hudzen76
I had notification of this during half term, with the 'public' notification (to the headteachers) happening last Tuesday along with the confirmation that it was going to happen.
It's a bit of a pita, but all the same it had to be done.
In B&NES we knew about last week BUT what SWGfL didn't tell us was that the filter is at the top most level so even our unfiltered 'net feed is filtered from Google applications that use https! :-|
Is it just google.com that's running on https? We redirect google.com to google.co.uk
That was the only reason I noticed it (I'm a B&NES Chap myself), as Staff complained that they couldn't get to there personal emails at lunch.
I'm not quite sure what to say to them on that, apart from 'tough' and you'll have to wait!
Yes, but a redirect won't work on https - to varying degrees.
Either the redirect won't apply to the encrypted traffic, or if it does, you'll get an HTTP certificate mismatch. You can't reliably redirect HTTPS->HTTP, except perhaps via MITM, which obviates the need for such tricks in the first place.
OK, starting to get updates through on email now; they did manage to link to a blocked site the first attempt, though - say no more...! Text of Google blog below...
-------------------------
An update on encrypted web search in schools
Monday, June 14, 2010 at 8:59 AM
We recently launched a beta version of encrypted (SSL) search at https://www.google.com to prevent people from intercepting our users’ search terms and results. However, because encrypted search creates an obscured channel between a user’s computer and Google, users who go to https://www.google.com can bypass some schools’ content filters. This can make it hard for schools to stop students from accessing adult content.
One option is for schools to use our SafeSearch lock feature, which is designed to help keep adult content out of our search results. But given how many computers some institutions have this is proving impractical in many cases. So to prevent students from bypassing their filters, some schools are blocking encrypted search. However, a side effect of this action is that it also blocks other services hosted at Google’s secure URL, including Google Apps for Education, and many of our other services which require authentication to keep information safe.
We’re working hard to address this issue as quickly as possible and in a few weeks we will move encrypted search to a new hostname – so schools can limit access to SSL search without disrupting other Google services, like Google Apps for Education. Longer term, we are exploring other options like moving authentication to its own hostname so that we can return encrypted search to https://www.google.com.
Safety and security matter to Google, and we are committed to working with our partners in education so that we help keep students safe and secure on the Internet.
Posted by Dave Girouard, President, Google Enterprise
-----------------------------
diggory (25th June 2010)
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote