Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional "sunec" native library of SunEC provider becomes mandatory when using SVM #951

Open
fcurts opened this issue Feb 1, 2019 · 27 comments

Comments

@fcurts
Copy link

commented Feb 1, 2019

The SunEC provider has an optional sunec native library that provides additional algorithms.

We do not want to ship the sunec native library with our native executable due to licensing and packaging concerns. However, not providing this library gives the following runtime error when opening an HTTPS connection:

Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[Ljava/lang/Object; [symbol: Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair or Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair__I_3B_3B]
	at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:145)
	at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:54)
	at sun.security.ec.ECKeyPairGenerator.generateECKeyPair(ECKeyPairGenerator.java)
	at sun.security.ec.ECKeyPairGenerator.generateKeyPair(ECKeyPairGenerator.java:128)
	at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:703)
	at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:78)
	at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:783)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:302)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
	at java.net.URL.openStream(URL.java:1045)

The error is preceded by the following warning:

WARNING: The sunec native library, required by the SunEC provider, could not be loaded. This library is usually shipped as part of the JDK and can be found under <JAVA_HOME>/jre/lib/<platform>/libsunec.so. It is loaded at run time via System.loadLibrary("sunec"), the first time services from SunEC are accessed. To use this provider's services the java.library.path system property needs to be set accordingly to point to a location that contains libsunec.so. Note that if java.library.path is not set it defaults to the current working directory.

We've tried several workarounds. The only one that worked is (code is in Kotlin):

class MyFeature: Feature {
  override fun duringSetup(access: DuringSetupAccess) {
    System.loadLibrary("sunec")

    Log.setLog(object : RealLog() {
      override fun string(value: String?): Log = this
      override fun newline(): Log = this
    })
  }
}

Here, System.loadLibrary("sunec") prevents the UnsatisfiedLinkError (although we don't know why), and disabling logging prevents the warning.

The only usage of method generateECKeyPair in our project is in com.oracle.svm.hosted.SecurityServicesFeature, line 133:

JNIRuntimeAccess.register(sun.security.ec.ECKeyPairGenerator.class.getDeclaredMethod("generateECKeyPair", int.class, byte[].class, byte[].class));

We think this might be related to the issue we are seeing.

GraalVM CE 1.0.0-rc11, macOS 10.14.2

@fcurts fcurts changed the title Optional "sunec" native library of Sun JCE provider becomes mandatory when using SVM Optional "sunec" native library of SunEC provider becomes mandatory when using SVM Feb 1, 2019

@cstancu cstancu self-assigned this Feb 1, 2019

@cstancu cstancu added the native-image label Feb 1, 2019

@fcurts

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

Update:

After removing the SunEC provider from the java.security file, the following code reports the same ciphers as before. Hence I'm not sure how useful "SunEC without native library" is.

println(java.util.Arrays.toString(
      (javax.net.ssl.SSLSocketFactory.getDefault() as javax.net.ssl.SSLSocketFactory).supportedCipherSuites))

We've also managed to get Bouncy Castle to work by removing the SunEC provider from the java.security file, adding Security.addProvider(BouncyCastleProvider()) to our SVM feature (registering it in the java.security file had no effect), and setting the following native-image options:

--rerun-class-initialization-at-runtime=org.bouncycastle.crypto.prng.SP800SecureRandom
--rerun-class-initialization-at-runtime=org.bouncycastle.jcajce.provider.drbg.DRBG$Default
--rerun-class-initialization-at-runtime=org.bouncycastle.jcajce.provider.drbg.DRBG$NonceAndIV

With this in place, significantly more ciphers are reported at runtime, including the ECC ones. However, it adds 15 MB to the size of our executable, which is too much.

@fcurts

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

Update 2:

I was able to get the provider list down to the following, but unfortunately it doesn't reduce binary size compared to the baseline without Bouncy Castle:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
@fcurts

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

Update 3:

The solution we've settled on for now is to remove the SunEC provider from the java.security file. In this case, none of the mentioned workarounds is necessary, and HTTPS still works for us.

If there was a way to get ECC ciphers back without shipping a separate library or significantly increasing binary size, we'd love to hear about it.

@nhoughto

This comment has been minimized.

Copy link

commented Mar 17, 2019

Great info in your 3 updates thanks for the learnings, i've settled on adding BouncyCastle as a provider, and removing SunEC both via java.security, doing it via Security.addProvider/removeProvider doesn't appear to work in SVM.

This results in a binary that doesn't require a native library and can't still do HTTPS.

I did still need to set JVM args to the path of cacerts as per #768 which feels really weird as at the point of having a native image, you don't really think about needing a JRE anymore, and cacerts is something that ships with the JRE, ideally it would just use /etc/ssl/certs/ directly, like everything else..

@nhoughto

This comment has been minimized.

Copy link

commented May 10, 2019

My own update since rediscovering this, SunEC can be replaced with BC fairly easily like this:

https://github.com/bsycorp/make-jks/blob/master/java.security.overrides

Its a bit fragile but works.

@lvh

This comment has been minimized.

Copy link

commented May 14, 2019

Is there a way to disable SunEC without editing the java.security file?

@nhoughto

This comment has been minimized.

Copy link

commented May 14, 2019

My approach above doesn’t edit the file, overrides by environment variable? Other than that I don’t think so

@lvh

This comment has been minimized.

Copy link

commented May 15, 2019

@nhoughto That repository appears to have disappeared :) I'm passing -Dsecurity.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider to native-image directly, which feels like it should be equivalent to what you're doing, but doesn't work: I get the same SunEC error when I run the resulting application.

