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

Question

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 ): 
 
 checks mx-record for domain.tld , let&rsquo;s assume MX is smtp.domain.tld 
 resolves IP for smtp.domain.tld , let&rsquo;s assume it is 0.0.0.0 
 connects to IP 0.0.0.0 and checks if certificate cn contains domain.tld . 
 
 This works for IP&rsquo;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: 
 
 checks mx-record for domain.tld . Let&rsquo;s assume MX is smtp.domain.tld 
 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!)

Tom Foucha · Accepted Answer

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.

LuCar Toni · Answer

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.

LuCar Toni · Answer

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.

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

Top Replies