• A bug in our logging library, specifically affecting the syslog target, has been identified and fixed; now a stuck syslog server can no longer cause resource channel lock-up in your Syncplify software.

As always, you can download the most recent release from our website, or if you’re running Server! v8.4.0+ or R2FS! v3.0.0+ you may (more easily) self-install this update with the push of a single button in the web UI.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• If you’re running any version of Syncplify Server! between v8.1.2 and v8.4.0 your service might CRASH (and auto-restart) when the following two events happen to occur symultaneously:

  • a log file is rotated

  • a client disconnects at the exact same time

  Version 8.5.0 fixed that specific race condition. We apologize to anyone affected by this bug, and we urge everyone to update to v8.5.0 so that this doesn’t happen anymore.

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

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-rsa weak host key algorithm was an automatic “re-entrant” if the SSH/SFTP service had 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.

What’s changed?

Learning from the lessons we learned developing SFTP.cloud, we added what’s likely the most requested feature ever, automatic self-service updates, to both Syncplify Server! and R2FS!

The SuperAdmin UI gained a new page, called Updates:

And you can now elect to be notified only or create your own auto-update policy:

Updates are graceful: the node being updated is put into “drain mode”, patiently awaits until there are no more ongoing client connections, then self-updates and restarts, all automatically.

Updates are also safe in HA cluster deployments: when running as part of an HA cluster, nodes take turns and update themselves one by one, verifying the success of the update and the node’s health before moving on to the next node.

NOTE: you will still have to download and install this one update manually, then once you’re running Syncplify Server! v8.4.0+ or R2FS! v3.0.0+ all subsequent updates can be automated.

Also, please, be aware that the automatic self-update feature does check the validity of your maintenance plan. Only active and current maintenance plan holders are eligible to receive updates and upgrades. Thank you for keeping your maintenance plan active and current.

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

1. It’s literally the platform’s domain name, so the dot is pronounced by default.

2. Just like Microsoft’s .NET platform (pronounced “dot net”) the dot in SFTP.cloud is also an integral part of its name.

3. We don’t want to be confused with “sftpcloud” which is a different service that has nothing to do with Syncplify or SFTP.cloud.

And here’s the official wordmark, to leave no ambiguity as to how it’s written:

As always, thank you all!

Now, after nearly 13 years of honorable service, we’re retiring Protector in favor of a completely new design. The change is so radical that we felt it appropriate to use a different name for it. We now call it Shield.

But… why?

Shield was developed as part of the SFTP.cloud project, and within 2 hours of its release it had already proven itself on-field, against a distributed botnet attack.

Of course we were pleased with the result, but that got us thinking: how would have Protector fared against the same attack? Luckily we had a few dozen megabytes of very detailed logs that allowed us to re-simulate the entire attack shape and run it against both Protector and Shield to measure the results.

First and foremost, it is important to say that both Protector and Shield handled it with a 100% success rate. But then, why is Shield such a big deal? If both technolgies prevented 100% of these attacks, why is Shield so far superior?

It all comes down to four aspects:

1. Resource usage: while the attack was underway, Protector used up ~8% of the host machine’s CPU to prevent it, Shield did the same while using only ~0.1% (that’s 80 times fewer CPU cycles)

2. Long-term memory: Protector didn’t have any, so every attack was a new event from its perspective, which means that “slow and patient” attacks are dealt with but never prevented. Shield has memory. It remembers the behavior of each attacker for a certain (configurable) amount of time, and is capable of preventing re-attacks from known sources far more effectively using such knowledge.

3. Shield is fully deterministic: Protector was partly deterministic and partly probabilistic, leading it to raise the occasional false positive here and there. Shield is fully deterministic, leading to far fewer (in the vast majority of cases absolutely zero) false positives.

4. Flexibility: Shield can be fine-tuned much more granularly than Protector, which increases its flexibility by a huge margin.

So, what does it look like?

Well, first and foremost its UI is far more informative than the old Protector. Shield gives you a lot more information about each ban and what caused it.

It also provides a real-time view of its current status, including a list of IP addresses that are currently under review (have strikes) and why.

