Bitvise FlowSsh Version History  

Changes in FlowSsh 7.35:    [ 16 September 2017 ]

  • We have identified two compatibility issues in current and past versions of mod_sftp for ProFTPD:

    • When using SFTP versions 4-6, when a client requests attributes not supported by mod_sftp, the server returns an incorrectly encoded response. With past Bitvise SSH Client and FlowSsh versions, this would result in a disconnect.
    • When using SFTP version 6, mod_sftp indicates support for the check-file extensions, but disconnects if the client requests the server to hash a larger file block by block. This prevents Bitvise SSH Client and FlowSsh from performing hash-based synchronization of file content, which would normally be used instead of Resume or Overwrite if check-file extensions can be used.

    We expect these issues will be resolved in future mod_sftp versions. However, mod_sftp now comes configured by default to not send its version in the SSH version string. A client therefore cannot distinguish between a newer version that contains these fixes, and an older version which does not.

    At this time, Bitvise SSH Client and FlowSsh will avoid the known compatibility issues by restricting SFTP protocol version to 3 when mod_sftp is detected. We would like to lift this restriction in the future if there arises a way to detect the mod_sftp version early enough.

  • We have identifed a compatibility issue with Van Dyke VShell:

    • When using SFTP version 6, the VShell server indicates support for the check-file extensions, but does not support block-by-block hashing. This prevents Bitvise SSH Client and FlowSsh from performing hash-based synchronization of file content, which would normally be used instead of Resume or Overwrite if check-file extensions can be used.
    • At this time, hash-based synchronization will be avoided when connecting to VShell, and Resume and Overwrite will be used instead.
    • If VShell chooses to implement support for block-by-block hashing, Bitvise SSH Client and FlowSsh will once more use this functionality if the server advertises the extension name check-file-blocks in its supported2 packet.
  • Bitvise SSH Client and FlowSsh will now recognize the check-file extension indicator in the supported2 packet as required by the SFTP extensions draft, in addition to check-file-name and check-file-handle.

  • Bitvise SSH Client and FlowSsh will now recognize a check-file-blocks extension sent by servers. We suggest that future SFTP server implementations advertise support for check-file-blocks if all of the following are true:

    • The server supports block-by-block file hashing.
    • Any reasonable block size requested by the client is supported.
    • A file can be hashed block-by-block starting from an arbitrary offset.

Changes in FlowSsh 7.34:    [ 1 August 2017 ]

  • This version fixes a memory leak introduced in version 7.31.

Changes in FlowSsh 7.31:    [ 3 May 2017 ]

  • This is not a new feature release, but a successor to 7.29 with continued maintenance updates. (We skip over versions containing zeros to avoid ambiguities. For example, 7.03 and 7.30 might both be referred to as "7.3".)
  • Small changes in key places improve CPU efficiency on the order of 30% (impact may depend on the system). This improves transfer speeds where CPU is the bottleneck – or maintaining same performance, allows for a greater number of simultaneous connections. Users who were previously maxing out a single core and seeing transfer speeds of e.g. 150 MB/s, may now see e.g. 200 MB/s.
  • Diffie-Hellman key exchange algorithms that use group exchange are once again deprioritized, regardless of which cryptographic provider is in use. This means other key exchange algorithms will again be preferred. In version 7.21, we stopped deprioritizing these algorithms because our Windows CNG cryptographic provider can handle dynamic DH group parameters generated by servers like OpenSSH. However, there remain older servers, such as SunSSH, which generate DH groups which are not acceptable to any of our cryptographic providers.

Changes in FlowSsh 7.29:    [ 31 March 2017 ]

  • Fixed a rarely occurring race condition which could cause FlowSsh to terminate the host application when closing an SFTP channel.

Changes in FlowSsh 7.24:    [ 14 January 2017 ]

  • Compatibility improvement for older versions of Cerberus FTP Server: when downloading a textual file using the file transfer mode Auto Std, FlowSsh will now close the file before reopening it in text mode. This is to avoid issues with servers that do not properly handle two open handles to the same file simultaneously.

