8
Provide a choice of TLS 1.0 or TLS 1.2 in SM
Idea shared by Lakshan Salgado - October 16, 2014 at 10:51 AM
Proposed
SM has stated previously ONLY TLS 1.0 for backward compatibility in  a prior post. I'd like to formally request a drop down for us to choose what version we would like to implement on our servers. (TLS 1.3 in draft can be a later addition)

13 Replies

Reply to Thread
1
John Marx Replied
October 17, 2014 at 5:26 AM
This is, and should be, a server side setting. I know we have TLS 1.1 and TLS 1.2 configured and installed. I can't see having an app do this being that the server does this already. We did try to just use 1.2 as it was newer when the SSL 3 issue was announced. When we did that Gmail stopped working. As such, you need a minimum of 1.1 and 1.2 for gmail to function (at least in our tests).
1
Joe Wolf Replied
October 20, 2014 at 3:52 PM
Here's what my server negotiates with Gmail: (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 
-Joe
 
Thanks,
-Joe
1
malfunction Replied
April 25, 2015 at 7:49 PM
SmarterTools needs to make this a high priority.  PCI 3.1 mandates the use of TLS 1.1/1.2 so where we are running control panel based servers with websites and mail on the same box, we will break SM if we are in compliance. 
0
Bruce Barnes Replied
April 25, 2015 at 8:21 PM
TLS 1.0 is, technically, a depreciated cipher and not allowed to be used.
 

The PCI Security Standards Council has introduced PCI 3.1, and PCI 3.1 mandates that SSL 1.0, SSL 2.0, SSL 3.0, and TLS 1.0 must be removed from all servers which handle credit cards by 30 June, 2016, or you will have your ability to process credit card charges taken away!

The only two encryption protocols now allowed are TLS 1.1 and TLS 1.2.

See my article about the new PCI Standards Council requirements at: https://portal.chicagonettech.com/news/28/new-pci-credit-card-security-requirements-coming.aspx The article includes a link to the PCI Standards website and the documentation of the new PCI 3.1 Standards.

There is, however, a caveat to this scenario, and that is that anyone who is running an Android version lower than Android 4.4 will not be able to connect to any browser or port which supports only TLS 1.1 or TLS 1.2. 

Android 4.4 was released several months ago, but carriers are slow to deploy because they must customize for their own bloatware.  Android 5.0 was released in February, 2015, and Android 5.1 will be released later this month, but may take several months to reach devices because of carrier customization requirements.

Until the carriers push at least Android 4.4 to their devices, and, so long as we do not have a shopping card which accepts credit cards running on the same server as our SmarterMail installations, we all need to continue to support TLS 1.1

TLS 1.3 is currently in the final stages of development and approval and IETF draft RFC #5246 has made significant progress toward that solution.

More information about TLS 1.3 is available here: Secure Crypto: TLS 1.3 – A New Beginning

Summary: 

  • We can continue to run TLS 1.1 on our SmarterMail servers so long as we do not also run a shopping cart which directly accepts credit cards on the same server.
  • The effective date of the new requirement is 30 June, 2016
  • Removing TLS 1.1 on our SmarterMail servers will significantly impact the browsers and devices which can connect if they do not support TLS 1.2 and TLS 1.3
  • TLS 1.3 is in development.
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
malfunction Replied
April 25, 2015 at 10:26 PM
I think you are getting confused between the versions of TLS.  I see no evidence that SmarterMail can utilize anything other than TLS v1.0.  
 
As I said, PCI 3.1 mandates the use of TLS 1.1/1.2 so where we are running control panel based servers with websites and mail on the same box, we will break SM if we are in compliance. 
 
This isn't some future problem, sites with TLS v1.0 still enabled are failing PCI compliance scans NOW, and while there is a year for implementation that's only granted after submitting a detailed formal risk mitigation and migration plan which is not very desirable.
 

 

1
Bruce Barnes Replied
April 26, 2015 at 6:52 AM
The inclusing of TLS is fully dependant on whether or not your server's registry has been configured to allow TLS, and at what level of encryption.
 
The ability to use TLS is dependant on using IIS and is NOT supported when running the SmarterTrack, SmarterMail or SmarterStats web servers.
 
When access to a secured site is made via a browser, the ability of the browser to use SSL/TLS is dependant on whether the browser has been configured to use TLS 1.0, TLS 1.1, and TLS 1.2 - which are not necessarily enabled by default in most browsers.
 
Android devices running versions of the Androis operating system lower than Android 4.4 are not capable of supporting TLS.
 
Whether or not a program or service can utilize the various versions of TLS is not dependant on a program, but on whether the server to which the connection is made is capable of supporting all of the TLS protocols.
 
Some programs and routines (like POP, IMAP, SMTP, LDAP, FTP, and IIS) require both additional capabilities and code be embedded within, and enabled, to utilize the TLS protocol, but the basic TLS capabilities must first be enabled at the SERVER level.
 
For the benefit of those who are less informed about the issues of encryption standards: All versions of SSL have been depreciated and should have been completely disabled at the SERVER LEVEL.  See: https://www.google.com/?gws_rd=ssl#q=ssl+exploit
 
Having stated that SSL is depreciated, and should no longer be in use on any server.
 
TLS is the replacement for SSL.
 
TLS 1.1 and TLS 1.2 are the only recommended protocols which should be in current use.
 
TLS 1.0 is a part of the TLS encryption protocol and, unless a server is also hosting a shopping cart, or other service, which directly accepts credit card payments (orders redirected to 3rd party payment systems like PayPal and Square are currently excluded) the new PCI 3.1 Security Standards mandate that TLS 1.0 be DISABLED on such servers.
 
Neither the disabling of SSL, nor the enabling of TLS is automatic in any server operating system. 
 
While Microsoft pushed a patch on 12 December, 2014, that patch did not fully disable SSL and did not enable TLS on Windows Server 2003, Windows Server 2008, or Windows Server 2012.
 
The complete disabling of the SSL protocol requires either direct registry hacks or the use of a 3rd party software to enable the new protocols and ciphers. 
 
TLS can be enabled in Server 2003, Server 2008, and Server 2012.
  • Server 2003 can ONLY be enabled for TLS 1.0, and does not support TLS 1.1 or TLS 1.2
     
  • Server 2008 can ONLY be enabled for TLS 1.0, and does not support TLS 1.1 or TLS 1.2
     
  • Server 2012 can be fully enabled for TLS 1.0, TLS 1.1, and TLS 1.2
 
Microsoft Technet provides a good starting point for learning more about the aspectes of what encryption protocols and ciphers are supported in Server 2008 and Server 2012 at:
 
Server 2003 is not mentioned at all in the article because ALL support for Server 2003 ends, promptly, at midnight on 14 July, 2015.  Server 2003 is, effectively, a dead server operating system and any installations of Server 2003 should be immediately upgraded to either Server 2008 or Server 2012.
 
Server 2008 is currently scheduled for depreciation on 12 Janyary, 2020.
 
 
I have written a series of articles pertaining to the required registry hacks which are available via my portal at:
 
While those articles contain all of the require information, for both the SECURITY PROTOCOLS and SECURITY CIPHERS, what they are, and how to enable them, either via a hack or the import of a .REG merge file, the process can be extremely confusing to even the most accomplished server operator.
 
Therefore, I have developed a downloadable zip file which contains two .REG merge files, which can be used for Server 2003, Server 2008, or Server 2012, and will completely patch the Windows server registry to:
  • DISABLE all SSL protocols: SSL 1.0, SSL 2.0, and SSL 3.0
     
  • ENABLE all TLS protocols:  TLS 1.0, TLS 1.1, and TLS 1.2, and
     
  • ENABLE and/or DISABLE CIPHERS which are required to:
     
    • MAXIMIZE the encrypting of the secured data;
       
    • REMOVE all of the ciphers which are no longer allowed or supported
 
In order to make the process of updating the Windows registry, in all versions of Windows Server: 2003, 2008, and 2012, I have created a set of two registry merge files which can be downloaded via a zipped file called "CIPHER.ZIP."
 
 
These files need to be downloaded to the SERVER which requires the updates.
 
Once you download the file, extract the two files from the ZIP:
 
Extraction of two files from CIPHER.ZIP using jZIP
Extraction of two files from CIPHER.ZIP using jZIP
Upon the successful extraction of the files from CIPHER.ZIP, you will have the following two files:
  • LOCAL_CURRENTCONTROLSET_CONTROL_SECURITYPROVIDERS_FINAL.reg and
     
  • LOCAL_MACHINE_POLICIES_MS_CONFIG_SSL_000100022_Final.reg
 
The next thing you want to do is open REGEDIT and BACK UP YOUR REGISTRY. 
 
While I have not had any problems with the merging of these two files, you ALWAYS want to make a backup of your system registry before making any changes.
 
To backup your registry, go to START, RUN, type REGEDIT, and press ENTER.  The followng screen will appear:
 
System Registry Editor Windos
Windows System Registry Editor Window - Example
 
To backup your registry settings:
 
make certain the TOP ITEM, in this case, "COMPUTER" is highlighted:
 
  • go to FILE
     
  • EXPORT
     
  • click on EXPORT
     
  • choose a location to save your registry settings
     
  • click SAVE
 
Exporting (backing up)  the Windows System Registry
Exporting (backing up)  the Windows System Registry Settings
After backing up your registry, close your registry editor by clicking on FILE ===> EXIT
 

PROCEED FURTHER ONLY IF YOU HAVE BACKED UP YOUR REGISTRY!

 
Now, let's go back to the two files you aquired via the download via CIPHER.ZIP:
  • LOCAL_CURRENTCONTROLSET_CONTROL_SECURITYPROVIDERS_FINAL.reg and
     
  • LOCAL_MACHINE_POLICIES_MS_CONFIG_SSL_000100022_Final.reg
 
Locate the extracted file: LOCAL_CURRENTCONTROLSET_CONTROL_SECURITYPROVIDERS_FINAL.reg and RIGHT CLICK on the file name:
 
A pop-up window will open. 
 
Right Click and select MERGE
Right Click and select MERGE
 
Select MERGE and a WARNING box will open:
 
Registry Editor MERGE WARNING window - select YES
Registry Editor MERGE WARNING window - select YES
respond YES when asked if you want to continue.
 
Upon the successful merge of the new CIPHERS and CIPHER ORDER, you will probably receive a warning message that some of the registry entries were in use and the entries may not have been imported. 
 
That is a normal warning.  You will have to REBOOT your server to complete the merge.
 
REBOOT your server before proceeding. After your reboot has completed, we will import the second file.
 
Now it's time to import the new SSL/TLS security settings:
 
Locate the extracted file: LOCAL_MACHINE_POLICIES_MS_CONFIG_SSL_000100022_Final.reg
 
RIGHT CLICK on the file name:
 
A pop-up window will open. 
 
Right Click and select MERGE
Right Click and select MERGE
 
Select MERGE and a WARNING box will open:
 
Registry Editor MERGE WARNING window - select YES
Registry Editor MERGE WARNING window - select YES
respond YES when asked if you want to continue.
 
Upon the successful merge of the new CIPHERS and CIPHER ORDER, you will probably receive a warning message that some of the registry entries were in use and the entries may not have been imported. 
 
That is a normal warning.  You will have to REBOOT your server to complete the merge.
 
Now, reboot your server a second time, and it will be time to test your new SSL/TLS settings.
 
 
Your sever(s) has(have) now been patched so they will no longer support SSL and, depending on the server operating sytem you are running, will support TLS 1.0, 1.1, and 1.2.
 
You can test your server's new capabilities, and security level, by entering the FQDN or the service at the SSL LABS testing site: https://www.ssllabs.com/ssltest/index.html
 
If you have successfully applied the patches which are included in the download CIPHER.ZIP the results shown below are what you can expect to see for:

 

WINDOWS SERVER 2003 - testing www.chicagonettech.com

Windows Server 2003 SSL/TLS Tests after Applicaiton of .REG Patches from file:
Windows Server 2003 SSL/TLS Tests after Applicaiton of .REG Patches from file: CIPHER.ZIP
To view the complete Quality SSL Labs encryption security report for Server 2003, click on the graphic above.
 
 

WINDOWS SERVER 2008 - testing portal.chicagonettech.com:

Windows Server 2008 SSL/TLS Tests after Applicaiton of .REG Patches from file: CIPHER.ZIP
Windows Server 2008 SSL/TLS Tests after Applicaiton of .REG Patches from file: CIPHER.ZIP
 
To view the complete Quality SSL Labs encryption security report for Server 2008, click on the graphic above.
 

WINDOWS SERVER 2012 - testing securemail.chicagonettech.com:

 
Windows Server 2012 SSL/TLS Tests after Applicaiton of .REG Patches from file: CIPHER.ZIP
Windows Server 2012 SSL/TLS Tests after Applicaiton of .REG Patches from file: CIPHER.ZIP
 
To view the complete Quality SSL Labs encryption security report for Server 2012, click on the graphic above.
 

SUMMARY:

  • The inclusing of TLS is fully dependant on whether or not your server's registry has been configured to allow TLS, and at what level of encryption.
     
  • The ability to use TLS is dependant on using IIS and is NOT supported when running the SmarterTrack, SmarterMail or SmarterStats web servers.
     
  • When access to a secured site is made via a browser, the ability of the browser to use SSL/TLS is dependant on whether the browser has been configured to use TLS 1.0, TLS 1.1, and TLS 1.2 - which are not necessarily enabled by default in most browsers.
     
  • Android devices running versions of the Androis operating system lower than Android 4.4 are not capable of supporting TLS.
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
malfunction Replied
April 26, 2015 at 2:01 PM
Thanks, if I need a lecture on cryptography I'll let you know, no need to trouble yourself cluttering the thread with hundreds of lines of irrelevant blather.  The fact remains that SmarterMail appears to only support TLS v1.0;  PCI 3.1 mandates the use of more modern protocols as of now, this is a serious problem for us.  Hoping SmarterTools are awake and have a solution close for this.
2
Bruce Barnes Replied
April 26, 2015 at 6:41 PM
First, the "lecture" was not for your benefit, but for the benefit of others who are also asking similar questions who might not be as familiar with PCI 3.1 requirements.
 
Second, I am very familiar with PCI 3.1 requirments.
 
Third, you can easily make your server PCI 3.1 complient by disabling TLS 1.0 - in your registry, or with the IIS Crypto program suggested by Joe, but this is not a SmarterMail issue.
 
So long as your server is complient, SmarterMail, and every other item running under IIS will be complient.
 
Fourth:  PCI 3.1 complience, from a server standpoint, is not mandated untili June, 2016 - so everyone who needs to become complient has more than a year.
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
malfunction Replied
April 27, 2015 at 1:14 PM
First, this thread is about support in SmarterMail for TLS v1.1/1.2.  Filling it up with irrelevant content is neither constructive or appreciated.  
 
Second, while that's good to hear I don't think you have actually tried disabling TLS v1.0 on a real server.  If you had you wouldn't be coming out with all this nonsense.  See #3.
 
Third, disabling TLS v1.0 will immediately cause SmarterMail to stop working.  That is very much a SmarterMail issue, whether you think so or not and while it might well be PCI compliant at that point a server with broken mail services isn't much good for anything.
 
