Sophos Secure Message? Where is it?

David,

you can use Data Control to create the policy that uses keywords to enforce PDF encryption which all our customers have access to. If you would like Portal Encryption with customization that is a separate license CEMA-PE-ADDON, please contact your sales team.

It is likely that those 10% would fail, while I can't say without looking deeper but Prefer TLS 1.3 will downgrade TLS versions if 1.3 is not available and if you uncheck "Allow unencrypted delivery" if TLS cannot be established it would fail to send those messages.

Tom Foucha 

Good to know, regarding TLS 1.3. We are in contact with support for over a month now regarding this issue. Because 10% of our outbound emails are failing due to this TLS Problems. I am really wondering why there is no KB or support article about this.

Because there is a big warning "not recommended" in central using unencrypted delivery, we extra created an exception rule for that, adding domain after domain when a new one fails. This is really annoying and time intensive.

It's really a pity why support doesnt know that issues and just would say: "we know that already and are investigating, stay tuend..." e.g.
Instead a lot of communication with support, dev, ges, happened, and a lot of try and error happened. we could have saved so much time if this error would be officially documented or communicated.

Regards

Peter

Sophos Support are not great. Better to Google around yourself (all they do is follow KB articles, sometimes over and over again) and if you're stuck, post in these forums. I've found that nets a better result, and Tom is helpful and knowledgeable.

I don't quite understand what your issue is though. You should not be allowing unencrypted messages. TLS1.2 has been standard for many years, and recently mandated by some mail providers. There is no way I would ever create exceptions. I'd take the approach of if someone doesn't use TLS1.2 as a minimum, they can't email my customers. Providing workarounds to get around lazy security is not a good idea IMO.

while setting outbound emails "select tls version: prefered tls 1.3" the mentioned round about 10% emails are failing. hence we have to set an exception rule for this 10% allowing unencrypted delivery. Even going down to 1.2 doesnt help/work. in our scenario not allowing unencrypted delivery for this 10% is not an option for us, while there are issues with prefered tls 1.3 settings. Regarding these 10% there are a lot of big companies and institutions affected we have to communicate with hence we have no choice.

But you are right, providing workarounds to get around lazy security is a no go. we have another issue open at sophos support, where the problem isnt solved till today. The current recommended steps from support are ridiculous and i refused them to do. Lets see whats up next...

If that's the case, it sounds like 10% of your emails doesn't confirm to TLS1.2 - that would be a massive concern for me. Any big company or institution should support TLS1.2. If not, bad luck IMO. If your systems are compromised, or someone gets an email and pays $1,000,000 to some random person, will your response of "we let them come in because they are a big company" be an adequate excuse to your bosses?

Here are my settings for all my clients - with 0 exceptions. If another company doesn't comply, I tell my customers to speak to the person at the other end, point out the holes in their security and ask them to request their IT people fix the problem.

Same with SPF and DKIM. To be honest, it's the lazy bypass rules and work arounds that cause the problems. No-one ever configures their systems properly because they don't need to. If more people said no, no exceptions, we'd have a much more secure digital world.

If that's the case, it sounds like 10% of your emails doesn't confirm to TLS1.2 - that would be a massive concern for me. Any big company or institution should support TLS1.2. If not, bad luck IMO. If your systems are compromised, or someone gets an email and pays $1,000,000 to some random person, will your response of "we let them come in because they are a big company" be an adequate excuse to your bosses?

Here are my settings for all my clients - with 0 exceptions. If another company doesn't comply, I tell my customers to speak to the person at the other end, point out the holes in their security and ask them to request their IT people fix the problem.

Same with SPF and DKIM. To be honest, it's the lazy bypass rules and work arounds that cause the problems. No-one ever configures their systems properly because they don't need to. If more people said no, no exceptions, we'd have a much more secure digital world.

Its sophos email central which causes the issues, not my mails. Thats why we decided to use this solution getting an reliable and professional email gateway. And yes TLS 1.2 should be todays standard, but there are still a lot of systems out which are not using it or configuring it wrong.

