Securing SmarterMail - Requiring SSL/STARTTLS For Email Clients

Question asked by ScottF - 2/22/2019 at 11:34 AM

Unanswered

We would like to require our customers' email clients to use SSL/STARTTLS. So far we disabled the ports 110 and 143 in SM Settings to secure POP and IMAP. Next we would like to secure SMTP. This would be the SMTP connection (when sending a message) from a user's email client (ie MS Outlook) to our SM server. We have not found a way to enforce STARTTLS.

Has anyone else found a way to enforce a secure SMTP connection from a SmarterMail user's client to the server?

20 Replies

Reply to Thread

Steve Norton Replied

2/25/2019 at 11:13 AM

Have the email clients send to port 465 and use SSL for encryption, never send to port 25 as STARTTLS is sent cleartext and is subject to man in the middle attacks.

ScottF Replied

2/25/2019 at 11:45 AM

Thanks Steve. Good recommendation. Have you found a way to prevent users from sending to port 25 in SmarterMail? Is there a setting to only allow users' email clients to send with 465 w/ SSL? Thanks.

Steve Norton Replied

2/25/2019 at 12:25 PM

To be 100% secure you need to tackle that on the client, an enforced outbound firewall rule to only allow connections to port 465 on your SSLd SM server from the mail application exe and to block all other outbound connections from that exe. If you don't tackle it on the client malware can redirect outbound mail to another server on the Internet so no SM security would help.

ScottF Replied

2/27/2019 at 1:27 PM

Thanks Steve. That's a great way to setup SmarterMail at an organization.

Our challenge is that our many customers are at different locations that we do not or want to administer. We can not enforce outbound firewall rules on the client side.

We're looking for a way to enforce SSL on the SM server side. We were successful with POP and IMAP but not SMTP.

Steve Norton Replied

2/27/2019 at 2:18 PM

If the clients are on known subnets (LAN or VPN) you could block inbound port 25 from those subnets on the SM server so they can only use port 465.

CTL Replied

2/27/2019 at 10:28 PM

For SSL v2 & v3 have vulnerability and TLS 1.2 stable version of safe mail transfer. Latest smartermail have option to enforce https on domain level and then disable V2 & V3 from server side and enable TLS 1.2 ( Not recommended TLS 1.0 & TLS 1.1 ) , Also recommend firewall allow only port 443, 143 & 25 rest of the port like pop3 110 ,465 , etc should be closed or not open firewall .

Make sure your third party certificate in proper installation, no further vulnerability in IIS

Disabled ssl v3 v2 DIH

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000

DIH

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman] "ServerMinKeyBitLength"=dword:00000800

Finally test your certificate the following sites for highest rating A or A+

https://www.ssllabs.com/ssltest/

https://www.checktls.com/

I hope the above settings have strong recommendation for Transport Layer Security

FYI - The above settings for Windows 2012 R2

Michael Replied

3/3/2019 at 5:20 PM

Here's what I believe is the plain issue for many of us...

Users are using either OUTLOOK 2013/2016, iPhone, or Android as their mail client (not webmail).
We want to disable these users from authenticating SMTP on port 25. Much like how GMAIL will not allow users to connect SMTP on port 25 and authenticate/send from Outlook or other mail clients.

Setting a firewall rule on the client's windows machine is not feasible.

This has to be solved Server-side.

It's nice to say "always use port 465" but if a user goofs and sets up regular SMTP over port 25, they're at great risk and it's too easy to fumble this on the client side.

Of course on the Smarter Mail server we need to be able to have port 25 open to accept inbound mail from the world, but port 25 should not be open for SM domain users to authenticate by SMTP and send outbound mail.

We need a control here that might be something like "Do not allow SMTP authentication on Port 25"

If the connection comes on Port 25, then do not allow cmd: AUTH LOGIN

Right?

Michael Replied

3/3/2019 at 5:34 PM

Or perhaps change the function of the "Disable AUTH LOGIN method for SMTP authentication" setting to:

Functionally disable AUTH LOGIN... if SMTP authentication is coming on a port that does not have SSL or TLS enabled (from the bindings setup).

Wouldn't that solve all this?

Or I guess what we're asking is another SMTP IN setting checkbox along the lines of:

