Opendium_Steve

Did Symmantec not contact all of their customers? Seems pretty poor if not - this was announced 7 months ago. For what it's worth, FireFox will also distrust Symmantec certificates from next month.

Not convinced that much will change in the long term - GDPR introduces a few nice (as far as the consumer is concerned) new things, but the vast majority of it was already implemented under the Data Protection Act. I think most of the good of GDPR at the moment is that people are worried about the new scary law and are busy implementing things they should have already been doing. Once they realise that it's being enforced by the ICO, who have never been interested in holding anyone but the worst offenders to account, I imagine a lot of stuff will slip back to how it was.

A British government can certainly regulate how British companies behave on the internet and that's often a good thing. i.e. "you may not sell illegal drugs through your website" and "you may not use false advertising on the internet". But the government also has to be mindful of the fact that the internet is global and there is a tipping point where regulations become so onerous that businesses start moving overseas in order to avoid that legislation. Its obviously a lot easier to move overseas if your business is entirely electronic (but even where you need to ship physical products to the customer, businesses seem to be doing a pretty good job of flouting false advertising regulations by basing themselves in China). If the government had come along and said that porn sites must embed HTTP headers in their traffic to make it easier for parents to filter the traffic, I can't imagine there would be much push-back from the porn sites. It's easy to do, it doesn't affect the legitimate customers, complying makes the porn industry look more responsible and it doesn't introduce any data protection problems. No one is going to move their business overseas to get out of that. Obviously companies that are already overseas aren't going to be affected, but it would at least help a little bit with filtering the domestic sites. Since it wouldn't be especially controversial, there's a good chance that the rest of Europe and the US could also be convinced to enact similar legislation. On the other hand, introducing measures that will harm the porn producers' legitimate business and introduce a load of data protection problems is going to push producers overseas, and its going to be much harder to convince other countries to do the same. I do agree that the perpetual problem with the government meddling is that they don't understand technology and refuse to listen to anyone who does. I don't expect bosses to understand everything but I do expect them to listen to the people who do.

Well, Android always was pretty explicit (users with a cert installed got a "you're being watched" notification on every boot.) But I think the worst thing is that, as far as I'm aware, there's no way for even school-deployed Android 7 devices to change the "don't trust manually installed certs" default. (You have to rebuild every app package individually to change that, which realistically a school isn't going to be doing.)

I think the government missed a trick with the whole age verification thing they are pushing. Who's going to want to hand over credit card numbers, etc. to verify their age to a porn site? I think the age verification checks will become such a hurdle for the legitimate business of porn sites that they will start to move overseas to avoid the age verification legislation. It would've been far better to legislate that porn sites must be easy to filter (e.g. inserting appropriate HTTP headers, etc.), which wouldn't have got in the way of their normal business but would've allowed parents to have better control over what their kids can get to.

To be completely clear: the decryption methods that school filters rely on aren't going to be putting lives at risk. School filters require the users to voluntarily install inspection certificates, which I'm going to assume you're not going to do if an oppressive government asks you to. (And if the OS itself has been backdoored by that government, you're stuffed whatever you do anyway).

I think you're right... mostly There's certainly something to be said for basic filtering to stop people accidentally stumbling across something they don't want to see, but you're not going to stop someone who's determined to get to blocked things. Our focus these days is on the reporting side of things rather than filtering - that way you can relax your filtering rules a bit so they don't get in the way of education and use the reports to give you a heads up when you may need to intervene on a case by case basis. And certainly, kids need to get an education into how to use the internet safely, just as they would be educated on how to cross the road. After all, they will be on their own when they leave school.

A school is always going to have more control over their own connection than over 4G, etc. You just might not be able to get quite as much control as you'd like. Having the kids on your connection will allow *some* safeguarding, but obviously the school may be liable if someone is using the connection for something they shouldn't. It's certainly not an easy choice. I couldn't agree more, but unfortunately this is going to take engagement from everyone involved - schools and filtering providers are not going to be able to solve all of these problems on their own if the likes of Google and Facebook are actively working against them. If schools want to see this stuff fixed they need to pressure these companies by refusing to buy their services and explaining to them why. Unfortunately I think that any future legislation to force tech companies to help with schools safeguard kids will always end up bundled together with governments snooping on everyone, and quite rightly there would be a lot more push back on those kinds of laws than ones which are specifically aimed at helping to safeguard children in school. You don't need to undermine everyone's security in order to allow schools to safeguard children under their care.

