SSL Intercept Legal and Acceptable Use Implications

[Opendium_Steve]

Since this thread has popped up again and I've got some spare time this afternoon, I've answered a bunch of old comments since I think they're still relevant and SSL interception (along with the advantages and disadvantages) is still not well understood.

 

Wondered how other schools handle this. I think staff should at least be informed of the intercept and acceptable use policies should also cover its use.

IMHO your ICT usage policy (which your staff and students agree to) should state that internet traffic may be automatically monitored and that this may include interception of encrypted communications.

 

Most filters would let you set different policies for the staff and students, so you could disable SSL interception for the staff. Obviously you need to weigh up the pros and cons and make a policy decision on exactly what/who you want to intercept - may involve explaining to non-technical policy makers exactly what's going on and why.

 

Does the use of SSL intercept break the T&Cs for some online services ?

I'm not a lawyer, but I would think that for services that the school itself does not subscribe to, T&Cs can only apply to the end users of a service, not a "man in the middle" such as the school or LEA running an intercepting proxy. For services that the school does subscribe to (e.g. Google Apps for Education), the T&Cs would apply to the school, but I would be surprised if the likes of Google care whether you're snooping on your own Google Apps traffic (I've not checked their T&Cs though).

 

Say your bursar uses online banking and doesn't realise they don't have an secure end to end connection to the bank are they breaking the T&Cs for online banking ?

I would hope that filters would exclude banking sites by default - ours certainly does, and as other people have mentioned, I believe the SWGfL only intercept Google for the time being.

 

We will be looking to 'intercept' search engines only. Is there a need to intercept all other traffic? I don't think there is unless I am missing something?

Depends on how your web filter works and what's on the web site. Consider the following address: https://www.example.com/games

If you don't intercept the traffic, the web filter knows that the user connected to "www.example.com", but there is no other information available. If you intercept it then the filter also knows that they accessed "/games" within that site, and can analyse the contents of the web pages.

So, if you know that the whole of "www.example.com" is good or bad you can choose to allow or block it without doing any interception. If you know that it's mostly good but there's one specific section you want to block (e.g. maybe you want to block the games section of example.com during lesson times) then you're going to have to intercept it.

Some web filters categorise websites based entirely on a big database of addresses, whilst others also analyse the contents of the web pages to improve the accuracy of their categorisation. For the former type of filters, you don't need to intercept; for the latter type, you're losing some of the filtering accuracy if you don't intercept (which may be fine, but you need to be aware of that limitation when you make the decision about what to intercept ). The modern web has a lot of dynamic content that is tailored to the individual users, so there is certainly a good case to be made for analysing what the user is actually seeing, rather than relying entirely on a predefined database of addresses.

 

Someone should talk to Google. They were concerned about the privacy of searches using the noSSL option. Now most insitutions are employing SSL intercept so searches are still not private, they are encouraging wider use of SSL intercept technology which can't be a good thing for the internet and wasting a great deal of time and money for all concerned.

However, with the old nossl option, anyone could (fairly transparently) intercept your traffic, whereas with SSL interception the user needs to have installed a certificate to allow this. I believe Google's main problem was unscrupulous wifi hotspot providers intercepting traffic, harvesting data, inserting adverts into search results, etc. That's not something that hotspot providers can consider doing if they have to intercept SSL traffic instead.

 

Google's SafeSearch doesn't do everything a school needs. We have a long list of terms that are filtered on top of SafeSearch. Things like self harm and suicide. As it is the main search engine used by everyone, its not that much effort really!

One of the things our customers make a lot of use of is having the filter report on any concerning search terms - picking up on search terms relating to self harm, etc. and being able to have staff intervene is a big deal, and something you couldn't do if you weren't intercepting searches.

 

Bit of a thread resurrection but was wondering what you're all doing about BYOD with SSL intercept? Do you basically say to users that they install the certificate or put up with constant security warnings?

This is what I've observed from our customers' approaches:

- Pretty much all of them do SSL interception on students' devices. Students are usually given instructions on how to sign into the school wifi, which includes instructions on installing the interception certificate. Sometimes ICT staff have to do a bit of hand-holding, but mostly this seems to work ok.

- Most do the same for staff, but some have decided that they won't do interception on the staff devices, so no certificate is necessary.

- Generally, visitor devices get some light filtering from a transparent proxy, with no SSL interception. So visitors can use the internet without any requirement to install a certificate or change any settings on the device.

- Whatever device you're using, some apps simply won't work with interception because they ignore the device's certificate store (this even applies to some of Apple's built in services on iOS devices, which can be quite badly behaved!) and our filters have a predefined list of web addresses that don't get intercepted in order to work around those problems. Every so often someone discovers a new badly behaved app and another address goes on the list and gets automatically pushed out to all the customers.

 

I don't think putting up with constant warnings is really an option - it makes the browser horrible to use, but more importantly would completely break some apps (which would opt to simply not work, rather than popping up a warning).

 

Android devices are a bit of an annoyance for some people, since they put a warning in the notification bar ("the network isn't private" or something like that) all the time when there's an interception certificate installed. You just have to learn to live with that. I'm honestly not sure it's a bad thing either - it's telling the truth, and it does serve to remind people that they should always be careful about what they're doing online.

 

I think mostly this comes down to grouping your users into separate networks appropriately (e.g. staff, students, visitors) and making sensible policy decisions about how much filtering (and therefore how intrusive) each group needs.