Fourth:  as I stated, having TLS v1.0 enabled is a scan fail item right now.  You have it enabled you will fail the compliance scan at this time.  As I also stated there is a mechanism over the next year to appeal, by submitting a detailed formal risk mitigation and migration plan, but the support workload involved in doing that hundreds of times is something we really don't need.  
4
Robert Emmett Replied
April 27, 2015 at 1:30 PM
Employee Post
SmarterMail 13.x and previous are built on .NET Framework 4.0 (or earlier).  .NET Framework 4.0 only supported TLS 1.0.  This is a limitation placed on SmarterMail by Microsoft.  SmarterMail 13.x and early will not have the capability of supporting (via software) TLS 1.1 or 1.2.
 
Starting with .NET Framework 4.5 (which SmarterMail 14.x and later uses) does support TLS 1.1 and 1.2.  This is the framework that SmarterMail 14.x is built on.
 
References:
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
malfunction Replied
April 27, 2015 at 3:00 PM
Yep, thanks Robert, that's pretty much the answer I just got from Emily over live chat (tried that as I wasn't making much headway here).  I've already had a SM 14 beta license key sent over and we'll be trialling this as soon as possible.  Might want to add it to the docs as this is going to come up more.
0
Colin M Replied
April 27, 2015 at 8:02 PM
Regardless of TLS v1.0, 1.1 or 1.2, the much bigger issue is that if TLS is enabled then *unencrypted* is also implicitly enabled! So until this is fixed, no version of SM, including 14 BETA can possibly be PCI-DSS 3.0 or 3.1 compliant! See my thread: http://portal.smartertools.com/Main/frmThread.aspx?threadid=1636
 
Specifically, a PCI vulnerability scan would correctly report that an unencrypted connection accepts authentication credentials which is a huge no-no.
 
SM folks, please just look at how every other email server implements this and follow their example ASAP.
0
Bruce Barnes Replied
May 4, 2015 at 8:12 AM
Responding to Robert's post:
 
Robert Emmett Replied
April 27 at 3:30 PM
 
Employee Post
SmarterMail 13.x and previous are built on .NET Framework 4.0 (or earlier).  .NET Framework 4.0 only supported TLS 1.0.  This is a limitation placed on SmarterMail by Microsoft.  SmarterMail 13.x and early will not have the capability of supporting (via software) TLS 1.1 or 1.2.
 
Starting with .NET Framework 4.5 (which SmarterMail 14.x and later uses) does support TLS 1.1 and 1.2.  This is the framework that SmarterMail 14.x is built on.
 
References:
 
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278 FREE
www.smartertools.com
Here's a screenshot, taken via LANDROID, which shows that SmarterMail 14.0.5590 BETA, running under .NET 4.5, on Server 2012, does support TLS 1.2
 
This was captured using LANDROID, on a Samsung 5, on the Sprint network, testing to securemail.chicagonettech.com
 
SmarterMail 14.0.5590 BETA, running under .NET 4.5, running on Server 2012, supports TLS 1.2
SmarterMail 14.0.5590 BETA, running under .NET 4.5, running on Server 2012, supports TLS 1.2
This clearly establishes the fact that TLS 1.2 is supported by SmarterMail 14.X and .NET 4.5 under Server 2012
 
Additionally, you can also prohibit the use of clear text passwords in SmarterMail by checking "DISABLE AUTH LOGIN method for SMTP authentication" under SETTINGS ==> PROTOCOL SETTINGS ===> SMTP IN, IE:
 
DISABLE AUTH LOGIN method for SMTP authentication" under SETTINGS ==> PROTOCOL SETTINGS ===> SMTP IN
"DISABLE AUTH LOGIN method for SMTP authentication"
under SETTINGS ==> PROTOCOL SETTINGS ===> SMTP IN
This will help to satisfy the HITECH portion of the HIPAA requirements.
 
The enforcement of TLS only communications between MX servers is another issue.  If this capability was to be added to SmarterMail, and an operator chose to enforce TLS to TLS ONLY for MX to MX, it would severely limit the number of MX servers which would be capable of communicating with a TLS only SmarterMail server.
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

Reply to Thread