Michael,

I believe the word is that Microsoft (Outlook.com/Office 365) and Google (Gmail/G Suite) plan to have fully switched to TLS 1.2 by January or February 2020.  I'm not 100% certain about other providers.

We still see a lot of TLS 1.0 connections into our mail server, so it seems like we cannot yet fully disable it. Though, all the big players are all TLS 1.2.

It seems that once Microsoft and Google are fully enforcing only TLS 1.2, that would be the trigger for the rest of us. Since by that point if you aren't exclusively TLS 1.2, you won't be able to talk to account holders working with the big boys. @ben how might we track their official plans, do you know?

Michael,

It seems I was a little off on Microsoft.  Their official timetable for deprecating older TLS versions is June 2020:

https://docs.microsoft.com/en-us/office365/troubleshoot/security/prepare-tls-1.2-in-office-365 

I'm still trying to find the official announcement from Google for you.

Michael,

Just a further update on this.  I still haven't been able to turn up an official announcement from Google regarding Gmail/G Suite.  However, they are definitely deprecating support for older versions of TLS in Chrome by March 2020.  This will effectively render it impossible for anyone using Chrome to access login pages for webmail if they aren't being served over at least TLS 1.2.  

Here's the announcement from the Chromium team:

https://blog.chromium.org/2019/10/chrome-ui-for-deprecating-legacy-tls.html 

Is anyone yet blocking outright TLS 1.0 and TLS 1.1 to their servers?

No, causes delivery issues from other mail servers who do not support TLS 1.2, so we had to revert back to accepting.

Same here. We turned it off and our support calls went through the roof. A lot of mail servers still don't support 1.2 so we have to keep the 1.0 and 1.1 protocols active.

+1 for what echoDreamz and John Marx said.  There are too many mail servers on the 'net that either use TLS 1.0 or no encryption at all.  We had to make a choice between forcing the higher level of security of TLS 1.2 only, or retaining backwards compatibility with older mail systems.  

Our decision was based on these conclusions:
 

We did, however, remove all support for SSL 2.0/3.0 because it's just too old.

Our philosophy is, we offer TLS 1.2 for anyone who wants it.  But we will not "break" connections (yet) for those who aren't at that level.

Running a mail server is an exercise in compromise for most service providers.  Email should never be relied upon as a completely secure method of communication, unless you're using full end-to-end security such as with the ZIX plug-in, or similar.

