I'm using Sophos XG and basically want to disable HTTPS (SSL) web filter scanning support so I don't want to deal with all those https certifacate exceptions.
How can i do this?
HI Huseyin,
Make sure you have checked the settings
1) You may disable the HTTPS malware scanning on your firewall rules.
2) Disable Micro - App scanning on your application filters
3) Run the command in console
console > system application_classification microapp-discovery off
You may verify the command by executing another command
console > system application_classification microapp-discovery show
These steps will ensure you will not encounter any HTTPS error except while accessing the user/XG portal.
There was a design decision made in v15/v16 regarding microapps and HTTPS that is proving to be problematic for some.
For the majority of people, they do not need to do the step of changing the microapp flag.
We are aware of the issue and hope to resolve it in v17.
Does this actually disable the proxy from transparently grabbing the traffic or does it simply turn off the decryption portion of it? We followed this advice but all HTTPS sites are now taking a long time to establish their connections for users behind the XG devices.
NOTE: This post has been updated to be more accurate. I apologize - I'm a web guy not a firewall guy and I should have tested before posting rather than the other way around. :)
Basically, if HTTPS traffic on port 443 is going to go through the XG, it needs to have one of two things:
A) Have a firewall rule that says HTTPS or TCP traffic is an allowed service
Then, once it goes through the XG it could either pass though the web proxy, or it could just be forwarded. It will be sent to the web proxy in the following cases:
1) HTTPS Decrypt and Scan is on
2) Web Policy is selected (not None)
3) microapp-discovery is on *
If you turn microapp-discovery off you need to make sure you still have a firewall rule that allows https.
* The future fix will turn this off by default and then make other changes so that the system works correctly when off
Can you take a look at your firewall for rules that apply to this traffic.
Do you have any rule that has a Web Policy or has Decrypt and Scan HTTPS on?
Do you have any rule that include HTTPS?
If the answer is no, then the reason is there. You need a rule that allows HTTPS to go across the firewall.
However this creates an interesting problem for us (people who are trying to fix stuff). How many other customers have firewall rules that don't have a firewall rule for web policy and don't have a rule for HTTPS, but unknowingly rely on the microapp-discovery behavior? If we deploy a fix so that port :443 doesn't go to the proxy when it doesn't need to are we going to break lots of other customers who don't have correct firewall rules? Ugh - the fix is now in jeopardy.
Honestly at this point I'm regretting not throwing a fit when we were giving the XG devices instead of UTM ones (this is an issue with our vendor, not with sophos). I can honestly say that after this experience I will never purchase an XG line again.
It turns out it was still enabled because we had a web profile in use somewhere. I will say that the policy selection UI is awful- you can see which policies are in use but you can't just click on that policy to see where it is in use or to disable it from there. Instead you have to individually check each firewall rule for it (which is it's own nightmare since you've disable the back button for the firewall rule page). It also means we can't scan HTTP traffic without scanning HTTPS as well.
Things are definitely faster now, but I am really shocked at just how low the quality of these devices are compared to the UTMs, and I'm going to try to reach out to support and the vendor to see if we can swap out for the UTM instead. I really hope there aren't any plans to get rid of the UTM line completely because I don't think we'll ever be willing to buy an XG device after having used both.
Michael Dunn said:However this creates an interesting problem for us (people who are trying to fix stuff). How many other customers have firewall rules that don't have a firewall rule for web policy and don't have a rule for HTTPS, but unknowingly rely on the microapp-discovery behavior? If we deploy a fix so that port :443 doesn't go to the proxy when it doesn't need to are we going to break lots of other customers who don't have correct firewall rules? Ugh - the fix is now in jeopardy.
Hi michael, thanks for your explanation. You guys really need to make a decision on who are you targeting with XG. If home users are your target then by all means, put little switches that enable stuff in the background and netflix and hulu along with a million other apps start working without any know how from the admin. Enable upnp on the firewall with allow any service as default configuration out of the box. You will immediately see a huge uptick in free XG home users.
But if you are targeting business users, lets get out of the nanny firewall mentality and block stuff unless an admin explicitly allows it. The default behaviour should be microapp-discovery disabled. Actually the firewall rule (allowed services) should have precedence over micro app discovery. If people are passing https traffic without firewall rules, maybe they need a wakeup call to look at their firewall rules and don't really know what is going on with their firewalls.
> But if you are targeting business users, lets get out of the nanny firewall mentality and block stuff unless an admin explicitly allows it. The default behaviour should be microapp-discovery disabled. Actually the firewall rule (allowed services) should have precedence over micro app discovery. If people are passing https traffic without firewall rules, maybe they need a wakeup call to look at their firewall rules and don't really know what is going on with their firewalls.
Agreed. Had I realized that this was meant to be a home user product and not an enterprise grade firewall I would have run screaming . . .
