What's new with Java

I'm sick of Java, as you probably are too. That said, there have been a number of changes to Java lately that may have flown under the radar. So, here is what you need to know about where things stand.

To begin with, there are now three latest/current versions of Java.

We have seen two "current" versions in the past as Oracle has maintained two versions of Java allowing for a migration to a newer version. They are doing that again, releasing bug fixes for both the older version 7 and the newer version 8. Version 7 is scheduled to be retired in April 2015.

Windows users running an old copy of Java 7 may get upgraded to the latest edition of Java 7 or to Java 8. The Java automatic update system stays within Java 7. This will not change until "early 2015". However, other types of Java updaters, may bump up a Java 7 installation to Java 8.

The latest version of Java 8, Update 25, was released on October 14, 2014. As of then, new installations of Java install version 8 rather than version 7.

There are, for the first time, two latest versions of Java 7; Update 71 and Update 72. By default, Oracle updates older versions of Java 7 to Update 71.

Update 72 has the same security related bug fixes as Update 71, but also includes additional non-security patches. According to Oracle, Update 72 is "... for developers and users requiring additional non-security improvements or for testing updated features". The additional fixes in Update 72 will be rolled into the next revision of Java 7.

POODLE

The recent POODLE flaw in SSL version 3 serves as a reminder to disable SSL version 3 whenever possible, and, to enable all three versions of TLS (1.0, 1.1 and 1.2). Webmasters need to do this on their servers, regular folks need to do it in their browser(s).

What no one has mentioned so far (that I have seen) is that Java users need to make these same tweaks.

On a Windows system (I have not tested OS X or Linux), open the Java thingy in the Control Panel and go to the Advanced tab. Scroll down to the bottom. The SSL/TLS options there look like those in Internet Explorer, but they are unrelated.

By default Java 7 enables SSL 3.0 and TLS 1.1, the same defaults as Internet Explorer. Turn off SSL 3.0 and turn on TLS 1.1 and TLS 1.2. Java 8 enables all four protocols by default, so all that needs to be done is to disable SSLv3.

For both Java 7 and 8, there is another interesting checkbox just below the SSL/TLS options. It is called "Suppress sponsor offers when installing or updating Java". It is off by default, I would turn it on.

SECURING JAVA

It keeps getting harder and harder to run a Java program (called an "applet") embedded in a web page. The rules often change and warnings are now the norm, both from the web browser and from Oracle.

Plus, there are two sets of rules, depending on whether the applet is digitally signed or not. And there are differences between Java 7 and 8.

Signed applets are treated like normal executables, they can do whatever the host operating system lets them do.

Unsigned applets run in a Java sandbox, walled off from the host system. Although the sandbox is far from perfect, reasonable people might consider applets confined to a sandbox safer. Oracle considers them more dangerous. In my opinion, they are placing way too much faith in the Certificate Authority system. Nonetheless, because Oracle thinks they are a greater security risk, they make it harder to run an unsigned applet than a signed one.

The other big factor in running applets is the Java security level. Java 7 has three security levels, Java 8 (as of Update 20) has only the two highest levels from Java 7. Both versions of Java default to the second highest level, which Oracle calls "high".

The "high" security level blocks the execution of unsigned applets by default. To run one, you have to first whitelist it (more below). The highest security level ("very high") is intended to block all unsigned applets (more on this below).

And, there is more.

Sitting above the Java security levels is an option to "Enable Java content in the browser". The security levels only apply when Java applets are allowed to run in browsers. The default is to enable Java in browsers.

It is much safer to disable Java in all browsers system-wide, if you can. The security flaws associated with Java only come into play when applets run in a browser.

Users that can disable Java in browsers, run normally installed applications that depend on Java. These applications use Java much like some Windows programs use the .NET framework. Some Windows programs that need Java are Wuala, Minecraft, and OpenOffice.

Anyone needing Java in a browser, is best served disabling Java in the browser they use most often, and enabling it only in a second browser dedicated to the websites that use Java.

Note that when Java is disabled system-wide, browsers may react as if Java is not installed. Firefox and Chrome don't even show Java in the list of installed plug-ins. Internet Explorer 11 may or may not show that Java is installed, it depends on the version of Windows and Java.

