Opendium_Steve

A very simple solution would be for YouTube to stick the "rating" and unique video ID in the HTTP response headers of any request relating to a video. That way, your local web filter could allow everything with a "clean" rating, but also allow/block other videos based on its own list of approved videos (which could, of course, be updated by the school's staff). You'd need to intercept the HTTPS traffic, but most schools do that anyway so it isn't a big deal.

That just places restrictions on users who aren't logged in to Google Apps. Once you're logged into Google Apps, your access is controlled by your account settings (which are set by your Google Apps domain administrator). But there doesn't appear to be anything to force users to log into one specific Google Apps domain, so users could log in to a different Google Apps domain, if they have an account in one. So this isn't a bullet-proof setup, but it may be "good enough" since users would have to jump through some hoops to create their own Google Apps domain.

One of our customers on the SWGfL has been having ongoing problems with the Grid's DNS servers - querying the server (10.80.11.235) for AAAA (IPv6) records within the cloudapp.net domain takes a very long time before eventually failing. They have raised the problem with the Somerset ICT guys over a month ago, but so far they've done nothing to resolve it. We've explained how to test the problem and offered to help, but it seems to be going nowhere at the moment - we can reliably reproduce the problem within a few minutes, and have confirmed it with several different customers who are on the SWGfL, but so far Somerset have said they can't see a problem. Is there a path to escalate the issue to someone technical enough to understand and resolve the problem?

That's true. Would need to check the Google T&Cs though.

Yep, our development team have implemented and tested support for it already and the update will be going out tonight. This is basically how it works (from my experience testing it - Google haven't exactly published great documentation): Firstly, you force YouTube into "Restricted Mode" (either with DNS tricks or through your web filter). Anyone who isn't logged in with a Google Apps account will only get to see restricted content - this is essentially the same as YouTube's old Safety Mode. Safety Mode was always a bit too aggressive at filtering for most people to find useful, and I don't expect this to have changed. The difference between the old "Safety Mode" and the new "Restricted Mode" is that once you're logged into a Google Apps account, what you can see is controlled by that account's settings (which are set through the Google Apps admin dashboard) - so you can set some users to still be restricted, others to be unrestricted and you can say that some users are allowed to approve videos. Approved videos can be viewed by all the users who are logged on with accounts in your Google Apps domain. Gotchas that are immediately apparent from this change: - You're going to need to subscribe to Google Apps and have accounts for every user. - Users will need to manually log into their Google Apps account unless you've set up single signon stuff (I have no experience of setting that up - looks complex, although someone may correct me?) - There appears to be nothing stopping a user logging on with a different domain's Google Apps account, which you wouldn't have control over. My take on it is that it's a bit more powerful than the old YouTube for Schools, but a lot more effort to set up unless you're already using Google Apps (but was presumably designed to push people into using Google Apps, but that might just be my cynicism )

Its similar to how Google already recommend forcing safe search, etc. (We actually do it by rewriting the HTTP traffic rather than inserting bogus DNS records, but that's not the approach that Google suggest)

Yes, not really sure how that works - it says to create CNAMEs to restrict.youtube.com, which I guess would probably stop people using youtube without logging in (?), but what's to stop them logging into an account you don't control? Testing required to figure out how it works

The Youtube for Schools signup system has been broken for at least a year - seems pretty clear that Google aren't interested in supporting it. I think people who are already signed up can still use it, but Google could pull the plug entirely at any moment...

I haven't got a presentation, but I hope this explanation helps a bit: A traditional web proxy sees all of the unencrypted data that goes between the browser and web server. This includes the full web address the client is requesting, any data the client is submitting (e.g. the contents of a form, any files being uploaded, etc) and any data the server is sending the client. Most web filters look up the requested web address in their internal database and decide whether or not to allow access. Some web filters also analyse the data being sent and received. When you access an encrypted website through a traditional web proxy, the web proxy/filter can only see the host name part of the web address and none of the data being sent/received. Web filters can still do some filtering based on the host name, but this obviously isn't as good as knowing the fill address, and they can't do any analysis on the data. Some clients also insist on connecting to just an IP address, rather than a host name, and that is something that can't be sensibly filtered. An increasing number of devices (iPads, etc.) have very poor support for traditional web proxies, so many filtering systems also provide a "transparent" proxy, which does not require any direct support from the browser. The browser thinks its talking directly to the web server, but the connection is really being intercepted and redirected to the proxy/filter. When accessing an unencrypted website through a transparent proxy, the proxy/filter can work in pretty much the same way as the traditional non-transparent proxy/filter does. Real problems come when you try to access encrypted websites through a transparent proxy - the proxy/filter only knows the IP address of the web server. The host name, web address and any data being sent/received are encrypted and therefore can't be examined by the filter. Some filters are able to examine the SSL handshake to retrieve the host name of the web server without doing full "man in the middle" decryption on the encrypted traffic. As more and more services move to using encryption as standard, just having the host name of the server isn't good enough to make a reasonable stab at filtering. The solution here is for the filter to become a "man in the middle" - the browser connects to the proxy/filter, which pretends to be the web server, and the proxy/filter pretends to be the browser and connects to the web server. Secure webservers present a certificate to the client so that the client knows its talking to the real web server - the proxy/filter needs to forge the web server's certificate, and this requires the browser to have already been told to trust any certificates issued by the proxy (by installing the proxy's certificate on the browser, either manually or through something like Active Directory). The advantage is that the filter works just as well when accessing encrypted websites as it does when accessing unencrypted websites. The disadvantages are that you need to install a certificate on every device, not all applications will bother to use that certificate, and you could end up decrypting sensitive data (e.g. banking transactions). For these reasons, you have to exclude some websites from being decrypted and just accept that those sites won't be filtered.

This was announced last year and the forcesafesearch VIP has been active for a year or so and is working well. Originally the nossl system shutdown was supposed to happen some time in January (from my recollection), but was postponed. I'd guess that a lot of schools were caught off-guard and asked Google for more time to prepare. My understanding is that the nossl system was being widely abused by wifi hotspot providers to snoop on users' traffic, inject ads into Google search results, etc., so its pretty understandable that Google have moved to shut down those kinds of abuses. I was amused we got some free publicity from Google in the form of the Wikipedia link anyway.

Not Smoothwall, but our clients mostly use the same filtering settings for students whether they are on wifi or on a wired workstation (by having the device authenticate as the student's normal account - that way they still get audit logs for each user), although restricting some categories and relaxing others for some time periods is quite common (e.g. allowing social networking and tightening up porn filters outside of lesson times). I think you will have real problems trying to use BYOD devices through a whitelist - Modern tablets/phones unfortunately expect to be on a fairly unrestricted connection and access a wide variety of online resources in the background during normal operation. Restricting those resources tends to cause the devices to misbehave in unexpected ways and you'll probably have to spend a great deal of time maintaining the whitelists in order to keep everyone's devices working reliably. I'll also say that support for proxy servers is pretty poor on the current tablets/phones, so transparent filtering is de rigueur. Guest wifi for non-student visitors (parents, contractors, etc) is often set up with some extremely light filtering (e.g. no authentication or HTTPS interception) to keep the filtering as transparent as possible so that the devices need no extra configuration.

Looks like Methodmaths' web server is badly configured to me - their server is set up to allow HTTPS connections, but the certificate they are presenting doesn't match their domain (it belongs to sgvps.net). They should either use the correct certificate or turn off HTTPS on their server entirely. Depending on the web filter you're using, you can probably block HTTPS yourself to work around this problem, although using HTTP to send authentication credentials shouldn't really be encouraged.

Out of interest, do you mind saying who that was? - I've not heard of anyone going out of business on the grapevine yet.

Install Firefox's Firebug plugin, go it its "Net" tab and reload the page - you should be able to spot any objects that are failing to load.

I think the app uses googleapis.com instead of youtube.com. Unfortunately redirecting it to forcesafesearch doesn't work and I've not seen any documentation relating to doing this for the app. On the other hand, Youtube's Safety Mode seems to be extremely aggressive, blocking an awful lot of completely innocent videos, so it seems that a lot of schools simply don't use it at all...

The certificate chain on both of those looks fine to me: Certificate chain 0 s:/serialNumber=8zNjMBehFD3Tbe0sezmihZ-h-hfwCArp/OU=GT17759042/OU=See http://www.rapidssl.com/resources/cps ©13/O U=Domain Control Validated - RapidSSL®/CN=*.imrworldwide.com i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 2 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA and: Certificate chain 0 s:/C=US/ST=California/L=San Jose/O=Adobe Systems Incorporated/OU=Adobe Marketing Cloud/CN=*.112.2o7.net i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA My guess would be that your Smoothwall doesn't think the certificate chain is valid when it does its HTTPS interception - maybe its root certificates are out of date - I assume all other https sites work fine without the browser showing certificate warnings? imrworldwide.com is registered to The Nielsen Company (no idea who they are), 2o7.net appears to be owned by Adobe. I guess you could try whitelisting those so they don't get decrypted by the Smoothwall.

The quick answer is: it doesn't Using captive portal or WISPr authentication on their own is only really suitable for single-user devices (e.g. phones, tablets, etc), where the device appears on an IP address and you know that every web request from that IP for a significant period of time (say an hour or so) is going to be from the same user. Kerberos, NTLM and HTTP Basic authentication all authenticate every connection to the proxy server individually, so they are more suitable for multi-user devices. All the major desktop web browsers support one or more of these methods, although support from non-browser software is a bit hit and miss. The solution we settled on a few years back is to use a hybrid of these mechanisms, authenticating every connection where possible, but falling back to cached credentials when dealing with software that doesn't support this. Its proven pretty reliable in most situations, although one place the hybrid system doesn't work well is a remote desktop situation (multiple users using the same device at exactly the same time) - the only way to handle that is to either authenticate every connection individually, or to forget about tracking individual users on that device and just set some fixed filtering that applies to all its traffic.

Try it from Firefox and install the Firebug plugin. The "Net" tab of firebug shows all the web requests that are made, so you can see if any of them failed. In theory it should show you the same stuff as the Smoothwall log, but you never know so it's worth double checking.

I've PM'd you a more complete answer because I don't want this to appear to be an advert (which wasn't the intention), but briefly: It's unfortunate, but there isn't a perfect solution for authenticating users - standard basic proxy authentication used to be pretty reliable, but it seems that increasingly lax software development has left a lot of new software with either broken or nonexistent support (I'm looking at you Apple/Google! ). We mostly use Kerberos authentication for Windows machines that are on the Windows domain, and this is pretty good and doesn't involve installing a client (you do need to enable proxy support on the workstations, but that can be done very easily through active directory). Workstations that are off the domain and non-Windows workstations end up using a combination of basic proxy authentication, WISPr and a captive portal - mostly this works ok, but there are occasional down sides.

As other people have mentioned, Google searches now go over HTTPS, and the old nosslsearch.google.com DNS hack that everyone used to use to force searches onto HTTP has been replaced with forcesafesearch.google.com (turns safe search on, but the search itself still goes over https). Our servers analyse the users' Google search queries by intercepting the HTTPS session. Basically, the proxy forges the certificate - clients need to have the proxy's certificate installed in order to accept the forged certificates. Have a look at Squid's "ssl_bump server-first" configuration options.

Hi, I'm Steve and I'm the Technical Director at Opendium Limited (and also a software developer . I've been dealing with web filtering stuff for schools for 15 years and have plenty of hands-on networking experience. Having been lurking on the EduGeek forums for a while I figured it would be a good idea to actually join.

We get a lot of really good feedback on our filtering products from our customers, but I'm curious about folks using other systems - what do you guys really like about the filtering systems you're using, what do you hate, how could they be improved? (Sorry if anyone feels this thread is inappropriate - I've been lurking on the forum for a while and decided there was no better way to get opinions than to just ask.)