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

MichaelBolton said:

I can tell you on my unit, if I don't have a web policy selected ie none, have maleware scanning enabled, and have "Use web proxy instead of DPI engine" checked, the XG is using the DPI engine. Only when I select a web policy will it actually use the proxy.

I assure you this is not the case.  What are you using to determine whether it is using the proxy (eg awarrenhttp) or DPI (eg snort).

HTTPS traffic stills show up in the log under "SSL/TLS inspection". The second I apply a web policy, the HTTPS traffic stops showing up in "SSL/TLS inspection" in the log.

Also, my work around for Honeywell traffic before your console setting, was to use the proxy but I had to set a policy then too. I used allow all and the traffic worked again. I will be happy to give you a remote session but I can assure you, the DPI engine is messing with the traffic somehow when no web policy is selected or "Decrypt HTTPS during web proxy filtering" is not selected.

I need to look at your configuration.  Can you please go to Diagnostics, Support Access and enable.  Post or PM me the Access ID.

Michael Dunn said:

 

I assure you this is not the case.  What are you using to determine whether it is using the proxy (eg awarrenhttp) or DPI (eg snort).

It looks like I am wrong.  Or rather, I am describing what should be happening and not what really is happening.  Looks like we have a bug in the proxy/dpi selection when web filter is none.

In Michael Bolton's case, with web filter = none port 443 is processed by snort and port 80 is processed by awarrenhttp.

Bypassing that issue by setting a web filter, can you please clarify the results here:

Results of further testing.

Web Filter=Allow All       Use Proxy            relay_invalid_http_traffic off      Block unrecognized protocols on               Error

Web Filter=Allow All       Use Proxy            relay_invalid_http_traffic on       Block unrecognized protocols on               Error

Web Filter=Allow All       Use Proxy            relay_invalid_http_traffic off      Block unrecognized protocols off                Allowed

Web Filter=Allow All       Use Proxy            relay_invalid_http_traffic on       Block unrecognized protocols off                Allowed

Thanks.  So even though they are controlled by different variables (snort is "more correct" than the proxy) the results are the same.

There is something against spec in the traffic from the IoT devices which both proxy and DPI do not like.  Since this is not a regression issue, it is currently low priority for investigation - especially as the investigation will most likely just confirm that they are non-spec in a way we don't want to allow.  There is a workaround - setting the global flag.

The issue of traffic going to DPI when it should be going to proxy has been reproduced and sent to the firewall team, who is responsible for that decision.

Thanks for the info and the help. Let me know if you guys want packet captures or any other info to help when it comes time to look into it further.

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