When Java is enabled for use in browsers, there are still other quirks in Windows 7.

With Java 8 Update 25 installed, a review of Firefox 33 plug-ins shows a dire warning that the "Java Deployment Toolkit version 8.0.250.18 is known to be vulnerable. Use with caution." It is Firefox error messages that should be viewed with caution.

Chrome 38 plug-ins (type chrome://plugins in the address bar) report the Java version as 11.25.2.18. You need go into the details view to see a reference to Java 8 Update 25.

This is just the sort of thing my JavaTester.org website was designed for.

RUNNING APPLETS

Even in the best case, when the installed version of Java is current and the applet is digitally signed, you still get a Java warning before the applet runs (assuming the default "high" security level). I guess Oracle is sick and tired of being the biggest security flaw on the planet.

To illustrate, the question below, "Do you want to run this application" is asked before running Oracle's own, signed applet, that detects the installed version of Java. This prompt is the same in Java 7 and 8.

Running a non-whitelisted unsigned applet at "high" security results in an "Application Blocked by Security Settings" error with Java 7 and the slightly more useful "Application Blocked by Java Security" error with Java 8.

To get around this, the website with the unsigned applet needs to be added to the Java "Exception Site list". This is done from the Java Control Panel, on the Security tab (see below). Click on the "Edit site list..." button, then the "Add" button. Website names have to be proceeded with HTTP(S) colon slash slash. If you reference a site both as "something.com" and "www.something.com" then both need to be whitelisted.

Even after being white-listed, running an unsigned applet generates the question below (on "high" security), which is identical in Java 7 and 8.

For more on the assorted messages Java issues see What should I do when I see a security prompt from Java?

And, all of this is only part of the story, as there will also be warnings from the browser.

At least from most browsers. In my testing, Opera v12.17 totally ignored Java both in Windows 7 and 8.1. Not only did it fail to run applets, it also produced no errors or warnings.

VERY HIGH SECURITY IS BROKEN

On the "very high" security level, no unsigned applets are allowed to run. Or rather, that's what Oracle says.

Specifically, as shown below for Java 8, they say "Only Java applications identified by a certificate from a trusted authority are allowed to run, and only if the certificate can be verified as not revoked".

But, this does not work.

I was able to run the unsigned applet on my JavaTester.org site, on Windows 7, with both Java 7 and 8. I tested with Firefox 33 and Chrome 38.

Sometimes these things need a re-boot before kicking in, but that wasn't the case here. After restarting Windows, my applet was still able to run.

Way to go Oracle.


JAVA EXPIRING

In December 2012 Oracle introduced the concept of the Java runtime (a.k.a. JRE and JVM) expiring. As a security measure, each version since Java 7 Update 10 has had an expiration date. Actually, two dates.

The shorter expiration date is roughly three months after the Java Update was released. However, computers that can not phone home to Oracle, have their versions of Java expire in four months.

As Oracle describes this

The JRE relies on periodic checks with an Oracle Server to determine if it (the JRE) is still considered up-to-date with all the available security fixes (above the security baseline). In the past, if the JRE was unable to contact the Oracle Server, it continued to behave as though it is still the most recent version with regard to security, for an indefinite period. To avoid this ... all JREs will contain a hard-coded expiration date... JREs that are unable to contact Oracle Servers for an extended period of time, will now start offering additional protection after a reasonable period, and will not continue to behave as if they were still up-to-date with security fixes.

The "additional protection" is, yet another, warning message.

Java 7 Update 60 was scheduled to expire on July 15, 2014 if it could phone home, and on August 15, 2014 if it could not. Despite this, in October 2014 I was able to run an unsigned applet on a Windows system with Update 60 installed (the security level was "high").

As shown below, there was a warning about Java being "out of date" but the applet ran nonetheless.

java.outdated.620w

The best thing about iOS, Android and Chrome OS may be that they don't support the use of Java inside a web browser.

Michael Horowitz is an independent consultant who has long been focused on Defensive Computing.

Copyright © 2014 IDG Communications, Inc.