Deprecation of TLS 1.0 and how you can help your customers with this change
I have a request which I imagine will benefit a number of your customers.
As you know, O365 no longer supports sending email to legacy Exchange (2003 and older) systems on Windows Server 2003 running TLS 1.0. ( See these articles:
Unfortunately, we have a client that is running such an environment and we are unable to send them email. If you wish to see details, the SR is SRX615081193192636ID.
We have encountered around a dozen other clients who’s email systems do not support TLS at all. For these cases, I have configured a rule which sends email to them using Office 365 Message Encryption (I’ll call it O3ME for short). This didn’t work for the case in question. After speaking to the technician, it appears that O3ME uses Opportunistic TLS. Because of this, delivery to a system which uses TLS 1.0 fails because O365 says “Oh, they negotiate TLS so let’s do it!” but in fact the recipient is negotiating a TLS version that O365 can’t support so the mail fails.
My request is that you provide an secondary O3ME option which can be configured via Transport Rule which will send entirely without the use of TLS. This, I believe, would solve the problem for any Office 365 customer trying to send to a recipient with a legacy system but who cannot do so since your change to deprecate this possibility.
Thank you for your time.
Correct, there was a bug in the implementation of ciphers in 2003. There was a fix available, but not included in the right cumulative rollup. We aren't seeing this issue very much anymore either. Thanks for following up.
This hasn't been an issue for any of our clients in the past 6 months or so, as Exchange 2003 is being replaced more and more.
When I posted this 11 months ago, I also contacted the Microsoft Exchange product team at the same time. They responded with the message below.
The receiving side being on Windows 2003 has a bug which was not properly addressed in 2003. They need to upgrade or disable TLS or remove the broken ciphers (3DES & AES). There are no other workarounds or solutions which would work very well. There is a way to get 2003 to a build which would support AES/3DES, but it is tricky and not recommended. We did attempt to ask Windows for a fix, but it was too late by the time we realized the impact of the problem.
Opportunistic is *supposed* to downgrade when STARTTLS is not advertised – or when the secure connection can’t be agreed upon. However, the Windows 2003 bug (3DES & AES) exhibits itself as a successful negotiation, and even a single packet or two have no issues. But then the stream becomes corrupted and unrecoverable. So it would be really hard for us to overcome that on the sending side – it’s not just a security issue, but a raw socket corruption problem. The sending server would have to be coded to understand and recognize the problem, which would be really difficult to do.
If the recipient side removes the bad ciphers, we would at least be able to not agree on a mutually acceptable cipher, and then opportunistic should work. If you can help me confirm, I’ll update the guidance accordingly."