Feature request - DNS Web Filtering

Current implementation: HTTPS with no scanning does categorization using the FQDN from the SNI. It can block via webpage (and certificate) or by dropping the connection. We do not do categorization/blocking on DNS requests. The practical difference between the current solution and DNS is that we currently can log/block all FTP/HTTP/HTTPS connections to sites in any given category, however a DNS solution would apply to other connections/ports as well. The problem with DNS categorization and filtering is that it is easy to bypass. A device with malware can use a local hosts file. A device with someone bypassing filtering can use google's DNS servers.
ATP does work on DNS (in addition to the web proxy), however it is designed to only catch callhome domains (infected devices connecting to known command and control sites).

If your concern is HTTPS, I fail to understand what DNS filtering gets your that the current HTTPS proxy (with scanning off) does not get you. Can you explain?

1) What about the current solution does not allow you to do this? Set up a URL Group or Custom Category for your whitelisted messaging FQDNs, create a web policy that allows the whitelist and blocks everything else. Create a WiFi SSID for "Guest WiFi (Locked Down)". Create a firewall rule for that network that goes to that web policy, no HTTPS decryption. Anyone who connects can access your allowed things no problem. If they try and access anything not allowed they'll get a block page (HTTP) or a certificate warning (HTTPS)/dropped connection (as per config).

2) Agreed. Again, I'm not sure what about the current solutions does not allow you to do this, though it may be painful to do. AFAIK IoT is on our radar.

3) I cannot speak on the reporting/alerting side. The data is there in the web proxy reporting.

Wishlist:

1) I know I can, but not via command line. This is more about preferred way of working.

2) I cannot speak on the reporting/alerting side.

3) You can do via web proxy, not DNS. Again, if the concern is HTTP/HTTPS why do you need DNS? And how would this deal with anyone who chooses to use any other DNS provider?

4) Agreed, somewhat. You can whitelist via exceptions using RegEx, though this applies to all policies. Whitelist/Blacklist via URL groups or custom categories has some wildcarding but is not RegEx. There is a problem of this legacy of several ways of doing things and we'd rather not introduce a new, additional ways. Coming up with a solution that works for what we want and also maintains that upgrades with pre-existing stuff still behaves the same is difficult.

Whitelist/Blacklist KB community.sophos.com/.../127270

Thanks Michael , you've made some good points .

Just a question now that TLS 1.3 is effectively upon us.

Can you still filter BYOD devices via SNI  without decryption ? 

Thanks Michael , you've made some good points .

Just a question now that TLS 1.3 is effectively upon us.

Can you still filter BYOD devices via SNI  without decryption ? 

I just had a quick lesson in TLS 1.2 and 1.3 Client hellos.  :)

In short - SNI is still sent plaintext in TLS 1.3.  There is an extension that allows for encrypted SNI but no one is using it (yet).  The handshake for TLS 1.3 looks like the handshake for TLS 1.2, which makes it backwards compatible.  But a handshake for TLS 1.3 with encrypted SNI, looks to a TLS 1.2 server as a handshake with no SNI at all, something that many TLS 1.2 servers wont like.  Proper encrypted SNI also requires you to use DNS-over-TLS.

Effectively, if a client uses encrypted SNI, that client is TLS 1.3 only.

When using the new DPI mode, TLS 1.3 is fully supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) then it lets the connection through to the server, inserting itself into the encryption (using the XG CA), to redirect the client to a page on XG:8090 containing the real block page. 

When using the proxy mode, TLS 1.3 is not supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) it will pretend it is the server and that it only supports TLS 1.2.  It used the XG CA to display the block page.

tl;dr answer:  SNI is unencrypted and both DPI and proxy mode work fine.  It will remain like this until clients and servers decide backwards compatibility no longer matters.  Let me know the lag time between the IPv6 standard and non-test websites that only support IPv6.

https://blog.cloudflare.com/encrypted-sni/

Thanks Michael for at least considering this. With the new DPI mode from what I understand it can also intercept non standard ports ( ie non 80/443) I take it ? That's one of the other issues I've faced , in that a lot of these devices are using nonstandard ports like  8443 , 8180 , 8880 to connect to some web api socket for data streaming.

DNS Filtering isn't an I win button , but if you layer it up with port ranges , APT , address lists/web categories it works pretty well. Effectively the "dumber" , "unmanaged" or "blacker" the box the more we tend to need it.

Especially now that we can force to do redirects to the XG's DNS server (Page 52 of the EAP1 PDF) it makes a lot of sense to put those hands together being able to filter certain clients DNS views.

Granted this is all just feels like it's all just temporary wins/control in this arms race this until the browser/app developers decide to head off to fully encrypted DNS and SNI.