@lvh

This comment has been minimized.

Copy link

commented May 15, 2019

Starting from an app that works (if it has libsunec.so, at least), with [org.bouncycastle/bcprov-jdk15on "1.61"] on the classpath, All tests are with graalvm-19.0.0 with the following options:

["--verbose" "--no-fallback" "-Dclojure.compiler.direct-linking=true" "-H:+ReportExceptionStackTraces"  "--report-unsupported-elements-at-runtime" "--initialize-at-build-time"  "--enable-https"]

I tried both security.provider.3=sun.security.ec.SunEC and security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider and both commented (so there's no provider 3) and they all have exactly the same behavior: at runtime, the app tries to load SunEC and fails. I have also tried adding -Dsecurity.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider and leaving java.security unchanged, which feels like it should be identical to what @nhoughto is doing, but that similarly appears to have no effect.

My best bet is that between -rc11 and 19.0.0, something changed in GraalVM in the handling of the provider, requiring it even if it's unset in jre/lib/security/java.security.

@nhoughto Which version of GraalVM are you trying this with?

@nhoughto

This comment has been minimized.

Copy link

commented May 15, 2019

1.0.0-rc16, I’ll try with 19.0.0.

I moved the repo sorry, it’s here now:

https://github.com/bsycorp/make-jks/blob/master/java.security.overrides

Graal options here:

https://github.com/bsycorp/make-jks/blob/master/build.gradle

I’m not sure you are setting environment variables properly, you can’t override sunec from jvm args directly, but you can set an argument to a file that has overrides. So likely that’s why your still using sunec. Copy the approach from makejks and it will work I reckon 👍🏼

@lvh

This comment has been minimized.

Copy link

commented May 16, 2019

Ah, IIUC the distinction is that -J-D... means the -D is passed to the JVM running the image generator, not the resulting image, which makes sense. That said, I'd expect -J-D without an override file to do the same thing as with; but just for experimentation's sake I did -J-Djava.security.properties=java.security.overrides with security.provider.3=org.bouncycaste.jce.provider.BouncyCastleProvider in that file, and got the same result.

Next up, I'll try using native-image directly instead of the lein plugin, just in case the problem is the relative path for the build server JVM.

@lvh

This comment has been minimized.

Copy link

commented May 16, 2019

WELP! That was it. (The relative path thing.)

@lvh

This comment has been minimized.

Copy link

commented May 17, 2019

@nhoughto OK, we're still not done. How (if at all) did you check that the provider in question is actually enabled? I first figured something was up because while the overrides trick produced a binary that didn't require libsunec (so it did _something), once I observed the traffic with Wireshark and saw only DHE and RSA ciphersuites were available even though BoucyCastle is supposed to support ECDHE. Calling Security.getProviders at runtime confirmed the suspicion that the BouncyCastle provider wasn't really being used at all.

Neither org.bouncycastle.jsse.provider.BouncyCastleJsseProvider nor org.bouncycaste.jce.provider.BouncyCastleProvider shows up as a provider in the runtime if I set it via overrides. I have included the following dependencies:

                                     [org.bouncycastle/bcprov-jdk15on "1.61"]
                                     [org.bouncycastle/bctls-jdk15on "1.61"]
@nhoughto

This comment has been minimized.

Copy link

commented May 17, 2019

Hmm so I’m explicitly adding the provider in my code, as well as disabling sunec via overrides. I haven’t dug deep into what cipher suites are available and what aren’t. Without the BC change makejks couldn’t process ECC certificates only RSA, it would fail to load sunec. With the BC change, static block, overrides and reinit options, ECC certs work as expected.

https://github.com/bsycorp/make-jks/blob/master/src/main/java/com/bsycorp/makejks/Main.java

@lvh

This comment has been minimized.

Copy link

commented May 23, 2019

I've written some test harnesses to test this a little more systematically. Firstly, I wrote nscap, a tool to take a piece of code and run it in a Linux network namespace together with tcpdump. This enables me to capture just the packets from 1 process. I then analyze the resulting dumps with ssldump to see what TLS conversations actually take place.

In my code, I'm explicitly adding both providers in all cases:

(Security/addProvider (BouncyCastleProvider.))
(Security/addProvider (BouncyCastleJsseProvider.))

... and both dependencies are added in all cases (lein syntax):

[org.bouncycastle/bcprov-jdk15on "1.61"]
[org.bouncycastle/bctls-jdk15on "1.61"]

I am strictly modifying java.security.overrides and got the following results:

name SunEC warning? SunEC idx BC idx BCJSSE idx Best supported handshake
nothing ✔️ 3 10 11
3=bcprov 9 10 ECDHE
3=bctls 9 10
3=bcprov&4=bctls 8 9
3=empty 3 4
3=nil 9 10

Next up, I'll try modifying the code itself to not just consistently do addProvider.

@lvh

This comment has been minimized.

Copy link

commented May 23, 2019

Note that 3=bcprov advertises ECDHE support but it doesn't actually work:

Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1903)
	at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1886)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1402)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
	at clj_http.lite.core$request.invokeStatic(core.clj:76)
	at clj_http.lite.core$request.invoke(core.clj:42)
	at clojure.lang.Var.invoke(Var.java:381)
	at clj_http.lite.client$wrap_query_params$fn__448.invoke(client.clj:166)
	at clj_http.lite.client$wrap_user_info$fn__458.invoke(client.clj:190)
	at clj_http.lite.client$wrap_url$fn__475.invoke(client.clj:212)
	at clj_http.lite.client$wrap_redirects$fn__392.invoke(client.clj:46)
	at clj_http.lite.client$wrap_decompression$fn__399.invoke(client.clj:62)
	at clj_http.lite.client$wrap_input_coercion$fn__414.invoke(client.clj:114)
	at clj_http.lite.client$wrap_output_coercion$fn__405.invoke(client.clj:71)
	at clj_http.lite.client$wrap_exceptions$fn__385.invoke(client.clj:32)
	at clj_http.lite.client$wrap_basic_auth$fn__453.invoke(client.clj:180)
	at clj_http.lite.client$wrap_accept$fn__426.invoke(client.clj:134)
	at clj_http.lite.client$wrap_accept_encoding$fn__432.invoke(client.clj:145)
	at clj_http.lite.client$wrap_content_type$fn__421.invoke(client.clj:126)
	at clj_http.lite.client$wrap_form_params$fn__470.invoke(client.clj:207)
	at clj_http.lite.client$wrap_method$fn__465.invoke(client.clj:195)
	at clj_http.lite.client$wrap_unknown_host$fn__480.invoke(client.clj:218)
	at clj_http.lite.client$get.invokeStatic(client.clj:271)
	at clj_http.lite.client$get.doInvoke(client.clj:268)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at transgressor.client$_main.invokeStatic(client.cljc:33)
	at transgressor.client$_main.doInvoke(client.cljc:29)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at transgressor.client.main(Unknown Source)
Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
	at sun.security.util.ECUtil.getECParameters(ECUtil.java:100)
	at sun.security.util.ECUtil.getECParameterSpec(ECUtil.java:149)
	at sun.security.ssl.JsseJce.getECParameterSpec(JsseJce.java:373)
	at sun.security.ssl.HandshakeMessage$ECDH_ServerKeyExchange.<init>(HandshakeMessage.java:1066)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:300)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	... 31 more
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
	at java.security.Provider$Service.newInstance(Provider.java:1621)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
	at java.security.Security.getImpl(Security.java:695)
	at java.security.AlgorithmParameters.getInstance(AlgorithmParameters.java:146)
	at sun.security.util.ECUtil.getECParameters(ECUtil.java:98)
	... 40 more
