Seeing lots of TLS Handshake errors on Server 2012r2 clients

Like the title says I am seeing a huge volume of SCHANNEL error events in my Server2012r2 severs that are all relating to requests to 4.sophosxl.net 

From what I can tell that URL is supporting a narrow string of Cipher suites for TLS 1.2 that were only introduced to Windows Server in Server 2016. Is anyone else seeing these events on clients with Sophos Endpoint Agent installed and running older (but still supported) versions of Windows Server?

Parents
  • Hi There,

    Thank you for reaching us, related to this SCHANNEL  error event that you're getting, there will be an exclusion that needs to be done in order to reduce this load. of events. To further understand SXL4 you may refer to this documentation. For the error that you're getting can you share with us the error details? 

    Glenn ArchieSeñas (GlennSen)
    Global Community Support Engineer

    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • Thanks for the reply, I have a support case opened for this right now as well, Basically we receive the following error approximately every 30 seconds on our domain controllers, less frequently on other Server 2012r2 devices but still the same error:

    A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

    Using Wireshark you can see that our Server 2012r2 servers are sending a client hello using the following TLS 1.2 ciphers:


    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA

    However, using nmap if you query the TLS 1.2 ciphers supported by 4.sophosxl.net you will get:

    | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
    | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
    | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
    | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A

    Support for those ciphers was not introduced to Windows Server until Server 2016, so a Server 2012r2 client will never be able to successfully complete a TLS handshake with that URL.

    Since that URL is AWS hosted, I have a feeling that the TLS 1.2 ciphers are using TLS1.2_2021, the following link documents supported ciphers for AWS https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html

  • Hello mthi0591,

    Could you verify if the following two Windows Updates are installed on your devices?
    - Update to enable  TLS 1.1 and TLS 1.2 as default secure protocols in  WinHTTP in Windows

    July 2016 update rollup for Windows 8.1 and Windows Server 2012 R2

    Let me know if you see any improvements after installing these. 

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • - Yes we have had KB3172614 installed for some time on this server, so installation predates this issue

    - I do not believe the first link you sent is applicable for Server 2012r2, regardless we control TLS protocols via GPO configured registry settings as is standard. I can verify with wireshark the servers make successful TLS 1.2 handshakes all day with other clients, it is just the 4.sophosxl.net URL that they are having issues with. Apparently this was an issue in the past with Sophos releases when SSLv3 support was removed, many admins chose to just black hole 4.sophosxl.net via a host file entry pointing to 127.0.0.1. I would rather not do this as it would more than likely remove the errors we see at the expense of fundamentally breaking reputation lookup (which appears to be the case anyways for clients that do not support the ciphers that 4.sophosxl.net suppports)

Reply
  • - Yes we have had KB3172614 installed for some time on this server, so installation predates this issue

    - I do not believe the first link you sent is applicable for Server 2012r2, regardless we control TLS protocols via GPO configured registry settings as is standard. I can verify with wireshark the servers make successful TLS 1.2 handshakes all day with other clients, it is just the 4.sophosxl.net URL that they are having issues with. Apparently this was an issue in the past with Sophos releases when SSLv3 support was removed, many admins chose to just black hole 4.sophosxl.net via a host file entry pointing to 127.0.0.1. I would rather not do this as it would more than likely remove the errors we see at the expense of fundamentally breaking reputation lookup (which appears to be the case anyways for clients that do not support the ciphers that 4.sophosxl.net suppports)

Children
No Data