Provide a choice of TLS 1.0 or TLS 1.2 in SM
Idea shared by Lakshan Salgado - 10/16/2014 at 10:51 AM
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)

28 Replies

Reply to Thread
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).
Here's what my server negotiates with Gmail: (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thanks, -Joe
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. 
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


  • 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 brucecnt@comcast.net Phonr: (773) 491-9019 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
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.


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: