Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2829
  • Last Modified:

Which is 'Static Key Ciphers' reported in PT scan?

Our scanner only elaborates on Med & High risk items.

As this is a low-risk item, the scanner did not elaborate what it is but I found one
Med risk item which lists out the ciphers : refer to attached screen

The scan reported: "The device (it's an appliance) is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted."

Based on the SANS link below, I'm assuming it's the 1st 3 ciphers in the attached screen as these 1st 3
ciphers have no mention of DHE :

Let me know if I got it wrong & how should I go about addressing this reported vulnerability.

I can elaborate on what is that device if needed but I don't think I'm allowed to run an "ssl_connect"
client command against it as it's a Prod device
  • 3
2 Solutions
Adam BrownSr Solutions ArchitectCommented:
Essentially, the use of TLS1.0 utilizes a "Static Key Cipher". Basically, here's how it works.

In a typical TLS session exchange, the client system receives a copy of the server's public key, generates a session key, encrypts the key using the server's public key, and then sends it the the server. The server decrypts the session key and sends all future messages after encrypting with the session key. This allows both systems to know what the key is in a way that can't be eavesdropped on. The weakness in this method is that it is always possible to decrypt the data using the private key on the server. If, somehow, the key becomes disclosed either through a brute force method or through weaknesses in the key generation algorithm, all past session information can be decrypted because all sessions can be decrypted with the same key. That's what the term "Static Key Cipher" means. You can decrypt every session with the same key.

Forward Secret changes the exchange so that each time a new session is created, the server and client agree on a specific algorithm to use and a random variable to use for generating entirely unique private keys that are used only for that exchange. The server's Private Key is used to validate and authenticate the algorithm, but cannot be used to decrypt the data itself. Each session is encrypted with a randomly generated private key that is based on the server's Private key, but different enough to prevent the server's private key from being used to decrypt any prior sessions.

TLS 1.0 *supports* Forward Secret exchanges, but does not always accept attempts to build sessions with it. As a result, it is not considered secure because the algorithm used to generate the Public/Private key pair in the certificate has known weaknesses that can result in unauthorized disclosure of the server's Private key, which would result in the ability to decrypt all sessions established with that key. In this Case, SHA/SHA1 (different names for the same thing) has significant identified weaknesses that make it non-viable as a key generation algorithm in the future.

TLS 1.2, however, supports and requires Forward Secret exchanges and also requires the use of more robust key generation algorithms like SHA2 and later.

The vulnerability you have is that your server certificate was generated with SHA, which means the use of TLS1.0 opens a known vulnerability in session encryption. The issue is marked as a "Low Severity" vulnerability because the disclosure of session data still requires a lot to accomplish. Someone has to capture the session data and determine your server's private key. With the known vulnerabilities in SHA, this is possible, but still takes a good deal of time and resources to accomplish, so session data is still protected from eavesdropping, but given time the data can be discovered if the private key is ever determined by unauthorized individuals.

You *can* continue using TLS 1.0 on the server without falling subject to a vulnerability *if* you replace your server's certificate with one generated using a more secure algorithm. You can also continue to use the existing Certificate *if* you reconfigure your server to utilize only TLS 1.2.

TL;DR: Basically that's just telling you to get a new certificate if you want to keep using TLS1.0, or use TLS 1.2 if you want to keep using the same certificate.
Adam BrownSr Solutions ArchitectCommented:
Spent too much time writing the explanation so I didn't really answer your question. The device in question is configured to allow the use of the 6 ciphers listed with TLS 1.0. This means that it will accept certificates that are generated with SHA1, which, as I mentioned, has known vulnerabilities that lead to key disclosure. If you are able to reconfigure the device to either Prohibit TLS1.0 sessions or prohibit the use of Certificates generated with those Cryptosuites, that vulnerability will go away. However, just supporting this ciphers does not mean the device has a certificate that *uses* those ciphers. Most likely, the certificate installed on the device was generated with a different suite, since this was flagged as low severity. Had these ciphers been enabled and the certificate in use generated using them, the severity would have likely been greater.

To verify, examine the certificate installed on the device. If it uses any of the ciphers listed, replace it. If not, you're okay.
sunhuxAuthor Commented:
So essentially upgrading this device's TLS to ver 1.2 will address this finding?
It's MobileIron
Adam BrownSr Solutions ArchitectCommented:
Well, upgrading to TLS 1.2 and ensuring TLS 1.0 is not available for use. You can also check the certificate you have installed on it to view the Crypto-suite it was generated with. If it isn't one of the six listed in that finding, then the finding doesn't apply. You can then just document the fact that the finding doesn't apply because the certificate isn't generated with a weak cipher.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now