And, like we said, it’s highly configurable/tunable, but it comes with built-in sensible defaults, so most operators won’t ever have to “mess” with it.

How can you get it?

Simply update or upgrade to Syncplify Server! v8.3.0 (or newer) and Shield is built-in, your old Protector is gone, and your old banned IP list and safe-list are automatically converted to the new format.

What’s changed?

• Dropped the old Protector, and adopted the far superior Shield, developed over the past 18 months as part of the SFTP.cloud project, which in just hours after launching the new platform has already proven itself ~80 times more efficient (and more accurate)
  > a dedicated blog post, with a full explanation, will follow <

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What happened exactly?

At 16:48Z, 56 distinct addresses arrive inside one minute. By 17:01Z the rate peaks at 211 attempts a minute. Note the shape of it: through the whole opening phase the count of attempts and the count of distinct source addresses are nearly identical, one attempt per host per minute. This is clearly a botnet deliberately spreading its guesses thin so that no single address trips a per source counter quickly.

It goes on for thirteen minutes. Then arithmetic catches up: the adaptive strike window at that point in time is narrower than 20 minutes, so around 17:02Z hosts begin crossing five accumulated failures and the bans start. The ban rate peaks at 61 in the minute of 17:09Z. From there the two curves cross. Traffic stops reaching the authenticator and starts bouncing off the accept gate instead.

The crossover at 17:13Z is the shield taking hold. Everything to the right of it is the attack still arriving and being dropped at TCP accept, before a key-exchange event even has the chance to occur.

What were they shopping for?

268 distinct usernames were tried. The head of the distribution is the expected system account sweep (we guessed usernames like root and admin, and log analysis proved us right): together they represent roughly 32% of all attempts.

The interesting part is the second cluster. wallet, crypto, solana, blockchain, exchange, metaverse, plus xmr, monero, eth and binance further down. That is 951 attempts, or about 19% of the total, hunting for crypto custody hosts rather than generic shells.

A third cluster names hosting control panels: whmc, ubersmith, cerberus, panel. And the long tail is a first name dictionary, five attempts each, which is what the single most persistent host in the log was patiently grinding through.

SFTP.cloud’s automatic shield held end-to-end

Nothing authenticated. Across 4,925 attempts from 937 addresses there is not a single successful attacker login on any protocol. The only successful sessions in the entire window are seven WebClient logins by a legitimate user account from a single address.

The cost model held. The accept gate refuses a banned source before the SSH key exchange, so 6,321 of the connections in our logs cost essentially nothing. That’s why the protocol-head process never moved above 0.1% CPU usage while 200 hosts a minute hammered it.

Persistence held. Bans survived in the database and the RAM index rebuilt cleanly. 120 bans expired and were lifted on schedule during the window, with no drift.

A good day’s work

Throughout the entire attack, our SOC staff sat there, watching it all unfold, keeping an eye on resource usage, making sure legitimate users were still signing-in without hiccups.

All they had to do was watch. SFTP.cloud protected itself, silently and efficiently, exactly as it was designed to do.

And the very first question we received? “Show me its WebClient”. Alright, that’s fair.

So here it is. Showing you both views of the same directory, to show off the optional thumbnails (in gallery view, cached on the browser to avoid wasting bandwidth) .

Now, the most observant among you will surely be drawn more to the bottom-right side of those screenshots, rather than the file-views.

What is the Transfers panel telling us? It’s actually telling us a very interesting story:

• New file uploaded from the browser need the browser to stay open to come to completion (just like Google Drive, OneDrive, and basically every other tool of this kind when accessed via web interface)

• But file copies/moves between existing locations are carried out on the server: they can be cross-VFS and even cross-Connector, and they survive if the browser tab/window is closed after initiating them

Moving on, of course no product of this kind would be complete without the (optional) ability to create “shares”, to share individual files or entire folders with external third parties in a controlled manner. So here we go:

The process is guided, and the security and convenience features cover many aspects, like, for example:

• Granular access controls

• Password-protected access (well, duh!)

• Maximum number of times the “share” can be accessed before it self-expires

• IP-based allow-list (individual IP addresses and network CIDRs supported)

• Anonymous sharer identity

• Automatic email notification to a list of recipients

And here’s how one such recipient sees the object shared with them:

And the beauty behind all this? The physical storage behind all that was never held by SFTP.cloud in the first place!

• Connect your own storage: SFTP.cloud will never hold a copy of your files

• Encrypt it with your own keys: SFTP.cloud will never have them

• Safely and securely share whatever you want with whomever you want: SFTP.cloud is just your quantum-secure protocol-head in the cloud

More to come, soon.

And here’s the interesting part: neither of them gets away scot free.

In fact, those who can plan for update windows get annoyed with “rolling release” vendors, because they add too many items to their already busy docket.

And the second type… well… they’re the reason why we still find customers on V4 when the current release is V8. It works just fine, and they can’t afford the downtime to upgrade. To be fair this type often splits into two sub-types: those who do not update, and those who deploy HA clusters behind load-balancers to be able to upgrade their nodes one by one without interrupting the service as a whole.

Up until now we’ve never felt this could be, at least in part, our responsibility. But, oh boy, were we wrong! Having spent the past year and a half developing all the SFTP.cloud components threw us head-first directly into those operators’ shoes. We quickly realized we had to come up with a better approach.

So, how do SFTP.cloud components update with zero downtime?

As it often happens there are two sides to this story:

• The Protocol Heads, the machines serving SFTP, FTP(E/S) and HTTPS, accepting incoming client connections, are the ones we operate. On top of load-balancing and clustering, each one of these nodes is also designed to hand over the listening socket to the incoming (upgraded) process, so connections survive the changeover without ever being rejected by a closed port.

• The Storage Connector, sitting in your data center, does something different. The new version starts up alongside the old one, dials the Head over its own reverse tunnel, and gradually takes over new work. The old binary keeps the transfers it already had, carries every one of them through to completion, and exits only once it has gone idle. At no point in the chain is there a gap where a transfer is dropped or interrupted.

The Head side updates/upgrades are orchestrated by an automation process that staggers the updates and delivers them in tiers, verifying each tier before moving on to the next. Any error during the process is an automatic zero-downtime rollback.

The Storage Connector side is capable of fully automatic self-updates, but it can be configured to wait until an operator decides to do the rollout. And still there’s nothing to keep an eye on, download, type in the command line… it’s just one button in the Connector’s Admin UI. One click. A few seconds of wait time. Walk away with a smile on your face.

Syncplify Server! and R2FS! come next

We decided to take it one step further. Now that we’ve developed the technology, we believe the same approach would also benefit our Syncplify Server! and R2FS! customers. After all, they are the ones who operate our self-hosted software, so it seems fitting to offer them the same convenience.

We have, therefore, begun a two-pronged effort to integrate the same zero-downtime update/upgrade features into those pieces of software as well.

Because it’s all about security

We don’t release updates for the fun of it, or to annoy our customers with yet another upgrade task to plan around. We release them because the threat landscape keeps shifting. And now, with the advent of AI, that shift is faster than ever before.

If you’re still running an old V4 or V5, you’re simply not safe. It works, yes, it works really well. But it’s vulnerable to attacks that didn’t even exist when that version was released. Keeping your software up to date is the one shield that protects you more than anything else.

Now, with SFTP.cloud that’s also easier than ever. And soon it will be, too, for Syncplify Server! and R2FS!

What’s changed?

• Fixed a cosmetic bug in the Admin UI that “forgot” that all usernames must be lowercased to ensure POSIX compliance effectively

• Upgraded SyngoDB to v6.12.0, which fixes a bug with the finder’s planner when the AND clause is used in conjunction with two distinct compound indices

• Upgraded the Go compiler to 1.27 (which comes with its own set of bug-fixes in the language’s standard library)

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Fair question. And if we have to answer it with the same fairness, it means separating two things the industry insists on (confusingly) calling by the same name.

