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.
        // disable new session renegotiation.

    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

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

JSSE Oracle Provider Preference of TLS Cipher Suites

JEP 114: TLS SNI Extension - Virtual Servers Dispatcher