Caused by: java.lang.NoSuchMethodException: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi.<init>
	at java.lang.Class.getConstructor0(DynamicHub.java:3082)
	at java.lang.Class.getConstructor(DynamicHub.java:1825)
	at java.security.Provider$Service.newInstance(Provider.java:1594)
	... 45 more
@lvh

This comment has been minimized.

Copy link

commented May 24, 2019

More tests!

The name columns is "overrides+injects". Overrides are statements in java.security.overrides. Injects are parsed as follows: if there's an addbcprov, the code includes (Security/addProvider (BouncyCastleProvider.)), if there's an addbctls, the code includes (Security/addProvider (BouncyCastleJsseProvider.)).

I have to leave to catch a train but I'll post some analysis later.

name SunEC warning? SunEC idx BC idx BCJSSE idx Best advertised handshake Client -> server records Server -> client records Runtime exception
nooverrides+noinjects ⚠️ 3 🚫 🚫 💥 💥 💥
nooverrides+addbcprov ⚠️ 3 10 🚫 ECDHE 1 4
nooverrides+addbctls ⚠️ 3 🚫 10 ECDHE 1 💥
nooverrides+addbcprov&addbctls ⚠️ 3 10 11 ECDHE 2 4
3=bcprov+noinjects 🚫 🚫 🚫 DHE 1 💥
3=bcprov+addbcprov 🚫 9 🚫 ECDHE 1 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
3=bcprov+addbctls 🚫 🚫 9 💥 💥 💥
3=bcprov+addbcprov&addbctls 🚫 9 10 ECDHE 1 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
3=bctls+noinjects 🚫 🚫 🚫 DHE 1 4
3=bctls+addbcprov 🚫 9 🚫 💥 💥 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
3=bctls+addbctls 🚫 🚫 9 💥 💥 💥
3=bctls+addbcprov&addbctls 🚫 9 10 ECDHE 1 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
3=bcprov&4=bctls+noinjects 🚫 3 🚫 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Default SSLContext not available
3=bcprov&4=bctls+addbcprov 🚫 8 🚫 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Default SSLContext not available
3=bcprov&4=bctls+addbctls 🚫 🚫 8 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Unable to invoke creator for DEFAULT: Default key/trust managers unavailable
3=bcprov&4=bctls+addbcprov&addbctls 🚫 8 9 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Unable to invoke creator for DEFAULT: Default key/trust managers unavailable
3=empty+noinjects 🚫 🚫 🚫 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Default SSLContext not available
3=empty+addbcprov 🚫 3 🚫 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Default SSLContext not available
3=empty+addbctls 🚫 🚫 3 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Unable to invoke creator for DEFAULT: Default key/trust managers unavailable
3=empty+addbcprov&addbctls 🚫 3 4 💥 💥 💥 Caused by: java.security.NoSuchAlgorithmException: Unable to invoke creator for DEFAULT: Default key/trust managers unavailable
3=nil+noinjects 🚫 🚫 🚫 DHE 1 4
3=nil+addbcprov 🚫 9 🚫 ECDHE 1 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
3=nil+addbctls 🚫 🚫 9 DHE 1 💥
3=nil+addbcprov&addbctls 🚫 9 10 ECDHE 1 💥 Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: EC, provider: BC, class: org.bouncycastle.jcajce.provider.asymmetric.ec.AlgorithmParametersSpi)
@lvh