If this works for you and your clients its ok, but for us it doesnt. We have to communicate a lot with several (city)governments, public institutions and so on, and we also tried to contact them, but they are not willing to help, or just saying their systems are ok. another answer was, that tls 1.3 is not very reliable and makes a lot of errors (even google knows that he said), hence they are not using it., case closed. And if i would tell my boss we cannot communicate with "government a" because they dont support the super secure email communication with us, he just would say, make it possible because we need it urgently.

Dont get me wrong but your comparison was a poor example.

I would not say it is Sophos Central Email that causes the issue. We are trying to adhere to industry best practices and secure our customers but we do not control the recipients email server or TLS settings. We provide options from Secure to Insecure and allow you to decide what level of risk you find acceptable. A car manufacture doesn't put a throttle limit on the vehicle and puts a speedometer that far exceed legal limits, it is the drivers responsibility to operate in a legal and safe manner. Same here, we provide the tools and recommendations but do not dictate your configuration. I would suggest if you can't send via TLS we provide the Encrypted Message (secure PDF) method. If you are transmitting confidential and sensitive information to a government agency unencrypted I would examine YOUR exposure for data leaks. Companies transmitting highly confidential information like credit cards, HIPAA, banking information in the clear have to accept responsibility and when there are 2 other alternatives in the product, Secure PDF and the add-on Portal Encryption explaining why the data leaked could get expensive. 

Our clients communicate with Governments and international companies and all support TLS1.2

This isn’t a Sophos issue. If you need to transmit insecure email, change the settings accordingly to allow insecure email.

we used sophos sg/utm in the past for years and never had any issues with tls 1.2 and these domains. now with sophos central email the issues showed up with a few certain domains. even when using the option "require tls 1.2" its not working! using the option allow unencrypted is the only way at the moment to get emails out for these certains domains. hence there needs something to get fixed. Because i dont understand, why our former sg system, or any other mail system e.g. M365 works without any issues.

And dont worry, we have a separate email encryption system, where confidential data gets encrypted if necessary, before sending out.

in my opinion it is definitely a sophos issue, because there are too many domains affected in the meantime where this happens.

even  me.com  domain has problems, our would you say apple is not able setting up their email servers accordingly?

Aug 9 15:46:51 Queue: 4RLWYz2q0tz1Lkg: to=<xxxxx@me.com>, relay=relay-eu-central-1.prod.hydra.sophos.com[52.28.110.24]:25, delay=4, delays=0.01/0/0.2/3.8, dsn=5.0.0, status=bounced (host relay-eu-central-1.prod.hydra.sophos.com[52.28.110.24] said: 550 XGEMAIL_0006 Command rejected : Preferred TLS 1.3 (in reply to RCPT TO command))

maybe you are not experiencing those issues, because you are using us or other sophos servers. But with eu central servers there are definitely problems. 

Peter, thanks for the information. One of the enhancements we are working on in our Message History logs is to expose to the admin what level of TLS was attempted and used in message delivery and attempts. I wonder and will investigate if it is actually not the version of TLS affected but the ciphers used that are causing some of the issues. 

The 550 XGEMAIL_0006 means - Returned when the message is rejected because the TLS version used did not match the version configured in customer policy. 

Let me have the team look at the message, if you already have a support ticket open please forward the ticket number to me at tom[.]foucha[@]sophos[.]com if you do not have one open please do so it makes tracking it simpler.

thank you very much, email is on the way.

the extended history log of the TLS Version is urgently needed. glad to hear you are working on it.

btw. when using the verify certificate option, errors are raising and we even have problems sending emails to sophos.com:

Aug 9 17:04:05 Queue: 4RLYH83lXzz1Lkg: to=<support@sophos.com>, relay=relay-eu-central-1.prod.hydra.sophos.com[3.120.51.105]:25, delay=1.4, delays=0.02/0/0.2/1.2, dsn=5.0.0, status=bounced (host relay-eu-central-1.prod.hydra.sophos.com[3.120.51.105] said: 550 XGEMAIL_0006 Command rejected : Preferred TLS 1.3 (in reply to RCPT TO command))

In the meantime we have round about 60 domains affected, which need to be excluded from the main  Prefrerred TLS 1.3 Policy with enabled allow unsecure option, containing, as already mentioned, domains of big governments, institutions, universities etc, hence i cant and i wont believe its a configuration issue on the recipient side.