BUG - SSL/TLS Inspection seems to break Honeywell smart devices

1) There is a known issue with "Use proxy instead of DPI mode" not being respected when Web Filter=None. This is being worked on for GA.

2) There is a known issue with handling and logging of unscannable traffic. This is also being looked at, post-GA

The traffic is on port 443 and matches a Firewall Rule for DPI mode and matches an TLS Rule Do Not decrypt rule.
The sslx system does not recognize it as an TLS handshake, or there is something invalid about it.
The sslx system, not being able to handle it, passes it to the HTTP parser hoping it can.
The HTTP parser does not recognize it as plaintext HTTP and logs an error "HTTP parsing error encountered"

Therefore it might appear to an administrator that the "Do not decrypt" was ignored, that it was decrypted and had trouble with the data after. In fact, what occurs is that neither the SSL system nor the HTTP system could parse the packets.

Therefore some/most "HTTP parsing error encountered" in the log is actually a failure in handling the SSL handshake.

In v18.0 EAP3 and most likely in v18 GA if you are in this scenario:
proxy mode - In Web > General Settings > turn Block Unrecognized SSL Protocols off.
DPI mode - In the command line (not ssh) use 'set http relay_invalid_http traffic on'

This may change post-GA.

1) Has not changed for GA. Please use "Allow All".
2) We have done several fixes for related defects, but we do not think that this particular problem is resolved. However we would like someone who was previously experiencing this problem to report whether it is working in GA.

Specifically for the Honeywell smart thermostat, as far as I know:
In 17.5 (proxy) it fails with "Block unrecognized protocols" Checked
In 17.5 (proxy) it works with "Block unrecognized protocols" unchecked
In 18.0 GA (proxy) it fails with "Block unrecognized protocols" Checked
In 18.0 GA (proxy) it works with "Block unrecognized protocols" unchecked
In 18.0 GA (DPI) it fails with "relay_invalid_http_traffic" off
In 18.0 GA (DPI) it works with "relay_invalid_http_traffic" on

Please confirm if this is true.

Block unrecognized protocols can be changed in Web > General Settings.
relay_invalid_http_traffic can be changed in command line (no ssh/advanced shell) with 'set http_proxy relay_invalid_http_traffic on/off'.

Hi Michael,

so what you are advising is there is no way to stop a firewall rule from being scanned eg LAN to LAN rules?

Ian

rfcat_vk said:

so what you are advising is there is no way to stop a firewall rule from being scanned eg LAN to LAN rules?

Ian, I love you man and I like all the bug reports you are giving us.  I'm a QA tester - I love testing, I love bugs.  But please do not hijack threads.

This thread is about Honeywell smart devices in a LAN contacting to a server on the Internet.

Hi Michael,

I could not find my original thread on the subject and this one has lots of explanations about the same issue, so I added a question because I have a device which has similar issues with DPI?

Ian

Your question is answered by Rich Baldry in this thread:

https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/feedback-and-issues/117987/question---bug---dpi-appears-to-be-on-by-default

Hi Michael,

that answer was about the display when you click on the field on the firewall rule not about turning off DPI.

Ian

rfcat_vk said:

So how do I turn off inspection of internal rules only?

RichBaldry said:

Hi Ian,

Our intent is for it not to be necessary to turn this off, so that the DPI Engine has no impact on traffic if there are no scanning or inspection policies applicable to it, but so that we can still include information about it in our overall accounting of traffic.

There are still a couple of outstanding situations that we've come across in the EAP that we are aiming to fix before the GA release of v18, including a few relating to our handling of traffic that is not recognized as TLS or HTTP on port 443. One of the major impacts of this right now is OpenVPN SSL VPN connections, which send a few packets of custom handshake protocol before beginning a TLS handshake. We've had reports of a few IoT devices that use OpenVPN to tunnel traffic to the cloud - is it possible that's what's going on with your camera?

So to be clear on your question "so what you are advising is there is no way to stop a firewall rule from being scanned eg LAN to LAN rules" the answer from the program manager is "the intent is for it not to be necessary to turn this off".

Therein lies the issue, you cannot use the http proxy on internal traffic (which does not break the application). but DPI does, so how do you overcome this because there is no log to show what needs to be exempted.

Ian

I will test out the original issue and get back to you Mike.

As far as what Ian said, I know it is off topic but it is also part of this issue overall. If I could have disabled any scanning whatsoever on a firewall rule, I could have bypassed this issue all together.

If what Ian is saying is true and the DPI is scanning even LAN to LAN traffic, how in the world can XG meet the performance numbers that are posted for the firewall itself? Snort can't put up those numbers with any of the hardware appliances. 20 GBPS throughout on an XG230? Yeah right. If DPI wasn't involved maybe. Sorry I continued off topic but it is related.

Off topic, but currently in v18 GA if you create a Rule without any Security profile on it, It will bypass Snort. The issue of DPI scanning LAN to LAN Traffic in my believe has only present on v18 EAP.