"Only allow AUTH LOGIN method for SMTP authentication on SSL/TLS encrypted ports"

ScottF Replied

3/4/2019 at 11:52 AM

Michael, that's exactly what we are looking for!

The "Disable AUTH LOGIN method for SMTP authentication" feature worked like you described above in SM 15.7.6915. Then SM 15.7.6956 included the change "System admins can now disable SMTP AUTH LOGIN even when using SSL connections." which forced us to uncheck this feature for our MS Outlook users. In the end this made our SM servers less secure.

kevind Replied

3/5/2019 at 1:26 PM

Yes, installed the latest version of SM15 (15.7.6970) and it broke Microsoft Outlook!

Only way to fix it was to uncheck this setting which has been checked for many years:

[ ] Disable AUTH LOGIN method for SMTP authentication

This allowed Outlook to send, but now clients can send with plain text authentication???

This latest release fixed a few bugs, but opened up a new security hole. Just hoping we can get one last build of v15 to close up this vulnerability.

Thanks!

Michael Replied

3/5/2019 at 1:39 PM

It's be great to get some senior eyes at Smarter Tools on this topic.

Steve Norton Replied

3/6/2019 at 8:58 AM

If you used SSL on port 465 this would not be a problem. If you need users to send mail from any global IP address put port 465 from your authenticating server on the Internet and have a separate gateway server listen on port 25 which can route domain email to the authenticating server via an internal secure private IP address. The gateway server can be your MX record and port 465 can be put in the autoconfig.xml for your users to use. Using port 25 for your users is at best subject to man-in-the-middle attacks and at worst, if there are vulnerabilities or configuration issues, allowing users names, passwords and email contents to travel clear text over the Internet. This is in breach of any countries data protection policies and if you can be subject to large fines for doing it.

ScottF Replied

3/7/2019 at 12:11 PM

Trusted Senders and Greylisting doesn't work well with separate gateways routing incoming mail. We prefer a server-side solution.

Michael Replied

3/7/2019 at 2:11 PM

It seems a no-brainer and I'm disappointed that there is still no official reply from Smarter Tools. I'm hoping it will come shortly.

