XG Intercepting SSL Traffic with disabled SSL/TLS-Modul and disabled SSL/TLS-Inspektion

Do you have a block rule on XG Firewall? Something like default drop ? 

Thank you for the reply. Yes we do but it does not match on it and has 0 Byte Traffic. The matching rule FW_Rule_ID="10" is the rule descriped above.

Is this a old installation? Did you enable something on the Console? 

Is there something enabled called Micro-app? Check the console:

console> system application_classification microapp-discovery show
off

What do you mean by old installation? I dont rember the factory version of the XG but it was updatet to 18.0.3 during initial setup. 

The output of the requested command is: "off"

We enabled the following on the console to address another problem:

Problem:
There is a known issue with handling and logging of unscannable traffic. This is also being looked at, post-GA
Beschreibung:
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.

Workarround:
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'

What do you mean by old installation? I dont rember the factory version of the XG but it was updatet to 18.0.3 during initial setup. 

The output of the requested command is: "off"

We enabled the following on the console to address another problem:

Problem:
There is a known issue with handling and logging of unscannable traffic. This is also being looked at, post-GA
Beschreibung:
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.

Workarround:
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 was not the solution to the problem, just something we did on the console to address another issue. 

Can you show us this rule 10? 

Thank you for the reply. I disabled "match known users" and IPS on the rule and there are no more certificate issues (when the certificate issues orrured there was no authentication on XG needed, the website would load aber accepting the cert error and also "web authentication for unknown users" was disabled). I reanabled the authentication now again and selcted the specific zones for source and destination instead of any for testing. ( community.sophos.com/.../sophos-xg-firewall-v17-5-how-to-log-all-dropped-traffic-without-interrupting-other-services )