QUIC and HTTP 2.0 both offer improvements in page loading speeds, so without those you *might* notice things being slightly slower. In reality I'm not convinced it's going to be a big deal. A filter is always going to add a small amount of latency anyway and all of this is likely to be pretty marginal. Client side stuff always has the problem that the kids will simply uninstall it (but then the filter can possibly detect that and block access to clients that have it uninstalled). Which is why the Safer Internet Centre's guidelines say that client-side stuff isn't good enough.

Some quick thoughts: QUIC Not really a big deal since things generally fall back to HTTP if you block QUIC (UDP port 80). But firewalls need to send a rejection rather than just dropping the traffic. HTTP 2.0 is a bigger problem. TLS 1.3 I haven't completely read up in the implications of TLS 1.3 so far. My understanding is that TLS 1.3 prevents certain types of passive inspection (i.e. decrypting the traffic after the fact by examining a recording of the network traffic), but doesn't prevent true man-in-the-middle decryption, which is what most (all?) school filtering systems use (but the filtering vendors are going to need to do some work to implement TLS 1.3 interception). In situations where you don't want to decrypt *all* the traffic, it does introduce some problems. Certificate pinning When done properly, certificate pinning isn't a problem. e.g. Google's certificates are pinned in Chrome, but that's fine because Chrome also trusts manually installed certificates to override pinning. Unfortunately many mobile apps simply distrust manually installed certificates entirely, rather than doing proper pinning. This means that your filter has to avoid intercepting HTTPS sessions made by those apps. To make matters worse, the apps often access web servers using use generic domain names, so your filters can't discriminate very well. i.e. the Facebook app accesses facebook.com, so your filter has to avoid intercepting requests to facebook.com, which of course also means no interception for normal web browsers accessing facebook.com. Its a shame the app doesn't use a separate host name such as app.facebook.com so the filters could tell the difference. Unfortunately, Google have become very anti-interception and made the decision to default to not trusting manually installed certificates in Android 7. Not a huge number of apps have switched to the new Android APIs yet, so this isn't yet a big problem, but it will become one. We have tried discussing the issue with Google via the IWF, since it directly prevents many of the child abuse images from being blocked, but unfortunately Google flat ignored us. Our current position on this is that schools will not be able to meet their safeguarding obligations if they are using school-owned Android devices, so unfortunately, buy Apple kit instead. That said, many schools already fail to meet their safeguarding obligations, and get away with it - its only going to come to a head when a school fails to prevent an incident that they should have been able to prevent. For BYOD devices the school obviously has much less say over what equipment is used - I'm afraid I have no good answers, other than to say that the device vendors need to step up to the plate and actually engage with schools and filtering vendors to ensure that safeguarding can still be done. So far, Google have ignored the problem and from what I'm told the US arm of Google is pretty uninterested in anything the UK arm has to say, even if Google UK did bother to look at the issue. Educational content hosted on generic AWS domain names Yes, it's stupid, there's no good reason for doing it (vendors can use their own domain names on AWS - no need to use the generic one) and I'm surprised that companies building content for schools are still doing this stuff. And don't get me started on the educational content providers that publish firewalling instructions that say "allow all traffic on ports 80 and 443" (most of our customers realise that this is a terrible idea, but occasionally someone does it, ignores all the popup warnings and then wonders why people's web aren't being filtered any more). HTTP 2.0 HTTP 2.0 allows connection reuse - if foo.example.com and bar.example.com have the same IP address and when you connect to foo.example.com it's certificate also says it'll cover bar.example.com, your browser will reuse the existing foo.example.com connection to make requests to bar.example.com. The upshot of this is that if HTTPS interception was turned off for foo.example.com, your filter will never see the requests to bar.example.com. This is particularly apparent on Google services where you have to disable HTTPS interception on some Google-hosted services in order to get Chromebooks to work, and those unintercepted connections occasionally end up being reused for things that you really want to be able to filter, such as image searches, etc. Again, the filtering vendors can only go so far - device/OS/app vendors such as Google, Facebook, etc. need to work with schools to help safeguard the kids rather than insisting that schools don't need to do any of that stuff. Note: I think there's a big difference between a school asking people to install certificates so they can safeguard a bunch of minors (with the support of their parents), and an oppressive government snooping on law abiding adults. Preventing the latter does not require the former to be prevented too.

