Reflexion will be End-of-life on March 31,2023. See Sophos Reflexion EoL FAQs to learn more.
Since version 18, Sophos Firewall has been able to do port-agnostic SSL/TLS decryption and web filtering. This extends our inspection for web threats beyond ports 80 and 443. We've used this ability to release IPS signatures that can detect some HTTP attacks in decrypted traffic on any port.
In version 19, we've introduced a feature that will apply a broader range of web-related IPS signatures to decrypted TLS traffic, regardless of the port. Overall this provides a significant enhancement in our ability to protect against attacks that may try to circumvent regular IPS protection.
The feature is not enabled by default yet. We would really like to get some more exposure to a wider range of situations and traffic.
If you're using EAP2 and TLS decryption, it would be great if you could turn this feature on. Here's how to do it:
console> set ips scan_decrypted_port_agnostic on
Enabling this feature may lead to an increase in the number of IPS signature events on your Firewall. Each firewall sends telemetry to SophosLabs when IPS signatures fire, enabling us to respond to potential false positives very quickly and update signature sets.
You can disable this feature again if necessary with the following command:
console> set ips scan_decrypted_port_agnostic off
Thanks for your help! Please feel free to tell us about your experiences in responses to this post.
So if decryption is not enable this setting has no effect?
That's correct. It only has any effect on traffic that is (a) decrypted by the DPI engine due to a TLS rule, and (b) subject to IPS scanning.
I have been trying to workout a case for using SSL/TLS decryption on my network and not found any
1/. does not work with mail protocols
2/. does not decrypt UDP traffic
3/. does not provide website blocking as per web policies.
So, if you use SSL/TLS decrypt you still need a web proxy setting to enforce URL policy management. The devices I thought it might be useful on are not capable of having a CA installed, so scanning will fail.
XG115W - v19.5.1 mr-1 - Home
If a post solves your question please use the 'Verify Answer' button.
I think there's a bit of a misunderstanding around 3.
Since 18.0, there have been two systems for enforcing web policy - DPI Engine and Proxy. Enabling SSL/TLS decryption allows the DPI Engine to enforce Web policy (including malware scanning) on decrypted HTTPS traffic without needing to use the proxy.
The proxy is only required for web policy enforcement if you want to enforce policies that require modification of allowed traffic e.g. safe search enforcement, Google/Microsoft domain authentication enforcement. All other policy elements, along with file scanning of HTTPS downloads/uploads, are done by the DPI Engine.
It's true that it doesn't work with mail policies or UDP traffic, and that, as with any inline TLS decryption, you need to be able to install a local CA on the device. But it's a more secure and efficient solution than using the proxy for HTTPS decryption and generally provides better overall performance.
thank you for taking the time to respond. The SSL/TLS engine and DPI do not block tunnels because tunnels in a lot of cases will fallback to UDP.
Still analysis my firewall rules to determine if I can not use the proxy on some functions.
Then there is the other issue of not being able move the default rule down the processing order, the only way is clone it, then disable it.
this is being a bit picky maybe, but why does the SSL/TLS rule listing show the firewall rule number as the processing order, while the firewall rules and NAT show the processing number down the lefthand side and the rule number towards the righthand side?
I take your point. The TLS rule number on the left-hand side is the fixed rule number - if you re-order rules the ID doesn't change. But this is different to the Firewall & NAT rules, which always show the order down the left and put the ID on the right. The simple answer is that the different UI pages are sometimes built and maintained by different teams, the TLS rules design was based on an older version of the Firewall rules table, and since release there have been more important things for the teams to work on. I hope we can find cycles to realign these views soon.