MX content filtering Support for QUIC & TLS 1.3

[ReginaPhalenge]

Hey everyone!

With the recent transition to using Cisco Talos Services for content filtering with Meraki MX, I'm curious about its capabilities. Can Meraki MX filter URLs using QUIC and TLS 1.3 protocols as well?

Thank you in advance!

[RaphaelL]

Hi, 

Not currently supported and I'm not sure that it will ever be supported too.

[pdeleuw]

The client sends its client hello with a server name indication (SNI). This is cleartext, no difference between TLS 1.2 and TLS 1.3. The MX sees the requested server and can decide if to block or to allow it. Patterns like www.foo.com/bar cannot be filtered if requested via https - regardless the TLS version.

So I do not see any difference between TLS 1.2 and 1.3.

[RaphaelL]

I'm not really an expert on QUIC , but from what I recall the SNI is encrypted in the payload. But you are right for TLS 1.2 and 1.3

[pdeleuw]

Yes, indeed, there is a difference between TLS 1.x and QUIC. QUIC already encrypts the first packet, the client hello, wich contains the SNI. But the encryption key must be known by sender and receiver. How should there be a key agreement for the first packet? This is why the key is known by a person in the middle and the client hello, including the SNI, can be encrypted. Of course, this is an additional load on the MX. I do not know if the MX supports this.

https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-server-name-indication-sni

https://www.opentech.fund/news/a-quick-look-at-quic-censorship/

One thing remains: 0-RTT. Both, TLS 1.3 and QUIC, allows for session resumption. The keys from a previous session are reused for a new connection. There is no TLS negotiation, the first packet contains the HTTP request. This reduces latency, but is obviously not optimal regarding security. 0-RTT lacks for forward secrecy. I assume, on many webservers this feature is disabled. Apache and Nginx have disabled 0-RTT by default.

Edit: Just a short test: Content filtering seems to work with TLS 1.3 but not with QUIC.

[RaphaelL]

Just a short test: Content filtering seems to work with TLS 1.3 but not with QUIC.

From what I could test ,  allowing UDP/443 will bypass your content filtering. The MX can't currently filter QUIC. I ended up blocking QUIC for security reasons.

[pdeleuw]

That's exactly my result. QUIC traffic is not filtered.

If you block UDP/443, you will block DTLS. If somebody wants to establish a DTLS based RA VPN (e. g. AnyConnect) through your firewall, the client has to fall back to TLS.

[PhilipDAth]

My understanding mirrors @RaphaelL - that SNI is now encrypted and not in plain text.

If this is the case, it won't be possible for for a device in the middle to see which web sites are being visited based on the https header.

Full proxy tunnels like Umbrellas SIG should still be able to do filtering.