A CONNECT tunnel (or its SOCKS5 equivalent) relays TCP bytes it cannot read. Your TLS handshake happens with the real server, end-to-end. All this “proxy” learns is a destination, a port, and some byte counts.

An intercepting proxy, sold to you as SSL/TLS inspection (aka “break and inspect”, ring any bells?) terminates your session, decrypts it, and opens a second one onward using a certificate your endpoints were configured (read: forced) to trust. That is a man-in-the-middle device with a support contract, and one compromise exposes every session that goes through it.

The distinction is not academic for us. The Syncplify Server!-R2FS! pair, and all components of SFTP.cloud SaaS guarantee hybrid post-quantum cipher-suites between all of their control plane components, and that guarantee can only be true when it can be established and verified end-to-end.

What these SSL/TLS intercepting proxies leave you with is a PQC connection to the middle-man, and an Agatha Christie-sized mystery beyond it.

We use mutual TLS (aka mTLS) with pinned certificates, which cannot survive interception by design, so the handshake fails at connect time. There is no silent downgrade path, and we will not ship a “skip verification” flag, because there is no moment when using one would be safe.

So, the only fair answer is: proxy traversal via CONNECT and SOCKS5 is on our roadmap, we’ll do it. Support for TLS-intercepting proxies is and always will be explicitly unsupported.

Proxying was never the problem. Interception is. Yes, even the type that a trillion dollars worth of marketing convinced you that “it’s for your own safety”: that’s how two out of three of the US’ major Telcos were hacked just last year. Not on our watch.

And we published a 9-minute video that shows the platform in action, end to end, for the first time.

The video covers some of the most common quick-start topics, like:

• How to sign up

• How to create your first site

• How to create your first transfer-user

• How to connect your own storage (Linux and Windows)

• How to transfer some files (via its WebClient UI)

Nothing fancy. Just the basics. But it can point you the right direction, because the way our platform works is unlike any other cloud-based SFTP/MFT you may be familiar with.

With SFTP.cloud, in fact:

• Your files never touch our servers. Not cached nor staged anywhere on our side.

• We never hold your storage credentials. There is nothing in our infrastructure that could be stolen and used against your data.

• Nothing new opens in your firewall. Your Storage Connector dials out to us. Nothing dials in.

• Post-quantum cipher suites on SFTP, FTPS, FTPES and HTTPS. Yes, all four of them from day one.

• Two signed audit trails per session, one written on your side with a key we never have. Neither of us can quietly rewrite what happened.

• Cross-VFS and even Cross-Connector managed transfers. Move files from your New York office to your Tokio subsidiary on a scheduled job, or a simple drag and drop.

• At-rest encryption with your own keys. Keys you never have to give us, not even temporarily.

And all that needs to be shown, not just talked about. Now we have.

And for those of you who may be interested in this service, there’s still a little bit of time to sign up for the second wave of early adopters (who, just like the first wave, will also receive a discount when the platform launches officially, after its early-access period runs out).

Thank you all!

This allows for cross-VFS and even cross-Connector MFT. Copy and move your files freely, they will land on your actual storage in your own facilities (Disk, NAS, SAN, SMB/CIFS, NFS, DFS, whatever you have connected from that office to SFTP.cloud).

These cross-VFS/cross-Connector transfers are fully managed, you can start them and logout, leave, come back the next day, and your files will be safe in their intended destination.

And all transfers are verified twice: in flight (using per-buffer rolling hash) and then again after they land (using a full-file hash).

And the icing on the cake: you don’t need to initiate these transfers via the web-based file manager. SFTP.cloud has built-in support for SyncJS scripting, event handling, and scheduling, so you can automate them however you like.

If you are among the 100 early-adopters who signed up via the SFTP.cloud placeholder website, first of all THANK YOU.

You will receive instructions on how to enroll (and how to redeem your well-deserved credit) within the next 10 days. Yes, we’re not doing this with a mailing-list, we’ll actually be emailing each and every one of you personally. Manually.

Of course we were hoping for SFTP.cloud to arouse some interest, but the initial reception has gone beyond our expectations, and for that we’re immensely grateful.

More to come. Soon. 😉

