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.

On a related, but also unrelated question Tom Foucha. If we use "Prefer TLS 1.3", does it also "Require TLS 1.2", or does preferring TLS 1.3 still allow TLS 1.0 and 1.1? Ideally, we'd rather require TLS 1.2 but if 1.3 is available, use that.

Preferred TLS requires 1.2 and above. We will remove complete support for 1.0 and 1.1 by end of year.

Excellent. I had assumed that was the case. Thanks for the confirmation.

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.

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.