Future of filtering

[mavhc]

With QUIC and TLS 1.3 and certificate pinning, what's the future of filtering? A per device monitor that can be at the other end of the encryption? Will laws have to change wrt byod?

[psydii]

Google do not approve of how corporate/education firewalls intercept and decrypt network traffic.

 

The Government will end up mandating a mechanism by which MITM certs must always work.

 

 

Facebook and Instagram have just moved over to TLS 1.3 and thus are accessible through previously secured filters.

[mavhc]

Google have 2 reasons for doing to: mitm boxes break everything, and other countries where the punishment for accessing anti government content is much worse.

[caffrey]

Be interesting to see any providers response to this - it's a bit quiet

[FN-GM]

For the time being you could disable TLS 1.3 support on the clients so it forces 1.2. But it will only be a short term solution.

[free780]

Safeguarding vs security. You'd think enterprise wouldn't be happy about no SSL Interception though. Maybe we will always have TLS 1.2 to support interception.

[psydii]

If you have a fully TLS 1.2 aware proxy *and* you don't exclude anything from your MITM attack, then you can protect against the threat of TLS1.3 bypassing the filter rules. Initially because TLS1.3 should fall back gracefully to 1.2 and laterly because over time MITM proxy/filter systems will fully support 1.3

 

The downside is that we'll all now be intercepting peoples banking transactions.

 

edit: A further downside is you've just broken apps that use certificate pinning.

Edited March 28, 2018 by psydii

[psydii]

@tom_newton and @SteveHill might have thoughts on this. Edited March 28, 2018 by psydii

[free780]

I'm sure everyone's interception exception lists are getting bigger and bigger. Unless interception is part of the spec of TLS its only a matter of time.

[Katy]

I'm sure everyone's interception exception lists are getting bigger and bigger. Unless interception is part of the spec of TLS its only a matter of time.

Definitely, not helped by the fact everything's "cloud hosted" meaning they all use the same set of domains (e.g. anything on AWS) so how do you then determine which is the education site and which isn't, when they also appear to randomly change...

[Arthur]

Unless interception is part of the spec of TLS its only a matter of time.

Interception is what delayed TLS 1.3 for four years.

 

www.theregister.co.uk/2018/03/27/with_tls_13_signed_off_its_implementation_time/

 

Also, Velvindron told us, while the signed-off TLS 1.3 included a resolution to the “middlebox controversy”, it could take a while for that to be implemented in the field.

 

Middleboxes – chiefly enterprise-edge traffic inspectors and packet filters – were one of the points of contention that helped delay TLS 1.3 for four years.

 

The IETF decided that systems like OpenSSL should ship with “middlebox compatibility” enabled by default. In this mode, the TLS 1.3 connection looks like TLS 1.2, Velvindron said.

 

“Assuming that the middlebox implements TLS 1.2 correctly, then the session goes through … it looks like TLS 1.2, but it's using TLS 1.3.”

 

That means, for example, that some of the worst aspects of TLS 1.2 – for example, that hackers could trick the system into reverting to an old and insecure ciphersuite – are plugged without customers having to undertake a large-scale upgrade to existing systems.

 

If there's anything wrong with how the middlebox implements TLS 1.2, the connection will break and users will get a warning, and Velvindron said some middleboxes will probably need a firmware upgrade.

[mavhc]

That's basically the problem with middleboxes: 1.3 will default to act like 1.2, boxes may have a broken 1.2, so they'll need an update.

 

TLS 1.2: 10 years old.

 

Which is why QUIC is designed to not let middleboxes do anything

[mavhc]

https://tools.ietf.org/html/draft-ietf-tls-tls13-22#appendix-D.4 is the middlebox section

[mavhc]

And DNS over TLS/HTTPS/QUIC will make simple DNS based blocking fail too

[caffrey]

I suppose at this point we don't believe the marketing, get something cheap in and if there is a safeguarding breach at least we say we did the best we could

[AlanD]

Yes, I don't see a bright future for smoothwall...or Sophos or any such premium filter provider if clients are essentially going to be invisible. BYOD devices have been capable of the invisibility cloak of a VPN for some time....with many schools not even realising this.

[mavhc]

Plus most of the kids have their own cell phone connection, so what are we protecting them from, high data costs?

[AlanD]

Plus most of the kids have their own cell phone connection, so what are we protecting them from, high data costs?

 

Most come with so much data ...and such high speeds...why would they want to connect to a restricted school wireless?

[gshaw]

Most come with so much data ...and such high speeds...why would they want to connect to a restricted school wireless?

 

You'd be surprised, loads connect to our BYOD Wi-Fi and I think they do it to save their data. It's a similar story with battery life and charging off of PCs etc. The contracts aren't as generous as you'd think, especially on the higher-end phones. Something like 10GB doesn't last long with lots of video.

 

As for the filtering it's becoming more and more of an issue, once again battling with e-Safe and Smoothwall clashing with each other doing two lots of SSL interception and that's before we get anywhere near Quic and certificate pinning. Also going forward from July Google are forcing most of the web towards SSL, even for sites that don't particularly need it so the problem will only get worse.

 

Chrome is also getting very fussy and flags certificate errors at the slightest provocation - horrible end-user experience when they change something but equally you can't stay on old versions because of the Flash patching. Stuck in the middle to some extent at the moment...

[tom_newton]

So, TLS1.3 will only cause us issues when 1.2 is no longer available - in that you won't be able to use "peeking" to determie the domain ahead of a decision to MITM. We've always been a client-first mitm though, and used SNI to determine the MITM rules, which should continue to work post 1.3.

 

I will agree that there's a limited shelf life on all technologies - and there's a tug-of-war between individual privacy and the needs of schools and businesses. IMO it would have been sensible to make trusted interception part of the spec - and much easier and more user-obvious, but what do I know

[mavhc]

What does client-first mitm mean?

[caffrey]

If I had the time I probably would just consider installing pfsense and squidguard it'll probably do just as good a job as it stands

 

Makes me do a double take on taking out 3 year contracts...

[psydii]

https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises

 

There’s two specific things that I think will have a negative impact on enterprise security.

 

The first is that it’s impossible to whitelist sites anymore because server certificates (the things that authenticate a site) are encrypted. So, your appliance will be unable to work out (for example) whether you’re communicating with your bank, or if malware on your machine is talking to its criminal masters, without breaking the connection. That wouldn't be a problem if you could break the start of a connection and then drop out when you find out it’s a low risk (or sensitive site). But that brings us to the second problem; you can’t do this in TLS 1.3. Once you proxy a connection, you have to proxy it until it’s done.

 

What this means is that enterprises will have to proxy each and every TLS 1.3 connection - whether they need to or not - and for the entire duration of the connection. This reduces the privacy of the employees in that enterprise, massively increases equipment and power costs, and probably increases overall technical risk for the enterprise and its employees. Clearly, that’s not a great outcome.

 

At the moment, this isn’t a problem as enterprises can just say that they’ll only support TLS 1.2, allowing them to continue managing their enterprise risk. However, it’s only a matter of time before some popular service adopts TLS 1.3 exclusively, at which point enterprises then have to make a choice about denying access, or losing the ability to manage their enterprise risk fully.

Edited April 4, 2018 by psydii

[caffrey]

Yep, all it would take is for Google services to adopt 1.3 and drop support for the others and it's game over for filtering I guess

[Wave9_Lee]

There are plans to deal with this from current vendors, but detail is sketchy at the moment. Some interesting articles on this :

 

https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00

https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/

 

It's fair to say that this isn't just of interest/concern to education users, all users interested in security will need this to be resolved.