Sophos Email customers using IP-based mailflow rule connectors must migrate to certificate-based configuration by March 31st. To see if you're affected Click Here.

Thread Info
  • State Verified Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 585 views
  • Users 0 members are here
Options
Suggested

Why you may be better not use Sophos Email solution as of now

Fred12

We did move away from Sophos Email and here is why we decided to do so.
TLS is a fundamental requirement not just for Websites (HTTPS)  but also for mail exchange and enforced by Central Email. If your company relays on information security certification as ISO27001 or SOC2 or requirements by law (KRITIS) you may have several requirements to not just use techniques like TLS, but also verify their functionality. That includes to check certificates used for communication e.g. do they have a valid chain of trust, are they not rejected or check if they are intended for that target (domain name match).

Sophos Email and SFOS (firewall) checks T LS-certificates by default not just for HTTPS but also for other TLS connection (SMTP). We thought that would meet our requirements as mentioned before. Soon we noticed the certificate check for SMTP does not work as expected. Several domains could not be reached because certificate validation does fail. Quickly it turns out it fails because Sophos certificate check does not work as it should.

What is really annoying, after several month of trying to explain the certificate check does not fail because of incorrect remote hosts configuration, but incorrect certificate check from Sophos involving GES, engineering and product management, Sophos confirmed the issue. However, they also mentioned to have no plans to fix BUG but maybe concluded it as a feature request with no plan to work this for now.

Technical details and what domains are affected:

Sophos checks certificates on SMTP like this example (mail@domain.tld):

  1. checks mx-record for domain.tld, let’s assume MX is smtp.domain.tld
  2. resolves IP for smtp.domain.tld, let’s assume it is 0.0.0.0
  3. connects to IP 0.0.0.0 and checks if certificate cn contains domain.tld.

This works for IP’s only serving one domain (certificate) and do not use SNI (see RFC8446, RFC6066).

The issue:

TLS-vhosts usually running multiple domains on a single IP. If you connect to IP,  no SNI is provided and remote server uses default certificate. That would most likely differ from certificate server would provide using FQDN / SNI and certificate check fails for good reason.

How certificate should work:

  1. checks mx-record for domain.tld. Let’s assume MX is smtp.domain.tld
  2. connects to FQDN smtp.domain.tld and checks if provided certificate is valid for smtp.domain.tld.

As many freelancer, smaller or midsize companies do use web and mail server with TLS-vhosts support of SNI is fundamental functionality in 2024!

For Central Email we did not find how to disable those checks what means we could not send mails to affected domains.
For Sophos Firewall you can disable certificate check globally (allow invalid certificates) but with that you may not meet legal or certification requirements anymore. (Beside we do not want to pay for Email Protection but then disable significant parts!)



Edited TAGs
[edited by: Raphael Alganes at 11:12 PM (GMT -7) on 16 Sep 2024]
Parents Reply Children
  • 0 in reply to emmosophos

    Without Case ID or more information this cannot be validated. 

    Also: For Central Email we did not find how to disable those checks what means we could not send mails to affected domains - Sophos Email in preferred TLS doesn't require the strict validation check that TLS Verify does. So not sure why you believe that we can't disable for those domains. Please open a support ticket and escalate further to myself if necessary.

  • 0 in reply to Tom Foucha

    Maybe we did not find that, but as mentioned for the firewall already: With disabling, we not meet legal or certification requirements anymore. We also do not want to pay for Email Protection but then disable significant parts, just because functionality does not work as specified in RFC.

  • 0 in reply to Tom Foucha

    I will add this from Postfix documentation: Currently Sophos Email does not support DANE. We will examine the use of SNI name carefully as noted it can break things for servers not setup.

    smtp_tls_servername (default: empty)

    Optional name to send to the remote SMTP server in the TLS Server Name Indication (SNI) extension. The SNI extension is always on when DANE is used to authenticate the server, and in that case the SNI name sent is the one required by RFC7672 and this parameter is ignored.

    Some SMTP servers use the received SNI name to select an appropriate certificate chain to present to the client. While this may improve interoperability with such servers, it may reduce interoperability with other servers that choose to abort the connection when they don't have a certificate chain configured for the requested name. Such servers should select a default certificate chain and continue the handshake, but some may not. Therefore, absent DANE, no SNI name is sent by default.

    The SNI name must be either a valid DNS hostname, or else one of the special values hostname or nexthop, which select either the remote hostname or the nexthop domain respectively. DNS names for SNI must be in A-label (punycode) form. Invalid DNS names log a configuration error warning and mail delivery is deferred.

    Except when using a relayhost to forward all email, the only sensible non-empty main.cf setting for this parameter is hostname. Other non-empty values are only practical on a per-destination basis via the servername attribute of the Postfix TLS policy table. When in doubt, leave this parameter empty, and configure per-destination SNI as needed.

    This feature is available in Postfix 3.4 and later.

  • 0 in reply to Tom Foucha
    Tom Foucha said:

    I will add this from Postfix documentation: Currently Sophos Email does not support DANE. We will examine the use of SNI name carefully as noted it can break things for servers not setup.

    Sophos should focus on rules and regulation at first.
    Yes, it could break things for servers not setup correctly but that is exactly intended behavior of that check and requirement.  

    For what reason Sophos decides to better break functionality for implementation following the rules over implementation not following the rules? That can't be for real.
    You maybe also runs statistics of servers not setup certificate as they intended to do in cooperate environment . You will notice there are almost none for good reason.

Unfiltered HTML