I've just tested it out with HTTP(s)-Download/SFTP/SMB and all of them bypassed Snort/AV/DPI using a Rule without any Security profile being applied.

So it's pretty much working as expected right now in v18 GA.

Thanks!

Off topic, but currently in v18 GA if you create a Rule without any Security profile on it, It will bypass Snort. The issue of DPI scanning LAN to LAN Traffic in my believe has only present on v18 EAP.

I've just tested it out with HTTP(s)-Download/SFTP/SMB and all of them bypassed Snort/AV/DPI using a Rule without any Security profile being applied.

So it's pretty much working as expected right now in v18 GA.

Thanks!

I have tested it on v18GA. All of my firewall rules, including LAN to LAN have all security, scanning, IPS, etc. disabled and the web policy set to non. Under "SSL/T LS Inspection Rules" you can see the traffic counters increasing, proving that the DPI is still being used.

MichaelBolton said:

All of my firewall rules, including LAN to LAN have all security, scanning, IPS, etc. disabled and the web policy set to non. Under "SSL/T LS Inspection Rules" you can see the traffic counters increasing, proving that the DPI is still being used.

The new DPI engine is always running, by default it have a hidden rule ANY=>ANY, Do not decrypt and Maximum compatibility.

I currently have a SSL/TLS Inspection Rule LAN => ANY, Do not decrypt, Maximum compatibility (For the Logs). And above that rules, the correct ones for LAN=>WAN traffic.

If there's no rules implicating Decryption over LAN=>LAN Traffic,  then SSL/TLS Inspection won't kick in and do It's thing. But of course, you can still apply Decryption Profiles over it to block certain Chipers or un-trusted certificates, so on.

There is a new video from Sophos showing fast-path, if you want the traffic not being scanned at all, you will need to disable all security profiles over that traffic, that includes AV and IPS + AppID.

Disabling only the Web Policy isn't right thing if you want the best throughput XG can give to you

Also apparently disabling the Web Policies =/= disabling SSL/TLS Inspection Rules. You can have a rule/user without any web policies and still have a decryption rule over SSL/TLS Inspection for a category/Websites. Web Policies are in my understatement, being used only to apply actual policies over HTTP(s), such as block/allow/quota/warn for the categories/etc you have.

Thanks!

Prism if you make a firewall rule with LAN to LAN, disable everything, make an SSL rule to not decrypt, you will see the traffic counter increase on the SSL rule. This shows that snort is looking at the traffic. See below after a simple test.

Maybe something is not right with my unit but snort is involved with my LAN to LAN traffic.

EDIT: the second picture was taken before I saved the rule and shows decrypt as the action but the saved rule shows don't decrypt.

Also Michael Dunn I am sorry man. I didn't mean to hijack this thread. I thought this was related, and it is in a way but it will be better handled in another thread. Prism let's move this over to https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/feedback-and-issues/117987/question---bug---dpi-appears-to-be-on-by-default as that is where Mike said it originated. 

But this is exactly what i said before, the new DPI engine is always running, since you have a LAN=>LAN Rule to not decrypt and also on Maximum compatibility, SSL/TLS Inspection will do nothing with the traffic, but of course It will still be logged.

What I've told you before, If you DON'T want traffic to be SCANNED (IPS/AV/APP-WEB Policies being applied) on XG, all you need to do is have a Rule with no security profile on it (IPS/AV/App Classification.) and simply don't create a SSL/TLS Inspection rule to decrypt.

As I've said  before, you can also do this test yourself, get a Web Server (Nginx), an certificate, and just throw a huge file to download over HTTPS (LAN=>LAN.)

If there's no security profile on the Rule being used, and there's a "Do not decrypt, Maximum compatibility" SSL/TLS Inspection rule, you will pretty much see line-rate throughput with it, you can even SSH to XG and see it for yourself, Snort CPU usage won't even move without the security profiles being applied.

Thanks!

Even without the SSL rule that shouldn't be doing anything, I can see the snort CPU usage increase when I transfer large files from LAN to LAN.

Again, maybe something is not right with my unit, but if DPI is always on, that means snort is being used and snort cannot put up the numbers.

I will default my test unit and test again.

Hi MichaelB,

I think you and I are having trouble getting people to understand.

See if you agree with this scenario.

There should be 3 tropes of firewall rules:-

1/. Proxy

2/. DPI

3/. no inspection  as per v17.5 firewall rules.

Even though everyone talks about using the DPI default do not decrypt and maximum compatibility seems not to understand that SNORT still needs to intercept and read the connections to decide which SSL/TLS rule to use and therein lies the issue.

Ian

rfcat_vk said:

Even though everyone talks about using the DPI default do not decrypt and maximum compatibility seems not to understand that SNORT still needs to intercept and read the connections to decide which SSL/TLS rule to use and therein lies the issue.

Well...

