DPI vs. Proxy exceptions

The Web > Exceptions apply to both proxy mode and DPI mode and can turn off HTTPS Decryption, certificate checks, Policy checks, AV and more.  It applies to web traffic.

The TLS Inspection Rules apply to DPI mode and can only turn off HTTPS Decryption and certificate checks.  It applies to any type of SSL/TLS traffic.

There is a bunch of new integration into the log viewer and dashboard to make it easy to add to the URL Group that is used by the TLS Inspection Rules.

In WebAdmin we have tried to make a note of things that only work in proxy mode and not DPI mode (for example SafeSearch).  Web Exceptions work in both.

Thanks Michael.

Does it gonna to change in the next future?

In this way, users need to update and keep update the same objects inside 2 different lists.

So image the user is not able to open a website and he/she is using DPI, then the user puts the site inside the TLS URL group but the website still does not open. So the user puts the same websites (using regex this time) into exceptions and ticked all checkboxes and finally the website works.

The user to keep the things clean on XG, needs to understand first who is responsible for the blocking traffic, try and then clean the portion that is not responsible.

Sorry, but for the moment, logs do not help a lot. I would like to have another extra checkbox into web exceptions for skip DPI scanning or something like that to have a single section to deal with.

Also, I prefer regex to url or subdomains, as regex are more flexible to filter/bypass traffic.

This is a bit complicated to understand for “normal users”.

A better description should be provided inside the ui itself.

lferrara said:

This is a bit complicated to understand for “normal users”.

A better description should be provided inside the ui itself.

Uncomplicated answer:  If are used to creating Web Exceptions, continue creating web exceptions.

Michael Dunn 

I will let you know once my customers will start to move on v18. Customers' feedback are the most important part in our job.

Thanks

I don't necessarily agree that it is too complicated, but I agree that this should be pointed out better in the documentation. Once you understand what is what, it makes sense and isn't hard to understand, but the information about it is missing or not clear enough. So I second the request that the documentation gets a little update on this. 

Cheers

cryptochrome said:

I don't necessarily agree that it is too complicated, but I agree that this should be pointed out better in the documentation. Once you understand what is what, it makes sense and isn't hard to understand, but the information about it is missing or not clear enough. So I second the request that the documentation gets a little update on this. 

 

I have just finished working the the Docs team on getting this (TLS Exclusion Rules and Web Exceptions) better documented in the Help section for SSL/TLS Inspection Rules.  I don't know when you guys will see the update, but it should be clearer in docs in the future.

Thanks for the update, Michael. I'll take a look once it's available. 

Online help links:

http://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/FirewallSSLTLSRules.html#TLSInspectionRuleManage__ptq_1yp_r3b

http://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/WebFilterExceptionManage.html

Thanks Michael, the docs look really good. Except for one thing. In the first link, third paragraph, the docs say:

SSL/TLS inspection rules do not affect the decryption of traffic handled by the web proxy.

From my experience, this is not the case. I have one firewall rule which is set to proxy mode and which has web exceptions configured to disable decryption. During my tests, I also added a TLS decryption rule (DPI) that matches that traffic. Traffic is being decrypted, despite the rule being set to proxy mode. If I understand the docs correctly, this should not happen. Is this a bug in v18 or is the documentation not clear enough?

Thanks
Sascha

Special thanks to Michael Dunn and @L@DocSupport for getting this content to our help!

Wanted to mention to any readers to visit our Feedback on User Assistance group to suggest new content for our online help, startup guides, knowledge base and videos, or tell us how we can improve what we already have!

cryptochrome said:

Thanks Michael, the docs look really good. Except for one thing. In the first link, third paragraph, the docs say:

SSL/TLS inspection rules do not affect the decryption of traffic handled by the web proxy.

From my experience, this is not the case. I have one firewall rule which is set to proxy mode and which has web exceptions configured to disable decryption. During my tests, I also added a TLS decryption rule (DPI) that matches that traffic. Traffic is being decrypted, despite the rule being set to proxy mode. If I understand the docs correctly, this should not happen. Is this a bug in v18 or is the documentation not clear enough?

 

I suspect you have a misconfiguration somewhere and the traffic is not hitting what you think it is.  This should not happen, and I'm pretty confident we don't have a bug here.

If you can reproduce it, can you please start a new thread and give plenty of details.

cryptochrome said:

Thanks Michael, the docs look really good. Except for one thing. In the first link, third paragraph, the docs say:

SSL/TLS inspection rules do not affect the decryption of traffic handled by the web proxy.

From my experience, this is not the case. I have one firewall rule which is set to proxy mode and which has web exceptions configured to disable decryption. During my tests, I also added a TLS decryption rule (DPI) that matches that traffic. Traffic is being decrypted, despite the rule being set to proxy mode. If I understand the docs correctly, this should not happen. Is this a bug in v18 or is the documentation not clear enough?

 

I suspect you have a misconfiguration somewhere and the traffic is not hitting what you think it is.  This should not happen, and I'm pretty confident we don't have a bug here.

If you can reproduce it, can you please start a new thread and give plenty of details.