7
SmarterMail not secure
Idea shared by Colin M - January 29, 2015 at 9:45 AM
Under Consideration
There are a few important security flaws with my SmarterMail installation. Perhaps I have something misconfigured in which case, please straighten me out. Otherwise I think these are bugs that need to be addressed ASAP.
 
First, SSLv3 is simply *not secure* which is very well established. I don't think SSLv3 should be removed from SmarterMail since some legacy installations might require it, but it should definitely not be depended upon as a solution.
 
Second, TLSv1 is only marginally better than SSLv3 and currently it appears that SmarterMail only uses TLSv1. It should be updated to support TLSv1.1 and TLSv1.2.
 
Last but not least, when adding a port via SmarterMail config and choosing "TLS" for the "Encryption" option, that port is actually enabled for both TLS and *unencrypted* connections! I was quite astonished when I found I could use telnet to connect and authenticate on my server.
 
What all of the above means is that it appears there is no way to configure the server such that:
 
* SSLv3 is disabled for all protocols (except POP since Outlook apparently doesn't support POP over TLS - and is the only client that I know of that doesn't)
* TLS is enabled for all protocols (and ideally TLS 1.1 and 1.2)
* Unencrypted connections are completely disabled for all protocols (except for port 25 for server-to-server communication)
* Authentication over the port 25 unencrypted connection is disabled (to prevent users from unknowingly using an insecure connection)
 
Notes about my installation:
- Windows 2008 R2 with all updates current
- SmarterMail 12.3
- IIS 7
- TLSv1.1 and TLSv1.2 both work on IIS (enabled using Nartac IIS Crypto)
- TLSv1.1 and TLSv1.2 DO NOT work on SmarterMail ports (pop, imap, smtp)
- SmarterMail IP Binding only binds to ports that are configured for "TLS"
 
I've tested all of the above stated facts using telnet for unencrypted and the openssl command line for encrypted. E.g.:
 
These tests FAIL:
 
> openssl s_client -starttls imap -tls1_1 -crlf -connect mail.example.com:143
> openssl s_client -starttls imap -tls1_2 -crlf -connect mail.example.com:143
 
These tests SUCCEED:
 
> openssl s_client -starttls imap -tls1 -crlf -connect mail.example.com:143
> telnet mail.example.com 143
> openssl s_client -tls1_1 -crlf -connect mail.example.com:443
> openssl s_client -tls1_2 -crlf -connect mail.example.com:443
 
EDIT: So these tests prove that enabling TLSv1.2 for IIS (https) does not also enable it for pop/imap/smtp. Also, enabling TLS in SmarterMail enables unencrypted on the same port. I understand the connection has to start out unencrypted for the STARTTLS command, but it should not allow AUTH LOGIN on an unencrypted connection that is configured to be "TLS".
 
At this point the most secure way to configure the server appears to be to not use TLS at all and only support SSL which means that the completely broken 18 year old protocol is the best that SmarterMail can really support and enforce at the same time!
 
Am I wrong?

7 Replies

Reply to Thread
0
Robert Emmett Replied
January 29, 2015 at 3:17 PM
Employee Post
Colin M and Nathan Y, thank you for bringing this topic up.  You are correct in that SM currently only supports TLS v1.0. Currently, SM is built on the .NET Framework 4.0 which only supports TLS v1.0.  We are planning on moving onto .NET Framework 4.5 with SM 14.  The primary reason that we haven't already made the transition is that fact that Windows Server 2003 does not support that .NET Framework.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Robert Emmett Replied
January 30, 2015 at 9:16 AM
Employee Post
Colin,
 
Are you looking for a TLS Only only for port 587?  I can definitely see the validity of this request.  It would have to accept more than just he STARTTLS command though, for example, EHLO, NOOP, HELP, and QUIT should be acceptable unencrypted commands.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Bruce Barnes Replied
January 31, 2015 at 1:10 AM
Until the E-Mail industry mandates TLS for inter-MX server traffic, via an IETF mandate, you cannot enforce TLS on port 25. To do so, will block a LOT of legitimate e-mail.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Robert Emmett Replied
February 2, 2015 at 2:37 PM
Employee Post
Colin, I am changing this thread from a problem to an idea and marking it as Under Consideration to facilitate development tracking.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
3
Mike Zieman Replied
February 2 at 4:12 PM
This thread needs a bump.  It's now 2017, on SM 15, and this feature is still "under consideration". 
 
I agree with Collin M- this is a very important feature for an increasing number of business segments.  It does not seem that implementing a solution is very complex and clearly competitors of SM have supported this for a long time.  If SM is truly marketed as a commercial, enterprise-ready alternative to systems like Exchange, etc, the ability for mail administrators to ensure security, both between client and SM, and, where necessary, between SM and another MX host is critical these days.
 
I would argue for the additional ability to specify a list of recipient domains for which TLS is required for sending mail.  Other enterprise mail servers accommodate this; the value being it ensures that traffic to those certain domains is always sent securely, even if other domains not on the list can't/don't use TLS when accepting mail from SM.  What we're saying is, for those domains on this Force-TLS list, it's not good enough to "prefer" TLS when contacting another MX to deliver the mail; it's TLS or fail the outgoing message.  Domains not on that list can "prefer" TLS or still send plaintext as happens today. 
 
These features would help us be certain that messages to specific domains are delivered securely, which is a requirement for many in my business segment.  I like SM, but unfortunately now I'm searching for a replacement that has this capability or I'm losing my business to others who use your competitors' products.  Please step up!!
4
Tony Evers Replied
February 22 at 8:40 PM
Bum-pity Bump - Yes - I'm out here tonight trying to figure out how to FORCE TLS on 587.  If users want to go unencrypted - go ahead and use port 25 - see if I care, but if you are authenticating using 587, I want to force you to use and encrypted connection.  
 
Even SMTP service on Windows Server 2003 in the IIS 6 SMTP manager has a check box "Require TLS encryption" -
2
Lucas Gomez Replied
May 3 at 9:00 AM
Any updates?

Reply to Thread