Solved

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

Posted on 2016-09-25
4
744 Views
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 :
https://www.sans.org/reading-room/whitepapers/bestprac/correctly-implementing-secrecy-35842

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
WeakCiphers_PT.jpg
0
Comment
Question by:sunhux
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
4 Comments
 
LVL 40

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.
0
 
LVL 40

Accepted Solution

by:
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.
0
 

Author Comment

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

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.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

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

Businesses who process credit card payments have to adhere to PCI Compliance standards. Here’s why that’s important.
Do you know what to look for when considering cloud computing? Should you hire someone or try to do it yourself? I'll be covering these questions and looking at the best options for you and your business.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, just open a new email message. In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
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…

738 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