What is the vulnerability?
Weakness in key generation.
Which Tectia versions are vulnerable?
All Tectia Client and Server versions running on Windows (before version 6.4.19) are vulnerable.
I’m only running Tectia on UNIX, Linux or z/OS, does this affect me?
No, only Windows installations are vulnerable.
I’m using ConnectSecure, is it affected?
Yes. ConnectSecure running on Windows is vulnerable.
I’m using Universal SSH Key Manager, PrivX, Tectia Manager or CryptoAuditor, are they affected?
No.
What do I need to do?
- We strongly recommend you to upgrade all Tectia Clients and Servers running under Windows to version 6.4.19 by June 30, 2021.
- To fully resolve the issue, we also recommend you to regenerate all user keys that were generated by Tectia running on Windows operating system.
- User keys that have been generated in FIPS mode don't have to be regenerated.
- To fully resolve the issue, we also recommend you to consider regenerating all host keys that were generated by Tectia running on Windows operating system.
Where can I download Tectia 6.4.19?
I’m only using Password authentication, do I need to regenerate my keys?
No.
I’m running my Tectia Server in FIPS mode, do I need to regenerate my keys?
Yes, unless your host key is already configured in Tectia Server as external key that was generated either with ‘ssh-keygen-g3 -H --fips-mode’ command or generated externally.
I’m using Tectia on Windows with hostkey generated on HSM (Hardware Security Module) or User keys / certificates on a Smart Card, do I need to regenerate my keys?
No.
I’m using Tectia on Windows with private key and X.509v3 certificates from PKCS#12 package, do I need to re-enroll my certificates?
No, unless the private key was generated using Tectia on Windows.
I’m only running Tectia on an internal network, do you still recommend to regenerate the keys?
We estimate that the vulnerability will require the resources of a state-level actor to exploit; this would mean it’s beyond the means of any normal authorized user of the network to exploit this vulnerability. The customer have to perform their own risk analysis of unauthorized users gaining access to the internal network to be able to exploit this vulnerability.
How fast should I be regenerating the keys?
We recommend regenerating the keys by June 30, 2021.
I have version 6.4.18, how safe is it to upgrade to 6.4.19?
4.19 is a patch release, so it only contains security fixes to the vulnerabilities, plus a few important fixes where the connection would fail in some corner cases.
I have been running 6.4.18 as a LTS version how does this affect Long Term Support?
Version 6.4.19 is part of the 6.4 LTS stream, so the LTS contract will be transferred to it. It will be valid until March 2023.
I have version 6.4.17, what do I do?
Upgrade to 6.4.19. Version 6.4.18 is widely used and stable and it has only one known regression, which is also fixed in 6.4.19. Please see the
server and
client release notes.
I have version 6.4.16 or earlier, what do I do?
These versions are out of support. Please upgrade to 6.4.19.
I have a very old version (6.3 or earlier), what do I do?
Please upgrade to 6.4.19; see
this link for details on version compatibility.
How do I see that a key needs to be replaced (if I’m, for example, in the middle of a key replacement process)?
- The key file contents do not have information on which Tectia versions they were created on.
File time stamps can be used for some degree of reliability.
How do I regenerate my user keys?
- The safest way is to go through all client installations, remove the old private keys, regenerate and upload.
- It is also important to remove the old user public keys from the servers where they are uploaded.
- If you have access to the SSH.COM UKM tool, you can use it to automatically regenerate user keys and upload them to Tectia Servers and non-Windows OpenSSH servers.
- Contact our support for advice, policy recommendations or professional services offerings.
How do I regenerate my host keys?
- The safest way is to go through all server installations, remove the old host keys and regenerate and inform your users of the changed identity and the new expected hostkey fingerprint.
- Clients that have saved the old host key will be issued a hostkey changed warning. Users that are operating the GUI client, or that are manually operating the command-line client, will be able to accept the changed hostkey upon connection and should be instructed to do so by replacing the host key instead of adding the alternate identity after verifying the hostkey fingerprint. For users that are running the command-line client via a script, the old host keys need to be replaced prior to running the script or connection will fail upon changed hostkey.
- If you have access to the SSH.COM UKM tool, you can use it to locate any host keys within your organization.
- Tectia Server version 6.4.19 has a feature to help with changing the host keys on the client side. To use it, you can configure host key rotation on the server-side. This will allow clients that authenticate the server with the old host key to save the new host key after successful user authentication and delete the old one once the old key is removed on the server-side, for example after 3 months. This feature requires a Tectia client version 6.4.19 that has Host Key Policy Rotation enabled (by default enabled when connecting to Tectia servers only) or a OpenSSH client version 6.8 or above that has UpdateHostKeys enabled.
- Contact our support for advice, policy recommendations or professional services offerings.
Is it really necessary to regenerate the keys in my situation?
-
A general security recommendation for SSH keys is to regenerate all keys every two years, regardless of vulnerabilities.
-
Please see the sample high level project plan.
-
Contact our support for advice, policy recommendations or professional services offerings.
