Syncplify.me Server! v4.0.29 released

We have just released version 4.0.29 of our Syncplify.me Server! software. This version features the following improvements:

  • Fixed: bug in the DiskAES256 virtual file system (VFS) that caused WinSCP to raise an “Error 4: file-write error”, but only on very large files (larger than 2GB or 4GB depending on the OS)

Note: if after the update you notice any unexpected behavior in the web interface, just hit Ctrl-F5 in your browser; that will force the browser to reload the page as well as all back-end scripts and update the ones that may have been cached from previous versions of the software.

As usual you can download this new release from our website.

Syncplify.me Server! v4.0.28 released

We have just released version 4.0.28 of our Syncplify.me Server! software. This version features the following improvements:

  • Fixed: bug in the DiskAES256 virtual file system (VFS) that caused WinSCP to raise an “Error 4: file-write error”

Note: if after the update you notice any unexpected behavior in the web interface, just hit Ctrl-F5 in your browser; that will force the browser to reload the page as well as all back-end scripts and update the ones that may have been cached from previous versions of the software.

As usual you can download this new release from our website.

HTTPS “connection not private/secure” – what it is?

Syncplify.me Server! version: 4.0.0+

After installing Syncplify.me Server! v4.0 you will be able to manage it securely via web interface over HTTPS.

Now, a very common choice is to use a self-signed certificate, because it saves money and if you know what you’re doing it doesn’t compromise security. This is, in fact, the most common choice among our users (according to our surveys).

But if you use a self-signed certificate, your browser will warn you that your connection may not be private or secure. That’s because self-signed certificates are often used for man-in-the-middle (MitM) attacks. But this is not the case, of course, if you can verify that this particular self-signed certificate was created by you and for you.

To get rid of this annoying message, you basically have 2 options:

  1. Spend some money to buy a trusted X.509 (SSL/TLS) certificate from a Certification Authority like DigiCert, Comodo, Thawte, and the like. It goes without saying that this is the recommended choice, as it takes advantage of the inherent trust chain provided by the Certification Authority.
  2. Verify and accept the self-signed certificate you have just created and add it to the trusted keychain of your browser. In this case you are advised to always verify the certificate’s fingerprint to make sure it’s really the one you created yourself, and that you’re not a victim of a Man-in-the-Middle (MitM) attack.

Continue reading

Maintenance release: Syncplify.me Server! v3.1.23.63

We have just released version 3.1.23.63 of our Syncplify.me Server!

This new maintenance release addresses a “foggy” area in the FTP protocol standard: the MLSD command will now accept wildcards (ex: *.txt) in the request path, and return an error only when a fully qualified file name is provided. This added flexibility mimics the behavior of several other FTP servers on the market, and ultimately improves compatibility with many existing and legacy FTP clients.

As usual you can download the latest version from our web site. Thank you!

Firewalls and FTP external IP address for PASV

Yesterday we came across what, at first, seemed to be a pretty odd case, and we think it’s worth sharing it with our users.

Most firewalls (we’d say all the ones we know) have NAT/PAT capabilities, and many are able to perform protocol-level inspection when the connection is not encrypted. SSH (and SFTP) are always encrypted, but FTP can be either encrypted or not; yet, theoretically protocol inspection should only prevent protocol-related attacks, not modify client requests or server responses.

Yet, yesterday a customer with a perfectly configured instance of Syncplify.me Server! was experiencing a weird behavior: FTPS/FTPES (encrypted) sessions were working perfectly, while plain FTP sessions were dropped upon every attempt to open a data connection to transfer files. Continue reading

Linux sftp client error 6: invalid packet (solution)

Some users of Syncplify.me Server! have reported that when trying to connect to Syncplify.me Server! using the command-line sftp client from certain (but not all) Linux versions they are suddenly disconnected with the error message shown in the picture here below:

linuxbefore

The error code 6 (invalid packet) signifies that the Linux sftp client was not able to negotiate a secure session with the server due to the (client) inability to verify the contents of the KEX packet coming from the server.

Continue reading