Mitigating the SSH Terrapin Attack

On December 18, 2023 the SSH Terrapin attack was publicly disclosed. This attack requires Man-in-the-Middle capabilities and that the connection be secured with ChaCha20-Poly1305 or CBC with Encrypt-then-MAC. Read more details on the attack website

As of build 8788 all /n software products have been updated with support for the "strict KEX" protocol extension which mitigates the attack by default, provided both client and server support this extension. Support is configurable through the UseStrictKeyExchange setting. When using previous version of the software this attack may be mitigated by disabling the affected algorithms as detailed below.


  1. UseStrictKeyExchange
  2. Disable Affected Algorithms (Legacy)


All nsoftware SSH products (e.g. IPWorks SSH, SecureBlackbox) implement the "strict KEX" protocol extension. This extension is defined in OpenSSH 9.6. By default, this extension is enabled in nsoftware products and if both the client and server side support this extension the attack is mitigated. Since both client and server must implement strict key exchange to effectively mitigate the Terrapin attack, the component also provides options to further control the behavior in different scenarios.

When UseStrictKeyExchange is set to 1 (default), the component will indicate support for strict key exchange by automatically including the pseudo-algorithm for client components and for server components in the list of supported key exchange algorithms.

To specify the desired behavior set UseStrictKeyExchange to one of the following values:

0Disabled. Strict key exchange is not supported in the component.
1(default) Enabled, but not enforced. This setting enables strict key exchange, but if the remote host does not support strict key exchange the connection is still allowed to continue.
2Enabled, but reject affected algorithms if the remote host does not support strict key exchange. If the remote host supports strict key exchange all algorithms may be used. If the remote host does not support strict key exchange the connection will only continue if the selected encryption and MAC algorithms are not affected by the Terrapin attack.
3Required. If the remote host does not support strict key exchange the connection will fail.

For instance: Sftp sftp1 = new Sftp(); sftp1.Config("UseStrictKeyExchange=3"); // Remote host MUST support strict KEX

When connecting the output of the Log event will indicate whether Strict Key Exchange is in use. The presence of the text Remote host supports strict kex. indicates both sides support Strict Key Exchange and it will be used. The presence of the text Remote host does not support strict kex. indicates the remote side does not support Strict Key Exchange and the behavior of the component depends on the value of the UseStrictKeyExchange configuration setting as detailed above.

Disable Affected Algorithms (Legacy)

In cases where updating to a new build of the software which supports Strict Key Exchange is not possible, the following steps may be taken to disable the affected algorithms and mitigate the attack.


Sftp sftp1 = new Sftp(); //Disable encryption algorithm sftp1.SSHEncryptionAlgorithms = sftp1.SSHEncryptionAlgorithms.Replace("", ""); //Disable MAC algorithms string[] vulnerableMacAlgos = new string[] { "", "", "", "" }; string myMacAlgos = sftp1.Config("SSHMacAlgorithms"); foreach (string vulnerableMacAlgo in vulnerableMacAlgos) { myMacAlgos = myMacAlgos.Replace(vulnerableMacAlgo, ""); } sftp1.Config("SSHMacAlgorithms=" + myMacAlgos);


Sftpclient sftpclient1 = new Sftpclient(); sftpclient1.SSHSettings.AutoAdjustCiphers = false; //Disable encryption algorithm sftpclient1.SSHSettings.EncryptionAlgorithms = ",-chacha20-poly1305"; //Disable MAC algorithms sftpclient1.SSHSettings.MacAlgorithms = ",,,-chacha20-poly1305";

We appreciate your feedback.  If you have any questions, comments, or suggestions about this article please contact our support team at