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);
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

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.