DPI-SSL and Content Filtering
xdmfanboy
Newbie ✭
Awhile back Sonicwall changed the way DPI-SSL and content filtering interact. Currently, it says if you want CFS to handle HTTPS you have to have content filtering unchecked under DPI-SSL. What I'd like to know is what if any role the CFS category tab plays anymore. If content filtering is unchecked and left to CFS to handle, then does the category selection really mean anything? I've had some confusing results in tests I've done, but the categories selected on that page do NOT seem to work if content filtering is checked under DPI-SSL, in which that tab seems to serve no purpose under recent firmware releases, like an artifact page that should be removed.
Further, if that is unchecked and CFS blocks, you will not get the block screen for HTTPS, but a connection failure, a behavior they describe. If you do leave it checked, a blocked HTTPS site will show the block screen, which would be the more desirable behavior. I wonder if this is another change for which I haven't seen documentation. This is with changing allowed categories under CFS Profile Objects. Changing category permission under DPI-SSL seems to have no effect whatsoever.
Can someone explain the various interactions of these settings? Is there a bug, or just a sloppy, poorly documented way this is all handled?
Answers
Hello @xdmfanboy,
On the latest general release 6.5.4.7, the HTTPS content filtering is moved to a profile-based section whereas DPI SSL is a global option.
When using DPI SSL, the SonicWall performs SSL proxy and can see the HTTP GET that shows the entire URI being accessed and can also show the block page as the SSL connection is being proxied and our banner can be inserted in between.
While just using HTTPS content filtering, the URL request is checked on the unencrypted HTTPS handshake fields like SNI (Subject name indicator), or the common name of the SSL certificate. Since it is an HTTPS connection, and encrypted post handshake, we cannot insert our banner in between and need to terminate the connection on the firewall, showing connection failure.
DPI SSL alone cannot allow/block websites, it only performs SSL proxy and the tabs checked under it are the engines to which the proxied connections are fed. So, if DPI SSL is not fed to the CFS engine, it uses HTTPS content filtering to find the category and allow/block the websites. When using DPI SSL in conjunction with DPI SSL we have more visibility to the entire URI being accessed and we can have much granular control over what we would like to block.
I hope this helps!
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
You've clarified a few things, but some questions remain. I've re-read it multiple times, trying to sort out what is being said.
If DPI SSL alone cannot allow/block web sites, then what role does the CFS Category tab play if any? If DPI SSL is active, yet its content filtering unchecked, then does the normal CFS function avail itself of information exposed by the SSL proxying?
"When using DPI SSL in conjunction with DPI SSL" - I assume you mean DPI SSL in conjunction with content filtering, but does that content filtering as checked under DPI SSL, or unchecked their by CFS filtering HTTPS. You see you need to be a little more specific. I guess I need to test bed this with all scenarios. My client has been oddly reticent about me testing at their place.
In summary, in a mixed environment where the public users aren't getting DPI-SSL, but staff and public users need content filtering, what would the best settings be? I'd certainly prefer to get a proper block notification with HTTPS.
Sonicwall really needs to have a comprehensive document describing the behaviors with different combinations of the settings.
Hi @xdmfanboy, the CFS tab in the DPI-SSL settings is purely to exclude or Include HTTPS Inspection by Content filter category, it is just using the CFS category list for ease it is actually nothing to do with the CFS as such, it is just maching the common names on the webites to a CFS category if it is excluded then it doesn't process the HTTPS Inspection.
it is so you don't need to add the all the sites manually to exclusions, so if you want all Banking sites to be excluded from the HTTPS inspection which is recommend for obvious reasons, then all Banking websites would be excluded without the need to add all the Banking URLS to an Address object list and then exclude from DPI-SSL.
Hope all that makes sense
So you're saying that for example if I have porn blocked under the CFS Profile Objects and CFS was set to filter HTTPS, that if I exclude porn under DPI-SSL it only excludes it from HTTPS filtering, but not HTTP? Or it doesn't exclude it from the content aspect of the filtering, but does exclude it from protections DPI-SSL may afford if it could examine the encrypted contents? My guess was that the tab is not for filtering per se, though by exluding a category from more advanced inspection.
Also, it seems if CFS is NOT set to filter HTTPS, then it seems the settings under DPI-SSL would be irrelevant?
Kind of related to that, I noticed there can also be some unexpected behavior when a request gets redirected from HTTP to HTTPS, but I guess that's another conversation.
(clipped from recent SW release notes re post-CFS changes)
DPI-SSL and CFS HTTPS Content Filtering Work Independently
DPI-SSL and CFS HTTPS content filtering can be enabled at the same time and function as follows:
• If DPI-SSL Client Inspection is disabled, Content Filter Service filters HTTPS connections.
• If DPI-SSL Client Inspection is enabled, but the Content Filter option is not selected, Content Filter Service filters HTTPS connections.
• If DPI-SSL Client Inspection is enabled and the Content Filter option is selected, CFS does not filter HTTPS connections. **(My notes - Then what is happening here since DPI-SSL apparently doesn't have its own filtering engine)
(end clip)
Like I said, I think many would benefit if SW more clearly spelled out what is happening with different combinations of options.