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

Posted on 2016-09-25
Last Modified: 2016-09-28
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
Question by:sunhux
  • 3
LVL 38

Expert Comment

by:Adam Brown
ID: 41815126
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.
LVL 38

Accepted Solution

Adam Brown earned 500 total points
ID: 41815138
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.

Author Comment

ID: 41815467
So essentially upgrading this device's TLS to ver 1.2 will address this finding?
It's MobileIron
LVL 38

Assisted Solution

by:Adam Brown
Adam Brown earned 500 total points
ID: 41816126
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.

Featured Post

Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
CA single sign on 2 74
Sudden performance loss on a Vista system. 14 145
Auto Smartport macro for Dell and HP laptops 2 54
Unknown security group 2 59
Big data transfers via information superhighways require special attention and protection. Learn more about the IT-regulations of the country where your server is located. Analyze cloud providers and their encryption systems for safe data transit. S…
An overview of HIPAA and guidance on this topic that Experts Exchange members can offer.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

895 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now