These days every major commercial mail service requires authentication and communication using only encrypted ports and methods (see: https://support.office.com/en-us/article/pop-and-imap-email-settings-for-outlook-8361e398-8af4-4e97-b147-6c6c4ac95353).

Currently in Smarter Mail, with some tinkering, we can prevent access to retrieve un-encrypted POP and IMAP connections (by disabling ports 110 and 143) ... but there is currently no server-side solution that I'm aware of to either a) require all connections to the mail server to have valid SSL or TLS encryption or b) require SMTP Authentication on only specific ports generally used for encryption.

In my eyes this is a big problem and it needs Smarter Tools senior eyes for a smart and sensible server-side solution.

kevind Replied

3/8/2019 at 2:42 PM

@Michael Breines, well written! This is a vulnerability that needs to be addressed in version 15 and possibly 16/17.

It worked securely until 2 months ago. Outlook users could use SMTP AUTH LOGIN over SSL with this box checked: [X] Disable AUTH LOGIN method.

Then version 15.7.6956 (Jan 17, 2019) had this in release notes:

Changed: System admins can now disable SMTP AUTH LOGIN even when using SSL connections.

which broke Outlook over SSL. So now we have to uncheck the Disable AUTH LOGIN which allows users to send insecurely!

As @Steve Norton pointed out:

is at best subject to man-in-the-middle attacks and at worst, if there are vulnerabilities or configuration issues, allowing users names, passwords and email contents to travel clear text over the Internet. This is in breach of any countries data protection policies and if you can be subject to large fines for doing it.

Having to set up a 2nd server as an inbound gateway to fix a vulnerability introduced in the Jan. 2019 build is not the answer because as @Scott Forsythe pointed out, that creates even more issues.

If I'm missing something, please let me know. Thanks in advance for looking into this!

Kyle Kerst Replied

3/11/2019 at 4:55 PM

Employee Post

Typically how I handle this is as follows:

- Set up client (user) access to SMTP ONLY on port 465 (SSL)

- Bind TLS certificate to SMTP port 25 in Settings>Bindings.

- Enable TLS if supported by remote server in Settings>Protocol Settings>SMTP Out

- Restrict SSL/TLS protocol usage to best practices using IIS Crypto

This configuration offers ONLY a TLS secured port 25, and an SSL secured port 465 for user SMTP usage. This will still allow less secure (not using SSL/TLS) third party email servers to deliver email to your server successfully over port 25 (preventing NDR/missing email due to lack of secure channel), but will keep end users sending/receiving email to/from your server securely over port 465. This does not completely disable non-secure port 25 access as the non-secure connection must be established in order to convert the session to TLS based SMTP first. This must be available to ensure smooth delivery of third party email to your server as external mail servers will ONLY connect to your server to deliver mail over port 25. Additionally, there is a HUGE number of email servers still out there that don't offer TLS on port 25 at all, meaning this email will never make it to your server without the non-TLS option available. More secure environments drop ALL non-TLS/SSL encrypted traffic on port 25, and instead set up a secondary or tertiary MX server with more lax requirements to facilitate delivery in these cases.

If end users are connecting only via port 465 on SSL, no usernames and passwords are transmitted cleartext. If you're ONLY allowing external mail servers to use port 25, no usernames or passwords are transmitted as the third party mail server does not need to authenticate to deliver mail to your users as its acting as an MTA.

Unfortunately this isn't something where a one size fits all fix will work, due to the variety of ways in which users are connecting to the server, the types and security levels of the businesses you send/receive email from, etc. Hopefully this helps point you in the right direction and sheds light on how we're handling this here.

Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com

Michael Replied

3/17/2019 at 11:28 AM

#1-- Kyle: Are you saying that if a TLS certificate is binding to port 25 then plain text/non-encrypted connections will not be allowed on port 25? I'm not entirely sure that is the case, but look forward to your confirmation, that if I try to send from Outlook SMTP over port 25 and authenticate... if I have TLS binding to port 25, it will encrypt?

#2-- What we're asking here is a control that will prevent mail server users from sending mail / authenticating on port 25 plan text. Turn it off. Do not allow sending or authentication over port 25. This has largely been turned off by GMAIL, O365, YAHOO, Etc. OK allow inbound mail port 25, fine. We understand this must exist. But SMTP outbound sending should be able to be turned on/off.

#3-- What is the meaning of the release note for 7008:

Build 7008 (Mar 10, 2019)
Changed: Behavior of "Disable AUTH LOGIN for SMTP authentication" setting works for only non-SSL SMTP connections now (changed setting name to reflect this behavior).

Does this mean some progress is being made?

Will these changes be rolled back to v15.x?

Matt bernard Replied

3/29/2019 at 6:16 AM

Hi, just botched my clients by upgrading my server 15.7 latest. Does anyone have a link/file to the 15.7 6915 build?

Thanks!

One Click Technology Group, LLC

kevind Replied

3/29/2019 at 6:47 AM

You'll need to uncheck "Disable AUTH LOGIN method for SMTP authentication." This will allow MS Outlook to work, but will make your server less secure.

Too bad this problem was introduced in the 2nd to the last release of v15. Would be nice to have a final public release that corrected this.

Sébastien Riccio Replied

5/13/2019 at 8:25 AM

Hi,

We've just noticed, despite our config shouldn't allow it, that any client can authenticate without issuing TLS first on both port 25 and 587. There are two problems here:

1) We don't want port 25 to allow any kind of auth but only answer to regular incoming SMTP traffic (so trying to auth on this port should be rejected and no AUTH capability should be announced, it's not a submission port!)

2) We do not want any SMTP or SUBMISSION port to allow to start an AUTH procedure if there wasn't a successful STARTTLS negotiation first.

That's how it's done since ages on all other MTAs we use, but I can't see where I can configure this in SM.

Maybe I'm missing something. Any hint on how to configure this ?

Thanks

ps: Forgot to mention we're on SM16. We are not yet ready to upgrade our production to SM17

Sébastien Riccio System & Network Admin https://swisscenter.com

Back to Community Threads

Please leave this box unchecked

20 Replies

Reply to Thread

Tags

Related Knowledge Base Articles