Changes in FlowSsh 7.21:    [ 31 December 2016 ]

  • Cryptography:
    • On Windows Vista, Windows Server 2008, and newer, our SSH Server, SSH Client, and FlowSsh now support server and client public key authentication using Ed25519, and ECDH key exchange using Curve25519. These algorithms are not available when Windows is running in FIPS mode.
    • We have updated support for OpenSSH private keys, so that our software is now able to import and export them in their new format as introduced by OpenSSH in December 2013.
    • Our SSH Server, SSH Client, and FlowSsh now support Diffie Hellman key exchange with 3072-bit and 4096-bit fixed groups, using SHA-512 as the exchange hash; and with the 2048-bit fixed group using SHA-256 as the exchange hash.
    • On Windows Vista, Windows Server 2008, and newer, our SSH Client and FlowSsh no longer deprioritize key exchange methods that use DH group exchange. On Windows XP and Windows Server 2003, the group exchange methods are still deprioritized by default, because ephemeral DH groups generated by most SSH servers do not pass validation by the Crypto++ cryptographic module we use on these older platforms.
    • The FlowSsh KeyExchangeAlgs parameter structure now supports configuration of minimal, maximal, and optimal group sizes when using Diffie Hellman group exchange.
  • SSH:
    • SSH protocol obfuscation, with optional obfuscation keyword, is now supported in the same way as in Bitvise SSH Server and Client. Obfuscation can be enabled via the new Client method, SetObfuscation.
  • Port forwarding:
    • Dynamic proxy forwarding is now supported using SOCKS4, SOCKS5, or the HTTP CONNECT method. It is enabled and disabled via the new Client methods EnableProxyForwarding and DisableProxyForwarding.
    • Logging of port forwarded connections is now supported. To handle notifications of port forwarded connections, configure a ForwardingLogHandler using Client.OnForwardingLog.
    • Listening sockets created by FlowSsh, such as for client-to-server port forwarding, now use a larger backlog value to reduce the likelihood of connections being refused.

Changes in FlowSsh 7.15:    [ 4 September 2016 ]

  • In version 7.14, the FlowSshC/Cpp/Net version was increased to 7.14, but the inner FlowSsh version was left at 7.12. Increased both versions to 7.15.

Changes in FlowSsh 7.14:    [ 3 August 2016 ]

  • SSH implementations have a chance of generating RSA signatures slightly smaller than expected with a small probability (e.g. 1:200). Windows CNG has been found to not validate such signatures as presented. With our software versions 7.12, this has resulted in occasional connection or login attempt failures. Our SSH Server, SSH Client, and FlowSsh now re-encode RSA signatures, so that smaller-than-expected ones can verify correctly.
  • Windows CNG, as used by our new cryptographic provider in versions 7.xx, has been found to return an incorrect signature size for odd-sized RSA keys (e.g. for 1023-bit or 2047-bit keys). Most SSH implementations do not generate odd-sized RSA keys, but there are old versions of PuTTY which do (e.g. version 0.62). Our SSH Server, SSH Client, and FlowSsh now take steps to support generating and validating signatures using such keys.
  • Certain implementations (e.g. OpenSSH version 7.2, but not 7.2p2) have been found to encode RSA signatures using the new signature methods rsa-sha2-256 and rsa-sha2-512 in a way that is not compatible with the specification of these methods. For compatibility, our SSH Server, SSH Client, and FlowSsh will now accept these alternate signature encodings.
  • Our SSH Server, SSH Client, and FlowSsh now have improved Windows error reporting, distinguishing NTSTATUS error messages from those associated with HRESULT.

