TLSv1 has been deprecated for some time now and is disabled in Sympl for web traffic, but it’s come time to disable it in for Mail (incoming and outgoing) and FTP traffic.
The next update to Sympl (currently on the testing branch) disables TLSv1, forcing clients to use TLSv1.1 or higher for mail connections, and FTP connections on Buster.
This is also a step on the course to making Sympl PCI Compliant by default, or at the very least, making it as easy as possible.
Unfortunately, FTP on Stretch uses the default (older) version of Pure-FTPd, which is limited to only using TLSv1, so users looking for PCI Compliance there should disable/firewall/remove the FTP service.
Longer-term, I plan to replace the basic FTP setup for Sympl with a jailed SFTP configuration, which provides the same functionality in more situations, including using IPv6-only reverse proxys.
“Currently on the testing branch” but here, apt update; apt upgrade is now offering me upgrades on sympl-core and sympl-web. My apt sources line for sympl is:
deb Index of /mythic buster main
Is that the testing branch (not obvious to me) or are these upgrades for sympl-core and sympl-web more in the nature of security fixes, and unrelated to the changes you are describing?
Its’s not very clear, but that’s the normal/stable branch.
If you change buster
there to buster-testing
, you can then run sympl update
, and it’ll update to the testing release.
Sorry , perhaps I wasn’t clear enough. I don’t want the testing release, but I did get some updates anyway. Is that as it should be?
Ah, sorry - yes, that’s normal - fixes and tweaks filter down from the testing to stable version every of often, and you can check what changed via the changelog in GitLab: CHANGELOG · buster · sympl.io / Sympl · GitLab
Thanks. That link answers what would have been my next question, and is bookmarked now.
This has now been pushed out to the stable branch, and should auto update.
There’s an outside chance that z very small number of users may experience problems with mail connections with incredibly old mail clients which don’t support TLSv1.1 or better, in which case they should either upgrade their client, or use the webmail interface.
Yes, I have someone using MS Outlook 2010 and Windows 7 and it took an afternoon of investigation (mostly distracted by misleading error messages from Outlook) to conclude that it was trying to use TLSv1.0 and dovecot wasn’t having it. I have yet to discover whether downgrading dovecot back to TLSv1.0 will make it work again, but they are aware that they are now using an unsupported OS and really need to do something about that.
It’s possible to downgrade the Dovecot config to allow TLSv1.0, but it’s dangerously insecure nowadays which is why you haven’t been able to pass PCI compliance with it enabled for some time now.
I don’t intend to leave it like that, it was an experiment to confirm the cause of the problem, but I think that’s that’s well established now!