(Wouldn't it be great if SmarterTools released an envelope encryption plug-in that worked with the major mail clients?)

Not only mail systems, we had hell when we tried it with email clients as well. Older Outlook installs and other email clients instantly went insane.

I agree with Jay, meh security is still better than no security. At least if the server supports TLS 1.0/1.1, it's better than nothing and much better than clients complaining and not giving 2 shits about why it's not working, all they care about is "Where is my super important email that is costing my company 62 trillion dollars per hour".

https://support.google.com/a/answer/9795993?hl=en Google still appears to support TLS 1.0 and 1.1 for it's mail protocols, I suspect for the same reasons we all do, because older mail servers and older email clients.

Now... if we are talking webmail (HTTP), we still support older TLS versions too, but we have plans to try and go away from TLS 1.0/1.1 next year.

Sucks that in 2020, Microsoft and IIS still do not support TLS 1.3, we've had our Nginx/Apache servers with TLS 1.3 support for years.

I had beta tested blocking TLSv1.1, but ran into issues with SmarterMail and Exchange 2016 on Postfix.  I'm thinking something with Windows SChannel.  Blocking TLSv1 hasn't seem to cause any issues that I'm aware of.

Example:

Nov  6 17:55:11 mail postfix/smtp[4639]: warning: server.domain.com[XXX.XXX.XXX.XXX]:25: Invalid TLS protocol list "!SSLv2,!SSLv3,!TLSv1,!TLS1.1": aborting TLS session

Using version 16 of Smartermail.  I had to turn off 1.0 and 1.1 about a year ago after various attacks.  We have had no issues with sending nor receiving.  When you do go to 1.2, you must remember to change the .NET Framework version in the app to 4.6, otherswise you will have issues.

Andrew, you must not have older devices on your server, when we disabled TLS 1.0 and 1.1 we instantly had complaints from older Outlook users, older Android phone users etc. We also saw tons of issues with mail servers having SSL/TLS connection errors when connecting to SM.

No idea what you mean by "change the .NET version in the app". You cannot change SmarterMail's .NET version, it is compiled in the version that they selected, which is 4.6, if you do not have 4.6 or higher installed, SmarterMail wont run at all.

We also tried disabling the older protocols almost 2 months ago and instantly had a lot of clients contacting us with issues so TLS 1.0 and 1.1 are re-enabled for now.

We are a small company, so no one within our org had older devices with issues.  That being said, if we did I would have made them upgrade due to the security issues we had with 1.0 and 1.1 enabled.  I actually had 2 instances where attacks were done that promoted a user to admin.  The hackers were not able to login with that account, but it was a very scary situation.  Going to 1.2 resolved the issue.

The web.config did not have 4.6 specified.  I don't remember if it was 4.0 or 4.5, but I remember I had to change it to 4.6.

Good luck as a massive hosting provider telling customers "oh well, upgrade your device". They will say "oh well, you going to pay for it" or "oh well, here is my cancellation request".

If you had an instance of a user account being promoted to an admin (which I am not sure how that happens, I assume you mean a normal email user was promoted to a domain admin, since normal email users cannot be system admins). You may need to get with SmarterTools on that, cause it sounds like a protentional security issue not related to TLS.

Even Gmail and hotmail still supports older TLS versions. If you are a private organization where you control your users and their devices, it's great. As a hosting provider though, we cannot tell users oh well, upgrade your device.

Yes domain admin, not sys admin.  I raised the issue here on the forums, but was told the answer was to upgrade to ver 17 which was basically still in beta.  I refused to do that with all the issues others were having with it, so I was able to resolve with by removing 1.0 and 1.1.

Can you provide a link, or more information on HOW exactly an attacker self-promoted a user account to domain admin-- and what the TLS version had to do with it?

Andrew,

The community needs more information.

Are you sure that the user was made a domain admin?

What do the log files say?

Did you open a support request?

How do you know it is TLS related?

What exact version of SmarterMail are you running?

Could an IDS block stop this?

This event basically indicates that malicious actors reached into your machine and made a change to a JSON file on your server.

This is a big claim and I believe you. Please provide us further details.

Ron

IMO, I dont believe TLS had anything to do with it. Im not entirely sure it was an attack, perhaps the user was able to get another domain admin account's password?

If there was an issue with SM16 and the answer was to upgrade to SM17, maybe someone from SmarterTools can expand on this? What was the issue exactly? In the past, SmarterTools has been pretty forthcoming with stating security fixes within the release notes.

We have TLS 1.0 - 1.2 enabled and have for years and years and years, been using SM since nearly day 1, we get hit with brute force attempts etc. all day long, but never seen a user get self-promoted to domain admin, so it is a curious statement that requires more info for sure.

This happened over a year ago I believe.  Going from memory, there was a "popLog.log" file with information about an exception being thrown.  I checked the Administrative logs under Troubleshooting and it mentioned about the user being elevated to admin status around the same time as the timestamp on the popLog.  The user in question was an "info" user that no one logs into.  All emails sent to it are forwarded to real users.  Only myself and my backup admin have access to the info account via the Smartermail interface while logged into the server.

Around that same time I was researching what it would take to move our regular application servers to TLS 1.2.  I took a snapshot of the Smartermail VM and removed TLS 1.0 and 1.1 and never saw the issue again.  It might not have been a TLS issue, but it's a damned big coincedence that it stopped after I went to 1.2.

I made a thread about it in these forums.  I was/am on the last version of 16 and was told to go to 17 to see if it resolved the issue.  With all the other users having problems with 17 I was not interested in doing so.

Strange, I dont see how the POP protocol would elevate a SM permission to admin, POP doesnt know about SM permissions, all it knows is POP. I think you may have had some other things going on and you noticed, disabled TLS 1.0/1.1 and didnt see the issue again was just a coincidence.

For reference, here is the link to Andrew's original post back in 2019 about the hack issue (promotion to domain admin) :

-dave