Changes in Bitvise FlowSsh 7.12:    [ 25 June 2016 ]

  • Cryptography:
    • Important: DSA keys larger than 1024 bits are no longer supported. The implementation of these keys in Bitvise software pre-dated the NIST standard for large DSA keys, and was incompatible both with the NIST standard and other implementations that might use it. In general, support for the DSA algorithm is being deprecated by SSH implementations. For interoperability with older SSH installations, we continue to support 1024-bit DSA keys, but we recommend migrating either to 3072-bit RSA, or ECDSA.
    • On Windows Vista, Windows Server 2008, and newer, our software now uses a new cryptographic provider, CiWinCng, which uses built-in Windows cryptography. This provider adheres to FIPS 140-2 requirements as long as FIPS mode is enabled in Windows security policy. In FIPS mode, ECDSA and ECDH are supported with curves nistp256, nistp384 and nistp521, but not with curve secp256k1 because this curve is not implemented in Windows. When FIPS mode is disabled in Windows, the curve secp256k1 remains available (implemented using Crypto++).
    • On Windows XP and Windows Server 2003, our software continues to use our previous cryptographic provider, which uses the Crypto++ 5.3.0 DLL. This DLL was FIPS-certified, but its certificate has been moved to the historical list due to changed random number generator requirements since January 1, 2016.
    • When using the new CiWinCng cryptographic provider - default on all recent Windows versions - the encryption/integrity algorithms aes256-gcm and aes128-gcm are now supported. Our implementation is interoperable with the OpenSSH implementation of these algorithms.
    • New RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 are now supported for host authentication.
    • The EXT_INFO extension negotiation mechanism is now supported, allowing for the use of new RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 for client authentication.
  • SSH and SFTP:
    • When connecting to an SSH server for which some host keys are already known (as full host keys - not fingerprints), the preference list of host key algorithms will now be reordered to favor algorithms for which host keys are known. Previously, if an SSH server added a new host key using an algorithm preferred by the client over an algorithm of a previous host key already trusted by the client, the new host key would have to be manually verified for the very next connection, or else the connection would fail.
    • When the server supports file hashing in SFTP version 6, files that already exist on both sides will now be transferred with greater efficiency, and ensuring greater correctness, by comparing hashes of the portion of the file that already exists on both sides, and transferring only the parts determined to be different. This transfer mode overrides the normal Overwrite and Resume modes that are otherwise available with servers that do not support file hashing.
  • General:
    • Recent FlowSsh versions targeted the SSE2 instruction set, which caused them to not run on old computers lacking support for SSE2. Versions 7.xx now target the SSE instruction set, which allows for compatibility with old CPUs, at the cost of a small performance penalty - in our measurements, between 0 and 0.5%.

Changes in Bitvise FlowSsh 5.39:    [ 5 April 2016 ]

  • Fixed an issue which could cause FlowSsh, and the process in which it runs, to crash under rare conditions.
  • Fixed a small memory leak which could become visible after long periods of use, e.g. after tens of thousands of SSH sessions under the same process.

Changes in Bitvise FlowSsh 5.38:    [ 26 January 2016 ]

  • Fixed a race condition that would cause process instability and abrupt termination on creation of an SFTP channel. The problem appears to have existed in all earlier FlowSsh versions, but became more visible in version 5.37. Due to the significance of the issue, this version continues to include an upgrade amnesty. Upgrade recommended.

Security Notification:    [ 30 November 2015 ]

  • We have recently discovered a security issue in a common library used by Bitvise software. Given specific, but common conditions, this issue can be exploited by an unauthenticated remote attacker to cause instability and denial of service in affected software. We cannot exclude that this issue could be exploited to run arbitrary code.

    The following versions of our software are affected:

    • SSH Server 5.xx and 6.xx, up to and including version 6.43. Version 6.44 and newer do not contain this issue.
    • SSH Client 6.xx, up to and including version 6.43. Versions 6.44 and newer do not contain this issue.
    • FlowSshC/Cpp/Net versions up to and including 5.36. Versions 5.37 and newer do not contain this issue.

    To help mitigate this issue, Bitvise SSH Server versions 6.44 and 6.45, and Bitvise SSH Client versions 6.44 and 6.45; and FlowSsh version 5.37; contain an upgrade amnesty, so that any existing license that is valid for any of the software versions affected by this issue can be used with the respective latest unaffected software version. This means that all users of Bitvise SSH Server and Client 5.xx and 6.xx can upgrade to version 6.45, and can activate it using their existing activation code. This also applies to FlowSsh users upgrading to version 5.37.

    Users of Bitvise SSH Server and Client per-installation licenses can log in to access their existing activation codes.

    Users of FlowSsh, and users of large-scale licenses, can upgrade using activation codes received in order delivery.