As others have said, plenty of commercial cloud offerings. If you want something on-site, consider setting up a Jabber/XMPP server (its an open protocol so there are lots of options for both server and client software).

How do you know if the IP address is related to an allowed site? 1. You can do a reverse DNS lookup on the IP address. This almost never resolves to anything resembling the host name you're accessing the website on, so this method is pretty much useless. 2. You can do a forward DNS lookup on the host name the client is connecting to and see if any of the IP addresses returned match the address the client is connecting to. Unfortunately, its common for DNS replies to be used for load balancing purposes, which means each DNS reply has a different set of IP addresses. If everything handled DNS cache expiry correctly and you could guarantee that everything on your network only ever looks up through the same DNS server, you should be able to get away with this. Unfortunately, in the real world, you're dealing with devices hopping on and off the network, so a mobile phone may well sit on your network referring to DNS relies it received when it was last on 3G. Also, 99% of client software is badly written and doesn't expire ancient cached DNS replies. The upshot is that whatever IP addresses your filtering system thinks are valid for a particular web site are frequently totally different to the IP addresses that the client devices think are valid for that website. 3. Ownership lookups can tell you who owns the IP address (i.e. you can tell roughly which datacentre an IP address is hosted from). Very fragile - web sites move between datacentres all the time, so your filtering system is constantly going to be blocking websites whenever it gets slightly out of date. Not to mention that an awful lot of stuff is being consolidated into the cloud hosting providers these days (AWS, Azure, Google Cloud), which happen to also be where most of the VPNs are hosted. VPNs are a problem because blocking them without blocking a load of legitimate stuff is *really* hard - it isn't because the filtering providers are too stupid/lazy to bother blocking them. If this were easy, people in China wouldn't be able to VPN through the great firewall!

Firstly, your filter won't be decrypting *all* HTTPS traffic - quite a few applications use pinned certificates, which means they will break if you decrypt their traffic (can your school live without working Adobe updates, Skype, Whatsapp, many ChromeOS features, Facebook and Twitter apps, etc? All of these things are incompatible with HTTPS decryption). Similarly, you probably don't want it to decrypt banking sites for obvious reasons. So filters generally have a list of websites that they don't decrypt, and if the VPN can convince your filter that it is connecting to one of those websites then it won't be decrypted. Hotspot Shield is a good example here - it replays recorded HTTPS handshakes for legitimate connections, so it's very hard for a filter to know the difference between a replayed recording (i.e. the VPN) and the real thing (legitimate traffic). I wrote a blog article explaining in detail how Hotspot Shield gets through filters last year - it really is quite clever, and the authors probably deserve some respect for their ingenuity even if they are making our lives hard. Psiphon is a bit simpler, but doesn't mind decryption at all. It spoofs domain names so it isn't trivial to just tell your filter "block this domain", and does fairly normal looking web transactions with the servers. Unfortunately the "normal looking" web transactions contain an encrypted payload containing the VPN data. Your filter has to be able to figure out if that payload is VPN data or something legitimate. You're suggesting that a filter needs to be able to identify traffic from every single legitimate application that could be used and block anything it doesn't understand. That's pretty impractical - you're talking about it understanding the traffic associated with several million different applications, including every legitimate webapp your users may ever want to use. And that's before you have to deal with all the legitimate applications that encrypt their traffic and look identical to a VPN that's encrypting its traffic. Even if a filter did manage to do that, it would break an application every time the application vendor changes the way the app works. In short - almost nothing on your network would work and your users would be screaming at you to fix it... and you still wouldn't be protected against VPNs that manage to convince your filter that they *are* one of the legitimate applications. Imagine that you're given recordings of millions of conversations and you're told to identify anyone who is not conducting legitimate business based on what they are saying... except their conversations are being held in every language on the planet, not just English, and some of them are, quite legitimately, encrypting their conversations. Telling whether an application is legitimate is like that but many times harder.

Fair enough. But even if smoothwall come up with a solution for Psiphon, this will just rear its head again when the next VPN appears. Harkens back to the days when I started in the educational filtering industry a couple of decades ago. Schools expected a technological solution to a social problem: if a child managed to get to any porn after intentionally searching for it, that was almost universally regarded as "the filter's fault" rather than the child doing anything wrong. Thankfully things have changed a lot now and schools recognise that a filter isn't going to be 100% accurate and you need the social stuff to go along with it (education, discipline, etc.)

I don't have a lot of experience with MDMs I'm afraid. I was assuming you could do an automated "remove this app from every device" job once a day or similar. If not, I'm outta ideas :-/