This comment has been minimized.

Copy link

commented May 24, 2019

I feel kind of self-conscious that I'm hijacking this ticket. This ticket is about SunEC becoming mandatory. It seems like a clear resolution is an override that replaces security provider #3 with any old nonsense value, effectively disabling SunEC, is an easy and functional workaround, if you can accept not having ECC. The secondary goal that I'm pursuing is re-enabling ECC, in this case using BouncyCastle (but BouncyCastle is incidental to the problem; if we could use [conscrypt][conscrypt] that would arguably be much better, but it relies on native code and is therefore presumably much harder to get working in SubstrateVM, presumably you'd need something like... System.loadLibrary but implemented against... LLVM with Sulong? That seems like a semantically valid sentence but very far away from reality today :-))

In conclusion, I feel like this ticket can be resolved (There's a workaround! There's a clear way to apply it!) and I should file a new ticket about getting BouncyCastle's JCA provider to work on SubstrateVM.

@rtfpessoa

This comment has been minimized.

Copy link

commented May 25, 2019

@lvh I am very interested in the solution to replace the ECC.
I had my go to it a few months ago, but failed miserably / quit since I could live without it for the time being.

@lvh

This comment has been minimized.

Copy link

commented May 26, 2019

@rtfpessoa My new ticket is ... not quite 1337. (#1336.) You should probably subscribe to that one :)

@yschimke

This comment has been minimized.

Copy link

commented Jun 15, 2019

What about using https://github.com/google/conscrypt to handle all SSL?

@nhoughto

This comment has been minimized.

Copy link

commented Jun 15, 2019

@yschimke

This comment has been minimized.

Copy link

commented Jun 15, 2019

Yes, it's included in the conscrypt dependency however. Not sure if that just works...

@yschimke

This comment has been minimized.

Copy link

commented Jun 15, 2019

Damn...

Exception in thread "main" java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-osx-x86_64 in java.library.path
	at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibrary(NativeLibrarySupport.java:118)
	at java.lang.ClassLoader.loadLibrary(Target_java_lang_ClassLoader.java:126)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.Runtime.loadLibrary(Runtime.java:240)
	at java.lang.System.loadLibrary(System.java:365)
	at org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
	at org.conscrypt.NativeLibraryLoader.loadLibraryFromCurrentClassloader(NativeLibraryLoader.java:318)
	at org.conscrypt.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:273)
	at org.conscrypt.NativeLibraryLoader.load(NativeLibraryLoader.java:162)
	at org.conscrypt.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:106)
	at org.conscrypt.NativeCryptoJni.init(NativeCryptoJni.java:50)
	at org.conscrypt.NativeCrypto.<clinit>(NativeCrypto.java:63)
	at com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:347)
	at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:267)
	at java.lang.Class.ensureInitialized(DynamicHub.java:437)
	at org.conscrypt.OpenSSLProvider.<init>(OpenSSLProvider.java:58)
	at org.conscrypt.Conscrypt$ProviderBuilder.build(Conscrypt.java:174)
	at okhttp3.curl.Main.main(Main.java:71)
