Migration from SSL to TLS
Question asked by Martin Schaible - 5/8/2021 at 5:42 AM

After years ignoring TLS, it's now time to move from SSL to TLS.
I'm trying to find a easy way for the customers. Each customer needs to change at least one setting in the mail client.

The easiest way would be changing the bindings as needed. The previously informed people needs to change their mail software, that's it. I'm pretty sure, that i will receive a lot of support tickets ;-)

The other way would be this: I add a second IP address to the server. Then i create a new set of bindings with a new hostname and a new certificate is needed to.

This allows to migrate domain after domain by changing the MX record in the DNS and chnage two settings on the options per domain in SmarterMail. This needs more time, but i'm able to control the work load and time frames.

Does this looks good to you? Any better idea or thoughts?



6 Replies

Reply to Thread
Sébastien Riccio Replied
Changing bindings would be a bad idea IMHO. 
Mail clients are trying to autodiscover services on standard ports with the protocol they are commonly used for.
I think it would create more confusion for the mail clients than help them.

That being said, I don't understand your concern here. Why not leave both active ? (legacy implicit SSL on their ports and explicit with STARTTLS on "normal" ports) ?

It's then up to the clients to use either of them:

Kind regards.
Sébastien Riccio System & Network Admin https://swisscenter.com
Martin Schaible Replied

I don't have the plan to retire SSL.
Douglas Foster Replied
The specification sequence Is     SSL2.0 -> SSL3.0 -> TLS 1.0 > TLS 1.1 -> TLS 1.2 -> TLS 1.3
Systems negotiate to the highest protocol that is mutually supported.
Most systems have SSL 2.0 disabled as it was never widely implemented and it has significant security issues.
TLS 1.3 is the newest and I don't know of any version of Windows that has it implemented (but could be uninformed.)

SSL3.0, TLS1.0, and TLS1.1 are deprecated because of potential vulnerabilities that have been detected by white-hat researchers and might be exploited by very sophisticated attackers (such as nation-state actors.)  Part of the attack is to trick TLS 1.2-capable systems to fall back to the earlier and weaker protocols, so there is pressure (especailly from PCI DSS) to disable earlier protocols so that they will never be used, even as a fallback.    Any reasonable client should be able to support TLS 1.2, so this should not be an obstacle for your most desktop users.   (Windows XP supported it with an optional Windows Update kit.  Early versions of Windows 7 had it available but disabled b y default.   It was subsequently enabled by default by a Windows Update.)

TLS 1.0 and later support "STARTTLS", which allows the client to start in non-encrypted mode and switch to encrypted mode.   SSL 3.0 does not have that capability.

What I understand all of this to mean:
For client connections using SMTP, IMAP, and POP:
- If your SmarterMail port definition is SSL, your clients must connect with encryption.   You can adjust your server settings to control which protocols you will accept.
- If your SmarterMail port definition is TLS, your clients can use either unencrypted or encrypted sessions.  You can till adjust your server settings to control which protocols are accepted.

Awhile back, I switched from SSL to TLS in my port definitions, but based on the above, I am debating whetehr to switch back.

Things get more complicated if you do not have an incoming gateway, because now you have to worry about the encryption capabilities of remote systems.   My observation is that there are still remote systems which cannot do encryption or cannot do TLS1.2, even though their message traffic is acceptable.   Consequently, my incoming gateway still allows weak TLS 1.0 and TLS 1.1 protocols as well as unencrypted connections.   Currently arguing the point with my PCI DSS scan company.

If you do not have an incoming gateway, I encourage you to implement one.   This allows you security policies for unauthenticated inbound mail connections that is different from authenticated email client connections
Martin Schaible Replied
Actually a company i germany is accepting only mails based on TLS. All other mails will be rejected.
I think, this is way to restrictive.

The only thing i want, is to offer both ways to the customers.
Douglas Foster Replied
If your SmarterMail port is configured for TLS, you should be able to send and receive both encrypted and unencrypted traffic.   When the remore server includes STARTTLS in its response, the client system drops the initial unencrypted connection and connects with encryption enabled.   You should be able to see this behavior in your outbound Delivery log or inbound SMTP log.

Martin Schaible Replied
Douglas: Thanks, i know that and i'm not sure, if your comments helps me in a way. The comment of Sébastien helped to make the decision to setup TLS and leave the existing configuration as it is.

So the customers can choose between SSL and TLS.

Reply to Thread