I guess that's your answer then - they have already been warned and have ignored the warnings. I can understand not wanting to sanction the whole school, but if they are already on their second chance I don't see much option. A letter home to the parents maybe?

Although the MDM can't stop the installation of Psiphon, can you perhaps have the MDM automatically remove it if it is installed? (run this as a regular job and it's almost as good as preventing the installation in the first place). Regarding sanctioning 2/3 of the students, maybe arrange an amnesty: remove it from your device within a week and we'll say no more, anyone who doesn't gets sanctioned? (Clearly explaining that the amnesty is a one-off and anyone caught with a VPN in future will be punished).

Yes, and also the fact that these VPNs try their hardest to look like legitimate traffic. Anyone who says "our product can stop all VPNs, including those that haven't been invented yet" is selling you snake oil. Sometimes it may be possible to do traffic flow analysis to figure out which machines are using VPNs, but for the advanced VPNs there's no way an automated system is going to be able to figure out how to tell the difference between each VPN connection and each legitimate connection in order to block it without also blocking the legitimate stuff. The real test is how quickly a vendor can put developers onto the job and figure out a solution once someone has discovered a VPN that's getting through. Layer 7 deep packet inspection will get the low hanging fruit, but without the vendor constantly keeping on top of new VPNs it'll never stop the more advanced ones. Exactly.

Layer 7 deep packet inspection (DPI) is definitely worth having, and the main filtering providers all offer it on their filtering products. I would tend to do this kind of traffic control on your internet gateway device - Meraki seem to be doing it on your core network switches, which just seems like a very odd place for it. DPI catches a lot of the "low hanging fruit", but certainly isn't a magic bullet. The big problem VPNs of recent times try really hard to make their traffic indistinguishable from legitimate traffic, and this will fool all of your filtering. Once you've identified that a VPN is getting through the filtering, your filtering provider then needs to put in the development effort to analyse the traffic, figure out how to fingerprint it so it can be blocked. And since it looks almost identical to legitimate traffic, identifying and blocking the VPN traffic without causing a load of collateral damage by blocking legitimate traffic too is really difficult. The last two VPNs we analysed were Psiphon and Hotspot Shield. Of these, I'd say that Hotspot Shield was probably the hardest to deal with, and to give you an idea why, I'll briefly describe how it works: 1. The VPN client connects to an IP address on port 443 - these IP addresses are hosted in popular cloud services, there are vast numbers of them and they change regularly. So blocking them isn't really an option. 2. The VPN client and server exchange HTTPS handshake traffic which has been previously recorded from the network traffic generated by a legitimate client accessing a legitimate website. The VPN system contains a large number of these recorded handshakes, changes them frequently, and since they are identical to legitimate HTTPS handshakes, you can't block the connection based on anything they contain. 3. As far as anyone snooping on the traffic (such as your switches or filtering system) knows, an encrypted connection has now been set up based on that handshake traffic and anything that follows would normally be encrypted with the associated keys and therefore unsnoopable. However, there is no way for the snooper to verify that the traffic being exchanged is actually encrypted with the appropriate keys (since the snooper doesn't have access to those keys). So in actual fact, the VPN client and server can send any traffic they like, and that's exactly what happens. To a passive inspection system, this traffic is indistinguishable from legitimate traffic and therefore you can't block it without also blocking the legitimate application. Of course, if you man-in-the-middle the HTTPS session, the VPN client can't connect. Unfortunately, because of certificate pinning, you can't man-in-the-middle every HTTPS connection, and eventually the VPN client stumbles upon something you didn't intercept and successfully connects. There is absolutely no way any kind of filter is going to automatically block that traffic without also blocking all the legitimate traffic - it requires a developer to spend time figuring out how the VPN is working and come up with a way of blocking that traffic without impacting legitimate browsing. Anyone who tells you "our system can magically block any VPN which is invented in the future" is selling you snake oil - the real test is how quickly a vendor can react and develop a solution once a new VPN has been identified.

Oh, one thing I did mean to mention - obviously web traffic goes through your web filtering system, but you often need to poke holes in your firewall for other protocols. Make sure that any holes you poke are either restricted to specific destination IP addresses (e.g. allowing traffic to 17.0.0.0/8 is a common and fairly safe one since that whole network is Apple's), or the ports you open are protected by layer 7 deep packet inspection. Any ports you leave wide open that haven't got these protections will very quickly be abused by VPNs - I've seen NTP and DNS ports being used by VPNs, amongst others (we tend to intercept DNS and NTP traffic and redirect it to local servers instead of allowing it out to the internet).

No problem - we always try to be honest, even when the answer may not be what you wanted to hear! Did they say anything of substance or did they just wave the problems away as non-issues? I think it depends what you want to get in terms of safeguarding. Whether or not the school does BYOD, students *will* use their own phones, you just get to choose whether they are using 3G/4G or the school's network. So you can avoid BYOD entirely, let them use 3G/4G and wash your hands of the issue - if it doesn't happen on the school network, it isn't the school's problem. This obviously means you may miss safeguarding opportunities since you have absolutely no control over their internet access. Or you can offer a BYOD scheme and accept that you're not going to have complete control - this gives you some scope for blocking the worst stuff and allows some monitoring for safeguarding purposes, just possibly not as much control and monitoring as you'd like. On the other side of the coin this has the potential for opening up the school to liabilities when a student uses the internet inappropriately, because the connection is now a service the school are providing rather than the parents' responsibility. These are hard questions and I don't have any easy answers I'm afraid, but this is the balancing act we all have to play.

We managed to figure out how to block Psiphon a few weeks ago and according to the customers the filtering is working ok for now. It is a game of Whack-A-Mole though - each time a VPN client comes along we have to drop everything and figure out how to block it. The previous one of concern was Hotspot Shield, which was quite difficult to block without causing too much collateral damage. I don't think you're going to find a purely technical solution to the problem of VPNs though. I think you have to attack the problem from multiple angles: Ensure that there are serious repercussions for anyone caught using a VPN. If there's no penalty for getting caught, why wouldn't the students try it on? With school controlled devices, use the MDM to prevent random VPN apps from being installed if possible. Also, use the MDM to identify users who have installed VPNs onto these devices and punish them. VPN use also needs to be rolled into the school's internet safety education. A discussion with the students about the safety implications of VPNs could be useful: they may be bypassing the school's antivirus filtering; how trustworthy is the VPN provider, given that they can snoop on all of the students' traffic? etc. A recent incident highlighted to me that the "you must not bypass the school's filtering" clause in an acceptable use policy isn't good enough even for students who want to play by the rules, because they often just don't think enough about what they are doing. A student was caught using a VPN and when it was pointed out that they had agreed not to bypass the school's filtering when they signed the AUP, the student said "I wasn't bypassing the filters, I just wanted to use Facebook [which is blocked during lesson times]". For what it's worth, Psiphon sends POST requests to https://.psiphon3.net/ with a user agent of "Go-http-client/1.1". Blocking these requests doesn't stop it from working, but you should be able to use them to identify devices that have Psiphon installed. Also consider whether your filtering is too restrictive - if you block too much, you push students into using VPNs and 3G/4G and lose any chance you have of safeguarding them. On the other hand, if you're less restrictive they may be able to get to some slightly iffy sites (which they would've got to anyway via VPN/3G/4G) but by keeping them on your network you retain some ability to block the worst stuff and safeguard them by monitoring their access. And yes, I'm afraid everything's going to get a whole lot harder with the rise in popularity of certificate pinning along with Google making a concious decision to make Android 7 incompatible with HTTPS interception. It is particularly concerning that Google have completely ignored our attempts to open a dialogue with them on the issue, even when we tried to discuss the issue through our contacts at the IWF.

I'm afraid I'm not sure how proactive the police are in getting this stuff taken down at source.

As a filtering supplier, I'm in the unusual position of being able to see specifically what is on the CTIRU list. I can't go into details, but there are about a couple of dozen links listed on that domain. Obviously you need to balance up the risk of someone visiting any of those links against the utility of accessing legitimate resources on the same domain. As a point of comparison, there are a couple of thousand Twitter addresses on the list, but I doubt anyone would block the whole of Twitter for radicalisation reasons (although there are plenty of other very good reasons to block Twitter . The other thing to consider is that the false positives caused by the whole domain being blocked reduce your ability to meaningfully report on which users may be at risk of radicalisation.

Whether or not to intercept is usually a separate question to whether or not to block. I think most people would say that intercepting banking stuff would be unwise, just because the school could end up storing financial data and may become liable for any money that is lost if their systems were compromised in the future. (I wouldn't like to say whether or not someone breaking the AUP would affect the school's liability in that case).