SFTP FIPS

  • Before upgrading, export and convert your SFTP keys. The new version only creates RSA keys in OpenSSH new format. (You can't generate DSS keys and save keys in SSH.com format.)

  • After upgrading, older ciphers and MACs will be removed automatically, without requiring any manual reconfiguration.

  • Private keys from previous versions:

    • Non-FIPS mode

      • The private keys generated by previous versions should load just fine in non-FIPS mode. Both RSA and DSA and SSH.com formats are supported.

    • FIPS mode

      • FIPS mode does not support md5—only the new format keys are supported. The keys themselves are fine, it is the file format that is not supported. As a workaround, you can use a third-party tool like PuTTYGen to convert your keys to the OpenSSH new format. If later you decide to go back to the older SFTP FIPS library, the new keys will not work and you will either have to use the previous keys or convert the new keys to the old format.

  • After you enable or disable FIPS mode, you must restart the EFT server service.

EFT SFTP FIPS Mode

When placed in FIPS mode, all cryptographic functions required by the SFTP transport protocol are managed by the OpenSSL cryptographic library, which is FIPS certified and thus meets the requirements of organizations that require all cryptographic functions be FIPS certified. While many vendors claim compliance status, it is not the same as "certified," which means the module has undergone third-party laboratory testing. At a functional level, SFTP transport in EFT is based on a Windows port of a modified version of OpenSSH. Modifications were necessary because OpenSSH itself isn’t a library, but rather a product. Also, many of the functions of OpenSSH aren’t relevant to SFTP, such as command-line parsing, X-11 forwarding, and many others. Finally, OpenSSH doesn’t support FIPS mode, and had to be modified following the principles applied by the Fedora FIPS patch that enables OpenSSH implementations on Fedora Linux to use OpenSSL in FIPS mode. When OpenSSH releases new versions, any beneficial changes (performance, security, etc.) can be merged into the SSH implementation in EFT.

Within the OpenSSH code, there are absolutely no cryptographic functions. All crypto is relegated to OpenSSL. In our implementation, OpenSSL consists of several libraries: SslEay.dll, which handles SSL network protocols, key pair loading and unloading, etc., LibEay.dll, which manages all cryptography and is FIPS certified, and SSLFIPS.dll, which acts as layer between EFT and OpenSSL. SSLFIPS.dll also does some key and network management, sans cryptography. OpenSSL is thus used both by SFTP and SSL/TLS-based protocols (e.g. HTTPS, FTPS) in EFT. A further benefit of this new module is that the FIPS-certified cryptographic module is not tied to any particular OpenSSL version, which gives Globalscape the ability to keep current with OpenSSL releases, while conserving its FIPS-certified cryptographic functions, so long as the NIST certification remains current and valid.

SFTP Logging

For Successful Connections:

    • Level of logging in EFT.log should be set to DEBUG.

    • The information should be semicolon separated

    • Items recorded should be in the following order SFTP connection accepted:
      KEX algorithm = ; Host Key Algorithm = ; Cipher algorithm = ; MAC algorithm = ; Compression algorithm = ; ip address = ; connection ID = 

For Failed Connections:

    • Level of logging in EFT.log should be set to INFO

    • The information should be semicolon separated

    • Items recorded should be in the following order SFTP connection failed; ip address=; connection ID=

For Insecure Connections:

    • Level of logging in EFT.log should be set to WARN.

    • The information should be semicolon separated Items recorded should be in the following order Insecure SFTP connection accepted;

      • KEX algorithm = ; Host Key Algorithm = ; Cipher algorithm = ; MAC algorithm = ; Compression algorithm = ; ip address = ; connection ID = 

    • This should occur if the KEX algorithm used is one of the following:  Diffie-Hellman-group1-sha1

    • This should occur if the Cipher algorithm used is one of the following:  arcfour

    • This should occur if the MAC algorithm used is one of the following: hmac-md5; hmac-md5-96

For Weak Connections:

    • Level of logging in EFT.log should be set to WARN.

    • The information should be semicolon separated

    • Items recorded should be in the following order:

      • Weak SFTP connection accepted; KEX algorithm = ; Host Key Algorithm = ; Cipher algorithm = ; MAC algorithm = ; Compression algorithm = ; ip address = ; connection ID = 

    • Weak connections should occur if the:

      • KEX algorithm used is Diffie-Hellman-group-exchange-sha1

      • Cipher algorithm used is one of the following:

        • 3des-cbc

        • blowfish-cbc

        • cast128-cbc

      • MAC algorithm used is one of the following:

        • hmac-sha1

        • hmac-sha1-96

Ciphers and Algorithms

  • In non-FIPS mode:

    • KEX:

      • diffie-hellman-group16-sha512

      • diffie-hellman-group14-sha256

      • diffie-hellman-group-exchange-sha256

      • diffie-hellman-group14-sha1

      • diffie-hellman-group-exchange-sha1

      • diffie-hellman-group1-sha1

    • MACs:

      • hmac-sha2-512

      • hmac-sha2-256

      • hmac-sha1

      • hmac-md5

      • hmac-sha1-96

      • hmac-md5-96

    • Ciphers:

      • aes-256-cbc

      • aes-256-ctr

      • 3des-cbc

      • aes-128-cbc

      • aes-128-ctr

  • In FIPS mode the same as the above except hmac-md5 and hmac-md5-96

COM

  • Due to FIPS requirements we can only generate keys on the server. This is the same as in SSL keypair generation. There is a new COM method "CreateSSHKeyRemotely" which works in the same way as previous version but creates key on the server machine, not where the COM is running. Older method "CreateSSHKey" still works, but it is always in non-FIPS mode.

Legacy BitVise implementation

  • Advanced property

    • The new advanced property "UseLegacySFTP" allows switching to the old implementation. This is a DWORD value under

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\GlobalSCAPE Inc.\EFT Server 7.4

    • Setting it to 1 and restarting EFT will switch to legacy BitVise implementation.

  • MACs, ciphers etc.

    • This setting only selects SFTP engine. Note that because BitVise implementation is quite old, it won't be able to load keys generated by the new version so they should either be recreated (or, for example, converted to one of the older formats using PuTTYgen).

  • FIPS

    • You can switch BitVise to FIPS mode. However, this mode is obsolete and currently is not FIPS compliant.

  • Switching back to the new version

    • Switching back to the new implementation should not require any changes in configuration except when you are in FIPS mode. See the section above, "Private keys from previous versions" for details.