Changes in Bitvise FlowSsh 5.37:    [ 10 November 2015 ]

  • Contains an important update. Upgrade recommended for existing users.

Changes in Bitvise FlowSsh 5.36:    [ 29 October 2015 ]

  • If configured, the session inactivity timeout could take up to double the amount of time as configured. Detection of this timeout is now more accurate.
  • The GSSAPI DH key exchange method with group exchange is now also de-prioritized when connecting to non-Bitvise servers, along with other methods that use group exchange. (Non-Bitvise servers tend to generate DH parameters that are incompatible with the FIPS cryptographic provider used by FlowSsh; this results in key exchange failures.)
  • Robustness improvements affecting FlowSshCpp and FlowSshNet:
    • Channel objects now maintain a reference to their parent Client object. Previously, a Client object could be destroyed with an active Channel if the user held the Client reference in a way that allowed the garbage collector to release it.
    • Reworked reference counting in FlowSshCpp to improve robustness and eliminate crashes that could occur during stress testing on some platforms. Users of FlowSshCpp that use explicit reference counting (with raw pointers) should note that AddRef now must be called explicitly after instantiating an object (e.g. Client). Users who use RefPtr (recommended) should see their code continue to work as before.

Changes in Bitvise FlowSsh 5.35:    [ 30 August 2015 ]

  • Interaction with Bitvise SSH Client: FlowSshNet is now included with Bitvise SSH Client, which comes with .ps1 scripts demonstrating how to use FlowSshNet from PowerShell. The FlowSsh library - including the standalone version - can now be used under the Bitvise SSH Client license if Bitvise SSH Client is installed on the same computer. FlowSsh no longer displays an evaluation dialog on computers where Bitvise SSH Client is installed.
  • Correctness: FlowSshNet previously used a handler architecture which could cause a Keypair object to be released by the .NET application before it was released by FlowSshC running in native code. This would cause FlowSshC to later make a call from a native fiber into .NET to release the Keypair object. This worked in .NET 2.0, but causes the application to crash in .NET 4.0. To address this, we have re-architected FlowSsh handlers, so that calls from a native fiber into .NET no longer occur.
  • Ease of use: What was previously the Client class in FlowSshNet is now ClientBase. A new Client class now derives from ClientBase, and implements additional methods that can help a simple FlowSshNet application, such as a PowerShell script, from having to define event handlers entirely. This makes FlowSshNet easier to use for scripting, and allows it to be used from PowerShell, which does not support implementing event handlers with return values.
  • SSH:
    • SHA-256 public key fingerprints, compatible with the latest OpenSSH versions, are now supported.
    • ECDH and ECDSA key exchange and host key algorithms are now supported in FlowSshCpp and FlowSshNet.
    • The 1024-bit fixed prime Diffie Hellman key exchange method, diffie-hellman-group1-sha1, is now disabled by default, due to doubts about continuing security of Diffie Hellman with a 1024-bit fixed prime. Compatibility with most older servers should be retained via the diffie-hellman-group14-sha1 method, which uses a 2048-bit fixed prime. We recommend migrating older SSH servers to new versions supporting ECDH and ECDSA.
    • Symmetric encryption algorithms that use CBC mode are now disabled by default. FlowSsh, as well as Bitvise SSH Client and Server, implement defenses against attacks on CBC mode, but other implementations that still use CBC mode are unlikely to implement such defenses. Most implementations should now support encryption in CTR mode.
  • SFTP:
    • OpenSSH servers contain a flaw where a noisy shell startup script, such as a .bashrc file, will cause garbage data to be passed to an SFTP client on the SFTP channel. Previously, this would prevent establishing an SFTP session. The client now ignores such invalid data, and looks for a particular byte signature to indicate the start of the server's first packet in the SFTP session.
    • When transferring files in text mode using SFTP version 4 or higher, the ignored offset is now set to an invalid 64-bit value instead of zero. This prevents an unending transfer with servers that do not ignore the offset as required by the textual transfer mode (e.g. older versions of VShell).
    • Fixed an issue which could cause the SFTP client to send more channel data after sending channel close.

