Solved

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

Posted on 2016-09-25
4
113 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
  • 3
4 Comments
 
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.
0
 
LVL 38

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

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Since pre-biblical times, humans have sought ways to keep secrets, and share the secrets selectively.  This article explores the ways PHP can be used to hide and encrypt information.
Never store passwords in plain text or just their hash: it seems a no-brainier, but there are still plenty of people doing that. I present the why and how on this subject, offering my own real life solution that you can implement right away, bringin…
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…
This video explains how to create simple products associated to Magento configurable product and offers fast way of their generation with Store Manager for Magento tool.

743 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

10 Experts available now in Live!

Get 1:1 Help Now