2

When using Java 8 update 162 and older in Internet Explorer, the applet loads and works as expected. When removing Java 8 update 162 and install Java 8 update 171 or 172, the applet errors with ClassNotFoundException referencing the class listed in the code attribute of the applet tag. I don't see any reason for this in the 171 or 172 release notes or the 171 or 172 bug fixes. I'm using Windows 10 Pro version 1709 build 16299.371. The applet is signed with a certificate that is trusted and still valid. There aren't any exceptions in the Exception Site List and adding an exception for this site (it worked fine without one on Java 8u162) still displays the exception. Using Java 8 update 162 and older is still working on another PC.

When clearing the Application cache in the Java configuration, the applet's JAR file doesn't appear again in the cache.

Are you aware of any changes in Java 8u171 or 172 that affect applets? Do you have any suggestions to resolve this?

Update 1: I'm aware that applets are deprecated in Java 9 and that applets don't work in Firefox and Chrome, but this is in Internet Explorer.

Update 2: I'm also aware that the 3DES Cipher Suites have been disabled in the update to 171 and 172, but the current digest algorithm is SHA-256 and the signature algorithm is SHA256withRSA with a 2048-bit key, which matches the signing certificate's signature algorithm and key. I've even tried signing the applet using Java 8 Update 172 without altering java.security to remove 3DES_EDE_CBC and using that version the ClassNotFoundException still persists as expected.

Update 3: When using Fiddler 4 or Charles as a proxy for Internet Explorer and capturing traffic between the server and the browser, the applet loads and works as expected. Both the Java SE Runtime Environment 8 Update 172 and Java Plug-in 11.172.2 Add-ons are set to Allow on all sites. When I clear the applet from the Resources cache using the Java Cache Viewer in the Java Control Panel, the applet doesn't download in the cache again without the proxy, but if I use a proxy again then it does download into the cache. My guess is that the proxy traffic is being treated as local and so has different permissions. Any other ideas or what permissions it could be?

Update 4: Enabling the debugging options in the Java Control Panel causes the full stack trace to show, where CODE_ATTRIBUTE_VALUE is the value I set on the code attribute of the applet tag. The applet's JAR file doesn't seem to be downloading even though I list it in the archive attribute.

java.lang.ClassNotFoundException: CODE_ATTRIBUTE_VALUE
  at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
  at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
  at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
  at java.lang.Thread.run(Unknown Source)

The Java Console now also shows more details about the connection and I see the following which is the cause:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
  at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
  at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
  at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
  at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
  at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
  at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
  at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
  at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
  at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
  at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
  at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
  at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
  at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
  at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
  at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
  at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$900(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
  at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
  at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
  at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
  at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
  at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
  at sun.security.ssl.InputRecord.read(Unknown Source)
  ... 40 more

Currently the applet is hosted on Windows Server 2003 using IIS. Moving it to Windows Server 2008 also using IIS causes that problem to go away. Mr. Laitinen was right the TLS connection was using 3DES_EDE_CBC.

WhiteKnight
  • 4,938
  • 5
  • 37
  • 41
  • Possible duplicate of [Why applets in JDK 9 are deprecated?](https://stackoverflow.com/questions/45535112/why-applets-in-jdk-9-are-deprecated) – Elarbi Mohamed Aymen Apr 19 '18 at 09:56
  • @ElarbiMohamedAymen Not a duplicate. This is Java 8 and Internet Explorer. It is still working in Java 8 update 162, but not Java 8 update 171. Yes applets don't work in almost every other browser. – WhiteKnight Apr 19 '18 at 10:23
  • what is the exact exception? in 8_172 the java.applet.Applet class is still in rt.jar. – P.J.Meisch Apr 19 '18 at 12:00
  • Please post the full exception – Mark Rotteveel Apr 19 '18 at 15:41
  • Haveyou seen this issue in 32bit/64 bit JRE? Do you have any specif use case to demonstrate this issue? – Fairoz Apr 20 '18 at 03:23
  • @P.J.Meisch Thank you for trying to help. When selecting the applet, which contains "Error. Click for details" due to the error, a popup is display with Application Error in the title, ClassNotFoundException and the value of the applet HTML tag's code attribute. The Java Console does not provide any further details. I've updated the question with details about the exception. – WhiteKnight Apr 23 '18 at 10:53

2 Answers2

3

JAVA_HOME\lib\security\java.security

Update 171 adds 3DES_EDE_CBC to the list of disabled algorithms (jdk.tls.disabledAlgorithms). Remove it and your applet will work again.

1

Faced the same issue and it comes down to Update 171 no longer supporting TLS 1.0.

Our webserver was old and only supported TLS 1.0 so the download of the Applet was failing and this could be seen in the Java Console, the connection was being closed.

Upgraded the webserver to support TLS 1.2 and it all works again.

NickK
  • 11
  • 1