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.

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

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

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!)



This thread was automatically locked due to age.
Parents
  • 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. 

    __________________________________________________________________________________________________________________

Reply
  • 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. 

    __________________________________________________________________________________________________________________

Children
  • 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. 

    __________________________________________________________________________________________________________________

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

    __________________________________________________________________________________________________________________