@luisnuxx

This comment has been minimized.

Copy link

commented Jun 21, 2019

I'm also having this same issue as soon as I try to access any HTTPS endpoint.

Running binary generated by native-image.
OS: CentOS 7

WARNING: The sunec native library, required by the SunEC provider, could not be loaded. This library is usually shipped as part of the JDK and can be found under <JAVA_HOME>/jre/lib/<platform>/libsunec.so. It is loaded at run time via System.loadLibrary("sunec"), the first time services from SunEC are accessed. To use this provider's services the java.library.path system property needs to be set accordingly to point to a location that contains libsunec.so. Note that if java.library.path is not set it defaults to the current working directory.
java.lang.UnsatisfiedLinkError: sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[Ljava/lang/Object; [symbol: Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair or Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair__I_3B_3B]
	at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:145)
	at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:57)
	at sun.security.ec.ECKeyPairGenerator.generateECKeyPair(ECKeyPairGenerator.java)
	at sun.security.ec.ECKeyPairGenerator.generateKeyPair(ECKeyPairGenerator.java:128)
	at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:703)
	at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:78)
	at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:783)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:302)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)

rmaucher added a commit to apache/tomcat that referenced this issue Jul 10, 2019

Add https (no TLS without it) to the command line
TLS doesn't really work though
(oracle/graal#951 and
oracle/graal#1336).
Also Tomcat Native fails to load with an initial JNI error.
Update some version numbers.
@yschimke

This comment has been minimized.

Copy link

commented Jul 19, 2019

@lvh n.b. you have a typo "bouncycaste", not sure if that is just here or in the config file

@lvh

This comment has been minimized.

Copy link

commented Jul 19, 2019

@yschimke I did orginally have that problem but I've since resolved it :) The most recent table should be accurate (as is #1336).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
7 participants
You can’t perform that action at this time.