Can someone explain SSL/TLS inspection rules vs. Web Exceptions?

It's my impression that the Web->Exceptions is a high-level list for really global control that can override many different steps of the firewall processing in one place, using wildcard expressions. Mainly meant for global-ish sites like Apple, Microsoft, your corporate site, key utility/security software sites.

The SSL/TLS inspection rules look for exact matches of host or domain, and only affect that aspect. So more specific to the TLS system itself (and you can turn off all TLS decryption entirely from that page.)

You can also turn off or on TLS inspection per firewall rule, so I envision the control hierarchy as (in order): if the firewall rule says yes and the TLS Policy says yes (and TLS is turned on globally), and the Exceptions don't say No: do it. Otherwise, if any point along the way says "no", don't do it.

It's my impression that the Web->Exceptions is a high-level list for really global control that can override many different steps of the firewall processing in one place, using wildcard expressions. Mainly meant for global-ish sites like Apple, Microsoft, your corporate site, key utility/security software sites.

The SSL/TLS inspection rules look for exact matches of host or domain, and only affect that aspect. So more specific to the TLS system itself (and you can turn off all TLS decryption entirely from that page.)

You can also turn off or on TLS inspection per firewall rule, so I envision the control hierarchy as (in order): if the firewall rule says yes and the TLS Policy says yes (and TLS is turned on globally), and the Exceptions don't say No: do it. Otherwise, if any point along the way says "no", don't do it.

Thats as reasonable as I have seen, but I find it odd that it isn't spelled out anywhere.  Even chat support didn't seem to really know.

Essentially one is the service, the other one is the entire Engine. 

So: DPI Exceptions means, we are not "touching" the decryption. 

Web Exception means, if the we touched the traffic and forwarded it to the Proxy, the proxy will not do "something" on it. 

And it's just my impression for how it must work. I think it's not really an issue in the sense that each location makes sense for a specific use case.

Firewall rules are the overall permission givers so you can specify which traffic has permissions and that traffic on that flow either is (with exceptions) or is not decrypted. Here's where you might decide that certain kinds of traffic -- say streaming video -- makes no sense to decrypt or is too much of a processing hog to be worth it. (And you also decide things like what QoS applies, which is related.)

The TLS Profile Rules has the master switch which can turn TLS decryption globally, for debugging/testing. The rules themselves include things like the two TLS exception lists: one curated by Sophos and one by you. For things like particular organizations/sites that are extra-strict and don't allow MitM and hence break under TLS decryption, mainly.

The Web Exception list gives you more flexibility in terms of names (wildcarding) and also gives you control over more steps in processing than just TLS. For more fundamental exceptioning of stuff like OS updates, etc.

At least that's how I imagine it.

Lucas says, below, that it has to do with the DPI engine (new-school) versus proxy (old-school) and I'd take his word over mine, which means my conception of the Web - Exception is flawed and if you're not using the proxy (sort of obsolete now) it doesn't matter. I use DPI engine only and that's one of the reasons to get an XGS appliance, I think.

Currently DPI (SSL/TLS) does not handle UDP traffic, where as the proxy does (sometimes).

Ian

I found this:

 Sophos Firewall v18: XStream - the new DPI Engine for web proxy explained 

Which indicates that DPI (I'm using DPI) works with both Web Exception and SSL/TLS inspection rules.  Looks like it considers both?  Not sure what happens if they conflict.

From the link: