Oracle says that starting with April 18, 2017, Java (JRE) will treat all JAR files signed with the MD5 algorithm as unsigned, meaning they'll be considered insecure and blocked from running.
Oracle originally planned MD5's deprecation for the current Critical Patch Update (CPU), released this week, which included a whopping 270 security fixes, one of the biggest security updates to date.
The company decided to give developers and companies more time to prepare and delayed MD5's deprecation for the release of Oracle Java SE 8u131 and the next Java CPU, scheduled for release in April,
MD5, which is a basic hashing algorithm, has been slowly phased out of browsers and other technologies during the past few years after it was proven to be insecure and easy to crack at the start of the 2000s.
In Java development, programmers sign their JAR files as a way to authenticate who wrote the code. In the 90s, when MD5 was considered secure, it became the favorite algorithm to sign JAR files.
At the start of the millennium, researchers proved that an attacker could provide two different inputs and obtain the same output hash, allowing the attacker to forge MD5 signatures.
In recent years, Oracle has been advising Java developers to use powerful and dedicated code-signing keys instead. In fact, Oracle removed MD5 as a default code signing option from Java SE 6, released in 2006.
Despite this, there will be thousands of Java apps that will never be resigned. For this, Oracle will allow system administrators to set up custom deployment rule sets and exception site lists to allow Java applets and Java Web Start applications signed with MD5 to run.
Sometimes in the second half of 2017, Oracle also plans to change the minimum key length for Diffie-Hellman algorithms to 1024 bits. These updates are part of Oracle's long-standing plan for changes to the security algorithms in the Oracle Java Runtime Environment (JRE) and Java SE Development Kit (JDK).
Below we are going to reproduce some of the instructions provided by Oracle to Java devs in October's Critical Patch Update bulletin.
To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.
For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar
If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSA jar: processEntry: processing block jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA jar: done with meta!
The updated jarsigner command will exit with the following warning printed to standard output:
"Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"
To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size.
Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:
zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'
To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.