JDK-8234611 : Could UnsatisfiedLinkError get thrown for SunEC provider
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8,11,14
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2019-11-22
  • Updated: 2019-12-06
  • Resolved: 2019-12-06
Related Reports
Relates :  
Description
In JDK-8233954, it is reported that a test case could throw UnsatisfiedLinkError in JDK 11.0.5.  I cannot reproduce this Error message with JDK 11.0.1,  11.0.5 and JDK 14 repository code.  It would be nice if we could make further evaluation if it is really possible to throw UnsatisfiedLinkError when using SunEC provider algorithms, for example KeyPairGenerator.

UnsatisfiedLinkError stack described in JDK-8233954:
Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.security.ec.ECKeyPairGenerator.isCurveSupported([B)Z
at jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator.isCurveSupported(Native Method)
at jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator.ensureCurveIsSupported(ECKeyPairGenerator.java:135)
at jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator.initialize(ECKeyPairGenerator.java:114)
at java.base/java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:699)
at java.base/sun.security.ssl.ECDHKeyExchange$ECDHEPossession.<init>(ECDHKeyExchange.java:112)
at java.base/sun.security.ssl.SSLKeyExchange$T13KeyAgreement.createPossession(SSLKeyExchange.java:575)
at java.base/sun.security.ssl.SSLKeyExchange.createPossessions(SSLKeyExchange.java:88)
at java.base/sun.security.ssl.KeyShareExtension$CHKeyShareProducer.produce(KeyShareExtension.java:263)
at java.base/sun.security.ssl.SSLExtension.produce(SSLExtension.java:532)
at java.base/sun.security.ssl.SSLExtensions.produce(SSLExtensions.java:249)
at java.base/sun.security.ssl.ClientHello$ClientHelloKickstartProducer.produce(ClientHello.java:648)
at java.base/sun.security.ssl.SSLHandshake.kickstart(SSLHandshake.java:515)
at java.base/sun.security.ssl.ClientHandshakeContext.kickstart(ClientHandshakeContext.java:107)
at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:228)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:168)
at com.example.NoEcTest.main(NoEcTest.java:13) 

Steps to reproduce the issue, described in JDK-8233954:
1) Install Oracle JDK 11.0.5 on Windows
2) Remove sunec.dll
3) Try to establish a TLS connection 

Test code, described in JDK-8233954:
package com.example;

import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;

public class NoEcTest {

  public static void main(String[] args) throws IOException {
    URL url = new URL("https://example.com/");
    HttpURLConnection con = (HttpURLConnection) url.openConnection();
    con.setRequestMethod("GET");
    con.connect();
    System.out.println(con.getResponseCode());
  }
} 

Comments
The sunec.dll could be removed from $JAVA_HOME/bin, but if it is existing in somewhere else in the java library path, it still can be loaded. And then the detection code in the SunEC provider does not work as expected (System.loadLibrary("sunec") in SunEC.java): System.loadLibrary("sunec"); // check for native library I'm not sure, there might be a solution to have the detection code more accuracy. But it may not worthy as sunec.dll is not expected to be in anywhere in the system if it is not allowed to use. Close the bug for now.
06-12-2019