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
  • +1 person also asked this people also asked this
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 6133 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]
  • 0

    Hello there,

    Thank you for your feedback. We regret to hear that Sophos's Email service might not cover your email scenarios.

    Can you share any Case ID here or via DM about what you’re mentioning? I couldn't find any attached to your account.


    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • 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.

  • +1 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.

  • 0

    I was looking into this from a external perspective. 

    Looking into this, i was verifying how other hosters work, which are used by Email Servers. Could you give me (via PN?) an example of a hoster, which is not reachable via TLS? 

    Because i am not aware of any customer saying, TLS is not possible with a public hoster. 
    I also independently tried huge public hosters, all of them worked fine. 

    __________________________________________________________________________________________________________________

  • +1 in reply to LuCar Toni

    Additionally, i could successful send TLS encrypted Emails with CEMA by using additional policy.

    CEMA supports an exclude/include principle.

    You can have a encryption profile, using "Verify certificate". 
    And if you have TLS errors, you can add another profile, adding the domains, which are not working, and do only TLS1.3 without verify the certificate.


    The option here "external" can match domains and you can specify an additional TLS Rule for those domains.

    You still enforce TLS here, you simply are not verifying the certificate anymore. 

    Which is, in terms of your examples, in some cases invalid anyway. So either you cannot send them emails anymore or you exclude them. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I want to add some more insights to this thread. 
    Sophos CEMA uses postfix. 
    Postfix has a feature, which we use, called "verify certificate". Just a short story about this feature: If you build up a connection to a SMTP Server port 25, Postfix will try to start a TLS connection after the initial ehlo. 

    Postfix will compare both components: the SMTP hostname, used by the server in SMTP, and the certificate. 
    If both mismatch, the "verify certificate" is failed. 

    Public hoster of email services workaround this system by using their own certificate and not adding every customer to their certificate. Because at this point, if you start a SMTP session, the email server does not know, what domain you want to reach. 

    Therefore it is quite unusual to have a "customer specific certificate" on a hosting service. 

    In this thread, it was identified, if a RCPT uses this kind of configuration, Postfix will deny the communication, if postfix is setup to verify the certificate. You can exclude it, as described above. 

    __________________________________________________________________________________________________________________

Unfiltered HTML