As most of you will surely have already seen, just yesterday we’ve released Syncplify Server! v8.4.0, featuring automatic self-updates, which in and of itself earned it a very special release note.
But v8.4.0 carries a lot more than that. It carries a robust set of security improvements which would not have been possible without the help of one of our customers, but since we’re a security company we’re not going to name them here. We’ll just say this: You know who you are, and we cannot thank You enough!
They provided us, free of charge, with the best security assessment and pen-testing our software has ever been put through. Ever.
And that act of kindness and genuine support lead v8.4.0 to also include the following changes and improvements:
More sensible default configurations for newly deployed instances (do not apply to updates/upgrades for obvious reasons) including but not limited to:
STARTTLS auth now defaults to “Required” on FTP bindings
Pinned-key mTLS is now on by default for all R2FS! bindings
SyngoDB management service now binds to 127.0.0.1
More sensible SANs in default self-signed certificates
More sensible HTTP security headers by default
Worker process auto-restart is now enabled by default
Tightened ACL on database and log files
Tightened systemd unit file configuration for all services (Linux only)
Fixed “Timing Oracle” exposure that allowed an attacker to tell apart existing from non-existing usernames by simply measuring the server’s response time
Legacy
ssh-rsaweak host key algorithm was an automatic “re-entrant” if the SSH/SFTP service has any RSA host key in its configuration (now disabled really means disabled instead)Hardened build pipeline now prevents builds from a “dirty” repo (a repo that has uncommitted changes, and forces PIE executable builds on Linux
The report we received also included a couple of false positives, which we verified (not assumed) to be false positives, and as such were not addressed.
It’s important to understand that all the security improvements to the executables and environment are automatic for everyone, new install and updates/upgrades alike. But all the improvements to the default configurations are only applied to new installs, so if you’re updating/upgrading to v8.4.0 from an older version you’ll still have to review your own configuration to ensure it’s the tightest possible (compatibly with your specific needs).
We hope this addendum to the previous v8.4.0 release note effectively conveys why we consider v8.4.0 such an important update for everyone running our software.
As usual, thank you all for your attention, and for being part of our journey.