Countermeasures to Neutralize TLS Renegotiation MITM Vulnerability in JAVA

The protocol level TLS renegotiation Man-In-The-Middle (MITM) vulnerability has already been fully fixed in Java SE for quite a while.  The following table shows the status of JDK/JRE releases and updates to neutralize the vulnerability in Java.

Renegotiation is VulnerableRenegotiation is DisabledRenegotiation is Secure
JDK/JRE 7N/AN/AAll releases
JDK/JRE 6Update 18 and earlierUpdates 19-21Update 22
JDK/JRE 5.0Update 23 and earlierUpdates 24-25Update 26
JDK/JRE 1.4.2Update 25 and earlierUpdates 26-27Update 28

Unfortunately, research shows many famous commercial sites on the Web have not yet upgraded their software, according to the last report, Potential Vulnerability status of major ecommerce sites (Please see my previous post).

Much worse, for some circumstance, it is not always easy to upgrade Java Runtime Environment. In such cases, we need workarounds to mitigate the impact of the vulnerability on vulnerable releases.

The Primary Countermeasure: Upgrade to renegotiation secure updates
  • Upgrade the Java Runtime Environment to JRE 7, JRE 6 update 22, JRE 5.0 update 26, or JRE 1.4.2 update 28 or later.
The Passive Countermeasure: Disable renegotiation 
  • Upgrade the Java Runtime Environment to JRE 6 update 19-21, JRE 5.0 update 24-25, or JRE 1.4.2 update 26-27.
  • Disable unsafe renegotiation in application level, especially for Java Runtime Environment of JRE 6 update 18, JRE 5.0 update 23, or JRE 1.4.2 update 25 or earlier.

        // disable new session renegotiation.
    sslSocketInstance.setEnableSessionCreation(false)
Or
    // disable new session renegotiation.
    sslEngineInstance.setEnableSessionCreation(false).

    Disable session creation cannot prevent SSL/TLS renegotiation communication, but the renegotiation will fail because the local cannot create new session. As will mitigate the impact of the vulnerability.

The Alternative Passive Countermeasure: Requires non-anonymous credential in vulnerable releases

Requires peer non-anonymous credential may not be able to eliminate vulnerability completely, but it make it is possible to find the hacker when attack happens. If there is no way to upgrade to renegotiation-safe releases, and renegotiation is required in your application, you may want to consider the following countermeasures:
  • Requires client X.509 certificate authentication and server X.509 certificate authentication
  • ONLY use the following cipher suites:
    • Kerberos authentication based cipher suites; (RFC 2712)
    • Pre-Shared Keys authentication based cipher suites; (RFC 4279)
    • Secure Remote Password authentication based cipher suites. (RFC 5054)
Anyway, the recommended approach is to upgrade the Java Runtime Environment to JRE 7, JRE 6 update 22, JRE 5.0 update 26, or JRE 1.4.2 update 28 or later.

What do you think?

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

NIST Security Strength Time Frames

Security Strength Time Frames of NIST SP 800-57 Part 1 Security Strength 80 112 128 192 256 applying processing applying processing through 2010 acceptable acceptable acceptable acceptable acceptable acceptable acceptable 2011 through2013 deprecated legacy use acceptable acceptable acceptable acceptable acceptable 2014 through 2030 disallowed legacy use acceptable acceptable acceptable acceptable acceptable 2031 and Beyond disallowed legacy use disallowed legacy use acceptable acceptable acceptable Symmetric Algorithms 2TDEA 3TDEA AES-128 AES-192 AES-256 FFC (e.g., DSA, D-H) L = 1024 N = 160 L = 2048 N = 224 L = 3072 N = 256 L = 7680 N = 384 L = 15360 N = 512 IFC (e.g., RSA) k = 1024 k = 2048 k = 3072 k = 7680 k = 15360 ECC (e.g.,ECDSA) f = 160-223 f = 224-255 f = 256-383 f = 384-511 f = 512+ Digital Signatures and hash-only applications SHA-1, SHA-224, SHA-256, SHA-384, SHA-5...
Read more

JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

Image
The implementation of  JEP 114  (TLS Server Name Indication (SNI) Extension) had  integrated into JDK 8  at October, 2012. In  the previous blog entries , we talked about the behavior changes in JSSE, and a few typical user cases . Let's look at a special user case, how to design a virtual server dispatcher in Java. Please refer to javax.net.ssl package of  JDK 8 APIs  for the detailed specification. Prepare the ClientHello Parser Applications need to implementation their own APIs to parser the client hello message from a plaintext socket. Suppose that an application design the following API to do the work, SSLCapabilities and SSLExplorer. SSLCapabilities is defined to show the SSL/TLS security capabilities during handshaking, SSLCapabilities can be retrieved by exploring the network data of an SSL/TLS connection via SSLExplorer.explore(ByteBuffer). /** * Encapsulates the security capabilities * of an SSL/TLS connection. * * Th...
Read more