与 Java 8 更新 162 及更早版本一起使用的小程序不适用于更新 171 和 172答案

【问题标题】：Applet working with Java 8 update 162 and older doesn't work with update 171 and 172与 Java 8 更新 162 及更早版本一起使用的小程序不适用于更新 171 和 172
【发布时间】：2018-04-19 09:52:37
【问题描述】：

在 Internet Explorer 中使用 Java 8 更新 162 及更早版本时，小程序会按预期加载和工作。删除 Java 8 更新 162 并安装 Java 8 更新 171 或 172 时，小程序错误，ClassNotFoundException 引用了code attribute of the applet tag 中列出的类。我在171 或172 发行说明或171 或172 错误修复中看不到任何原因。我使用的是 Windows 10 专业版 1709 版本 16299.371。小程序使用受信任且仍然有效的证书进行签名。异常站点列表中没有任何异常，并且为此站点添加异常（在 Java 8u162 上没有异常也可以正常工作）仍然显示异常。使用 Java 8 更新 162 及更早版本仍在另一台 PC 上运行。

在清除 Java 配置中的应用程序缓存时，小程序的 JAR 文件不会再次出现在缓存中。

您是否知道 Java 8u171 或 172 中影响小程序的任何更改？你有什么解决这个问题的建议吗？

更新 1：我知道小程序在 Java 9 中已被弃用，小程序在 Firefox 和 Chrome 中不起作用，但在 Internet Explorer 中是这样。

更新 2：我也知道 3DES 密码套件已在更新到 171 和 172 时被禁用，但当前摘要算法是 SHA-256，签名算法是 SHA256withRSA一个 2048 位的密钥，与签名证书的签名算法和密钥相匹配。我什至尝试使用 Java 8 Update 172 对小程序进行签名，而无需更改 java.security 以删除 3DES_EDE_CBC 并使用该版本 ClassNotFoundException 仍按预期保留。

更新 3：当使用 Fiddler 4 或 Charles 作为 Internet Explorer 的代理并捕获服务器和浏览器之间的流量时，小程序会按预期加载和工作。 Java SE Runtime Environment 8 Update 172 和 Java Plug-in 11.172.2 附加组件均设置为在所有站点上允许。当我使用 Java 控制面板中的 Java 缓存查看器从资源缓存中清除小程序时，如果没有代理，小程序不会再次下载到缓存中，但如果我再次使用代理，它会下载到缓存中。我的猜测是代理流量被视为本地流量，因此具有不同的权限。任何其他想法或可能是什么权限？

更新 4：在 Java 控制面板中启用调试选项会导致显示完整的堆栈跟踪，其中 CODE_ATTRIBUTE_VALUE 是我在小程序标记的代码属性上设置的值。即使我在存档属性中列出了小程序的 JAR 文件，它似乎也没有下载。

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)

Java 控制台现在还显示有关连接的更多详细信息，我看到以下原因：

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

目前，小程序使用 IIS 托管在 Windows Server 2003 上。将其移至 Windows Server 2008 也使用 IIS 会导致该问题消失。 Laitinen 先生是对的，TLS 连接使用的是 3DES_EDE_CBC。

【问题讨论】：

Why applets in JDK 9 are deprecated?的可能重复
@ElarbiMohamedAymen 不是重复的。这是 Java 8 和 Internet Explorer。它仍然在 Java 8 update 162 中运行，但不是 Java 8 update 171。是的，小程序几乎不能在所有其他浏览器中运行。
确切的例外是什么？在 8_172 中，java.applet.Applet 类仍在 rt.jar 中。
请发布完整的例外情况
您在 32 位/64 位 JRE 中看到过这个问题吗？你有任何具体的用例来证明这个问题吗？

标签： java applet

【解决方案1】：

JAVA_HOME\lib\security\java.security

更新 171 将 3DES_EDE_CBC 添加到禁用算法列表 (jdk.tls.disabledAlgorithms)。删除它，您的小程序将再次运行。

【讨论】：

谢谢你，但使用的算法不是 3DES_EDE_CBC。我已经更新了我的答案，提供了详细信息。
对不起，你是对的。我编辑了错误的java.security。 TLS 连接使用 3DES_EDE_CBC。

【解决方案2】：

面临同样的问题，归结为更新 171 不再支持 TLS 1.0。

我们的网络服务器很旧，仅支持 TLS 1.0，因此 Applet 下载失败，这可以在 Java 控制台中看到，连接正在关闭。

升级了网络服务器以支持 TLS 1.2，一切都恢复正常了。

【讨论】：