Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 1419 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Sven Gölles

Hello, 

we are facing this issue from the beginning (pre MR4) and have an open case on it for 3 month which seems stuck. So i´m trying it with a forum post. The XG is a standalone System XG230 (SFOS 18.0.4 MR-4). We have disabled all related features and still we get certificate warnings with signed Sophos SSL CA. This behaviour can be seen in the browser as well as applications like outlook and zoom. Here is the relevant configuration:

Application control is deactivated aswell. Only thing in place is User Authentication via Synchronized User ID and Heartbeat enforcement:

Web Filter log shows denied messages for seemingly no reason:

The machting FW rule is the one descriped above. Im wondering that there are even messages in the Webfilter Log since its disabled.

SSL/TLS-Inspection Log is empty. 

Any Ideas would be much appreciated!



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to LuCar Toni

    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'

  • 0 in reply to Marvin Pofahl

    This was not the solution to the problem, just something we did on the console to address another issue. 

  • 0 in reply to Marvin Pofahl

    Can you show us this rule 10? 

  • 0 in reply to LuCar Toni

    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 )