We pretty regularly have customers calling in looking for assistance with adjusting their MEG TLS configuration due to a vulnerability test they just had done on their systems.  Usually, the request is that we do something with the key lengths the MEG will accept, although sometimes it has to do with one cipher or another that customers would like to discard from use.  Both can be handled, but there are some considerations which admins should take into account before having these things done.


1.  What is the problem being reported?


Generally, the change desired is either to require larger keys for TLS encryption or restrict the appliance from using lower-security ciphers.  This is triggered on because a larger key length is harder to break as are higher security ciphers.  Knowing what the issue is then pretty much gives us the next answer we need.


2.  What is the goal of the change?


In the case of an issue with key length, the vulnerability scan wants to have the appliance using a longer cipher key length.  If cipher strength is at issue, the vulnerability report wants a more secure cipher used.


3. Why is the vulnerability scan calling for this change?


Generally, the point of a vulnerability scan is to verify that systems aren't vulnerable to attack.  When a vulnerability scanner reports that TLS is an issue, it is generally complaining that the key length is not long enough or that the server uses insecure ciphers.  But what does that mean?  Have ciphers really been broken?  In some cases, yes, they absolutely have.  In other cases, there is a weakness which has been found, but the cipher hasn't been broken yet.  In some cases, no specific weakness has been found, but the key lengths and types are simply generally weak. 


When it comes to key length, the system is talking about the symmetric key used by the internal encryption inside TLS, not the public-private key pair(s) used to set up the TLS connection.  This key is negotiated by the two servers in the TLS conversation.  A longer key means a harder-to-break key.  The harder it is to break, the more effort someone is going to have to go to in order to break the encryption, and thus read the data passing through the TLS tunnel.


4.  What are the possible impacts of the change?


First, we have the obvious impacts: 

1.  We'll disallow the use of weaker encryption keys

2.  We'll disallow the use of weaker ciphers


And then we get into secondary impacts:

1.  We'll have to transfer data in the clear to hosts which don't support stronger keys

2.  We'll have to transfer data in the clear to hosts which can't use stronger ciphers

3.  Bigger keys require more processor cycles

4.  More complex ciphers likewise take more processor cycles


So now this brings us to the final question we should ask ourselves.


5.  Does this make sense to do?


And there is the rub.  Does it make sense to restrict the use of lower security keys or lower security ciphers, considering that anyone out there who doesn't have access to those ciphers would be unable to communicate with you?  Does it make sense to refuse to encrypt data with even a weak cipher, and instead send the requested data in the clear?  Let's face facts: Encryption keys are like the keys to your house.  Having locks on your house won't keep out a determined invader.  If someone is determined to break the encryption on your data, they will find a way, regardless of the security measures you have in place.  But the presence of that lock will keep people who aren't determined to break in from doing so.  Thus, admins should take into account all the ramifications of restricting key lengths and cipher strengths when deciding their policy on this subject. 


As a whole, McAfee does not recommend any particular choice here.  Obviously higher security ciphers are better than lower security ones, just as longer keys are better than shorter ones.  However, each company's needs are different, and thus each company should make that decision for themselves.  For customers needing to ensure minimum key lengths, please see KB76384, which discusses how to configure TLS.  In there is included information on how to adjust the cipher strength requirement.  For those needing to restrict the use of particular ciphers or classes of ciphers, it is recommended to call in to Support to discuss with us the precise ciphers you wish to restrict.  Ultimately, steps similar to those found in KB78818 will need to be followed to perform the change.