1. Group A shall not be inspected. (IPS / Web filter / App Control / etc.)
2. v18 has a problem with the DPI engine, so it is often impossible to communicate properly.
3. Use Web Proxy to avoid problems with the DPI engine.
4. Using Web Proxy violates policy of the Group A
5. Evict the XG Firewall v18 appliance.

Is that correct? Is there any other way?

Hi FOW,

that is for external access, internal access you cannot use the proxy (LAN to LAN), but otherwise a nice summary.

ian

ATP is a global on/off. When turned on it applies to all traffic on all ports.
Bandwidth shaping and rate limiting are applied to all traffic.
IPS is applied to various traffic.
All of these things use snort to various extents. With the introduction of DPI they all use DPI to some extent.

The reason that matching a firewall rule with no web policy and a TLS inspection rule with Do not Decrypt is not enough is because there are more parts to the system than that.

So let says we have a problem where there is traffic that should go through the system and is not. That is a bug. There are two broad solutions to this: Fix the bug or exclude the traffic. As Rich has said, our approach is to fix the bug. Right now we are not looking at a way of excluding traffic completely from DPI. Right now we are focused on fixing bugs.

That is partly why I have tried to separate the issue of "how do I bypass DPI" from "this device does not work" into separate threads, but I'm giving up now. You don't bypass DPI. Asking again how to bypass DPI is a dead end. Asking how you can help fix DPI so that the devices work is better. That is why EAP is so valuable to us. There are lots of really great and helpful people here who are sharing logs and tcpdumps and time and energy, and we really really thank you. And I know you are also sharing a feature request to have a way to bypass DPI completely but right now that feature is not going to happen. Rather than having a feature for a workaround we want to fix things so that you don't need to workaround.

As for the counters proving that DPI is being used, you are semi-correct, and partly it gets down to terminology. Internally, all traffic gets looked at by snort. If the traffic looks like a TLS handshake then the TLS/SSL Inspection Rules are consulted and if a rule matches then the rule counter goes up. But even if no rules match and it falls to the bottom it is still looking at the traffic. You cannot say "don't look at the traffic if it matches these criteria, which you can only find out by looking at the traffic".  How can you apply a rule to Don't Decrypt traffic to microsoft.com until after you have looked in the SNI in the TLS Hello. So it is true if a TLS Inspection Rule counter goes up that proves that snort looked at the traffic and determined it was TLS. But even if none of the counters go up, snort is still looking at the traffic, so the proof is immaterial.  And if the traffic was not TLS, DPI is looking at the traffic and none of the TLS counters would change.

Lets take a scenario where you have a Firewall Rule that says apply a web policy to block access to websites categorized as Phishing&Fraud. Lets say you have a TLS inspection rule that is Don't Decrypt, Maximum Compatibility. Lets say a client goes to HTTPS fakebank.com. DPI will see the TLS Hello and read the SNI in it, then decide to block the request based on the web policy. No TLS inspection rules counters went up. Lets say a client goes to HTTPS MalwareControlServer.com. DPI will see SNI and decide to block the request based on ATP. Even if the firewall rule had no Web policy, ATP is applied.

Making sure that you hit a TLS Inspection Rule of Do not Decrypt does not mean that it isn't doing DPI, that it is not doing Deep Packet Inspection. It just means it won't decrypt.

Prism said:

What I've told you before, If you DON'T want traffic to be SCANNED (IPS/AV/APP-WEB Policies being applied) on XG, all you need to do is have a Rule with no security profile on it (IPS/AV/App Classification.) and simply don't create a SSL/TLS Inspection rule to decrypt.

If you don't want traffic to be scanned for viruses, turn off malware detection in the firewall rule.
If you don't want traffic to have a web policy applied, use policy None or Allow All.
If you don't want traffic to be scanned for ATP, turn off ATP globally.
If you don't want traffic to be scanned for IPS, turn off IPS for it.
If you don't want SSL/TLS to be decrypted, make sure it hits a Do Not Decrypt rule.
If you don't want traffic shaping or bandwidth limited, turn off those rules.
And probably more.
There is no global way of saying don't scan for anything.  That is how it has been since XG began.  DPI means we are looking deeper into packets then before, but snort has always looked at packets.  Fact is, even when using the full blown web proxy, snort is still looking at the traffic.

So, given that you cannot turn off DPI, the question is how can we make DPI work better.  We need helpful customers who are willing to tell us where it is broken, to share detailed information and logging, to test out solutions.  We have done our best to fix as many issues as we can for GA, we are going to do our best to fix as many as we can for MR1.  If you have an issue and you need it to work, then continue to use the web proxy.

Hi Michael,

thank you for taking the time with the detailed explanation.

I have tried to assist with this thread because I have an application that does not work LAN to LAN and I have not been able to find anything in the logs that I know how to access that would add further value to the thread. So, I ask how to create a similar situation as in V17 which you tell me I can't, so I am stuck with a application that doesn't work the way the application support people tell me it should. So to get around this issue I have permanently put one of my devices on my IoT network to provide local access. Shortly I will dig out an old android device and use that.

Ian