What’s changed?

• The “automatic linking” upon first login used to be limited to the principal’s subject as defined in the remote directory, this new release adds the ability to specify a custom claim to be used for auto-linking (upon first successful login); read more here: https://docs.syncplify.com/v8/docs/general/sso.html

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Improved named-pipe compatibility with impersonated worker system services when running on the Windows operating system (Linux never had that problem in the first place); Also added an “escape hatch” via system-wide environment variable (documented in the manual) in case everything else fails, to switch from named-pipes back to the old TCP-loopback method.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

But words are just words… until someone tests them. So we had it tested.

Yep, that’s our very first site running on SFTP.cloud (rather obviously, it’s our own).

But we can already hear you all: “security goes much deeper than just a good TLS implementation”. True. Very true. And that’s why we hired a penetration testing company to red-team and blue-team the heck out of our solution, so that once it finally gets into your hands it will be green-lighted by the best independent security testers out there.

Would you like 2 FREE MONTHS of service when it launches? There are still a few spots left. Head over to SFTP.cloud and reserve yours.

What’s changed?

• Added the ability to backup/restore the configuration, and/or migrate the entire R2FS! node to a new machine/VM

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

The core itself (the Portal, Customer UI, Protocol Heads, Storage Connectors, …) is ready, and in the past couple of weeks we focused on monitoring and observability. And, in typical Syncplify fashion, we didn’t do it just for us, we did it for you as well.

First and foremost, our intercontinental distributed monitoring system: 5 probes in 5 different data-centers, operated by 4 different ISPs, in 3 different continents.

The service is degraded, or “down”, when 3 or more probes agree it is. And the whole purpose of this complex distributed system is to give you this:

That’s the public-view of our service’s health. The transfer service is currently not measured because we haven’t released it to anyone yet. Once we do, it will be.

In addition to that, each customer has a per-protocol view of their individual sites’ health inside of their own Customer Portal. Something that looks like this:

And this is not all we did recently to ensure service observability and uptime. Read on, it only gets more interesting.

Two tamper-evident, digitally signed, verifiable logs

All file access and transfer events in SFTP.cloud are logged on two sides:

• on the Head that serves the protocol (that we control)

• on the Storage Connector that’s in your hands (and we cannot reach)

In your Customer UI you can see the Head’s log integrity, and download a digitally signed evidence file:

In your Storage Connector UI, you can check the integrity of the logs acquired on your own infrastructure, outside of our control:

And to keep everyone honest, so that none of the parties has to “operate on trust”, we open-sourced the log verifier. Anyone can read the source code, verify it’s honest, download it, compile it, and run it against their own SFTP.cloud Storage Connector logs with one simple command line:

logverify verify -dir /opt/Syncplify/sc-conn/audit -identity /opt/Syncplify/sc-conn

The source code is on GitHub here: https://github.com/syncplify/logverify

All that… for what?

Reason #1: addressing the hidden logical fallacy

The one thing that often goes unsaid in the zero-trust SaaS world is that, in most cases, you still have at least one party you must trust: the vendor itself.

And… one is not zero.

We don’t want you to “just trust us”. We’re giving you the tools to verify our claims. And we’re open-sourcing the verifier, so you can audit its honesty and reliability yourself.

Reason #2: treating customers with fairness

There’s this little thing called Service Level Agreement (or SLA, for short). It says that if the service degrades below certain levels, you get some sort of compensation (typically in the form of credits).

The problem is that with most competitors the whole burden of proof is on you. You have to detect the failure, you have to develop the evidence, you have to report it, and you better do it within 60 days or your claim is invalid.

Enough with that! Who wants that anyway?

With SFTP.cloud we monitor the platform, detect degraded services and outages, attribute them to the correct side, digital sign the evidence, give you all the tools to verify our claims, and then we automatically give you the service credits you deserve.

Because we believe that when you buy a service, measuring its reliability and acting on those signals should be part of the service you pay for. It’s that simple.

So… how do you sign up for your 2 FREE MONTHS?

Just go to https://sftp.cloud, scroll to the bottom, and fill in the form.