DPI / TLS Scanning exception issue with d1. d2 d3.sophosupd.com when installing Intercept-X for Mac

Hello LHerzog,

May be the following KBAs would help, if you add the certain domains and ports into the exception of the FW rather than scanning them !!

> Domains and ports to allow: https://docs.sophos.com/central/Customer/help/en-us/PeopleAndDevices/ProtectDevices/DomainsPorts/index.html
> Exceptions: https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Web/Exceptions/index.html

Thank you Vivek. I expect our exception lists are well filled. And we can see the firewall traffic of that client only hit the desired firewall rule that contains all the central domain exceptions.

I'd like to know why all those Sophos domains cause the same error in the DPI logs.  "Server did not respond to client hello"   That should concern Sophos, doesn't it?

Likely this could be an issue with your connection as well. That is the reason to check the tcpdump. If we see an reply, the firewall is doing the blocking. If we see no replies at all, this could potentially mean, your ISP or the service is blocked. But as nobody right now is reporting this issue, this could mean, your ISP does something with those packets or potentially the packets get corrupted by the DPI. 

There are a lot of IFs right now. I would not say, this is a general issue. 

I do not expect a server side / ISP issue. I suspect some TLS decryption issue.

May I send you a dump of my client and the firewall for a simulated connection to d1, d1, d3 and dci LuCar Toni ? What do you think of it?

On the Client I see Server hello but on the XG there are a lot of retries for server hello.

What do you mean by retries on Server Hello? And how can the Client see the Hello but SFOS not? 

that dump is from XG

Hey LHerzog,

Can you share a pcap file with us which is captured from the SFOS ?
Create and download a packet capture : https://support.sophos.com/support/s/article/KB-000037007?language=en_US
Ensure to capture "destination base." 

I have those files Vivek, can I sent it as message to you?

Do not check for source. Follow the IP Stream in Wireshark. You should see the entire communication. 

And check both ends (SFOS to Client and SFOS WAN to Server). 

Compare both. 

Sure LHerzog !!

I filtered only for better view. I have the entire communication of the two IPs. I will send to Vivek. It's small.

I filtered only for better view. I have the entire communication of the two IPs. I will send to Vivek. It's small.

Vivek you have the files.

the Sophos Endpoint is of course also involved. It decrypts and does MIM after the Firewall.

The correct filter would be the following: "tcp.stream eq 0 || tcp.stream eq 1"
You can share the out of the advance firewall from the console !!

And the following is from the client dump:

This looks fine. And this is with an error in TLS Logviewer? Or does this work? 

yes. two for each server connects.

Can you share the out of the following:
console> show advanced-firewall
============================
try toggling the following:
>  TCP Seq Checking 
>  TCP Selective Acknowledgements
>   Midstream Connection Pickup
See if that makes any difference upon toggling on/off this options !! LHerzog

Thank you, I will test changing those options after hours.

        Strict Policy                           : on
        FtpBounce Prevention                    : control
        Tcp Conn. Establishment Idle Timeout    : 10800
        UDP Timeout                             : 30
        UDP Timeout Stream                      : 60
        Fragmented Traffic Policy               : allow
        Midstream Connection Pickup             : off
        TCP Seq Checking                        : on
        TCP Window Scaling                      : on
        TCP Appropriate Byte Count              : off
        TCP Selective Acknowledgements          : on
        TCP Forward RTO-Recovery[F-RTO]         : off
        TCP TIMESTAMPS                          : off
        Strict ICMP Tracking                    : off
        ICMP Error Message                      : allow
        Caching for route lookups               : on
        IPv6 Unknown Extension Header           : deny

I changed those adv. FW options.

Toggled them all, toggled a single of them...

but unfortunately this did not change the behaviour. if accessed, those 4 test FQDN still generate the error in TLS log.

I believe this is an Intercept-X endpoint https decrypt issue. Will test some more at later time.

just a quick info:

What is common with all failed requests is the cipher suite and that is uses TLS1.3

There are also successful requests to those sophos servers, but they are all TLS1.2 and have an other cipher suite:

That one is always failing, no single success in our logs:

2022-08-04 19:25:36SSL/TLS inspectionmessageid="19017" log_type="SSL" log_component="SSL" log_subtype="Error" severity="Information" user="xxx" src_ip="172.16.xxxxxxx" dst_ip="184.30.25.172" user_group="xxxxx" src_country="R1" dst_country="DEU" src_port="58841" dst_port="443" app_name="" category="Software Updates" con_id="3403381952" rule_id="0" profile_id="1" rule_name="System exclusions" profile_name="Maximum compatibility" bitmask="" key_type="KEY_TYPE__UNKNOWN" key_param="Unknown" fingerprint="" resumed="0" cert_chain_served="TRUE" cipher_suite="TLS_AES_256_GCM_SHA384" sni="cloud-assets.sophos.com" tls_version="TLS1.3" reason="Server did not respond to client hello" exception="" message=""

Hey LHerzog,

Can you execute the following commands from the advance shell of the SFOS and from the windows client machine in powershell and check the results:

#openssl s_client -connect d2.sophosupd.com:443 -tls1
#openssl s_client -connect d2.sophosupd.com:443  -tls1_1
#openssl s_client -connect d2.sophosupd.com:443 -tls1_2
#openssl s_client -connect d2.sophosupd.com:443  -tls1_3

Based on the reporting you shared, there are chances they you may not see a negotiation established on TLS 1.3