Changes in Bitvise FlowSsh 5.34:    [ 2 May 2015 ]

  • When key exchange fails due to no match in algorithms, the local and remote algorithm lists are now reported.
  • The final build of version 5.33 contained an issue which would cause the using application to freeze on exit.

Changes in Bitvise FlowSsh 5.33:    [ 26 April 2015 ]

  • When using SFTP protocol version 6, SSH_FXP_OPEN requests sent by previous FlowSsh versions would include the flag SSH_FXF_BLOCK_WRITE, in an attempt to prevent remote files from being modified while FlowSsh is accessing them. This resulted in servers that do not support this flag failing such open requests, preventing successful transfers. This flag is currently no longer sent as part of SSH_FXP_OPEN.
  • The Client object now supports the method SetKexDoneHandler, allowing the application to register for notifications of completed key exchanges, and to receive data about negotiated key exchange, encryption, data integrity, and compression algorithms. It was previously not possible for the application to obtain information about algorithms actually negotiated by the library.
  • The Client object now implements the method SetDebugFile, allowing an application developer to capture a debug record of the SSH session for purposes of testing and diagnosis. Use event mask 1024 (0x0400) for the most common event type desired (FlowDebug::MessageSent).
  • Objects caching public key information kept internally by FlowSsh are now properly thread-safe. It was previously possible for concurrency issues to arise with applications that could call Client.Connect on multiple threads simultaneously.

Changes in Bitvise FlowSsh 5.27:    [ 4 November 2014 ]

  • The Keypair object now supports the method GetPuttyData, allowing for private keys to be exported in PuTTY format.
  • The Keypair method CreateNew now supports ECDSA algorithms in addition to "ssh-rsa" and "ssh-dss". The following additional algorithm names are now supported: "ecdsa-sha2-nistp256", "ecdsa-sha2-nistp384", "ecdsa-sha2-nistp521", "ecdsa-sha2-".
  • FlowSsh now supports ECDH-based key exchange algorithms, and ECDSA host authentication. Additional fields for these algorithms have been added to structures KeyExchangeAlgs and HostKeyAlgs.
  • Data integrity protection algorithms that use MD5, or that produce a truncated 96-bit digest ("hmac-md5", "hmac-XXXX-96"), are now disabled by default, but can still be enabled explicitly by the application.
  • The Client object now supports the method SetSocketProvider. By default, FlowSsh will use only a narrow selection of trusted Windows Layered Service Providers, which promotes stability, but comes at a possible expense of connectivity. Applications can now use this method to cause FlowSsh to use any LSP that may be installed, promoting connectivity, but at a possible expense of stability. Please note that non-default LSPs have been deprecated with Windows Server 2012, in favor of the Windows Filtering Platform.

Known Issue

  • Windows XP: All versions of our software that we recommend using are built using Visual Studio 2015. The C++ run-time library used by this Visual Studio version has a known issue where 1-2 kB of memory are leaked each time a new thread is created. This issue does not occur on later Windows versions; it does not occur e.g. on Windows Server 2003. Microsoft has stated they do not intend to fix this issue. Bitvise's view is that the impacts on our SSH Client and FlowSsh are manageable; whereas our SSH Server is rarely used on Windows XP. We therefore do not plan to work around this; but we warn that this can be a potential denial of service vector on Windows XP.