Optional "sunec" native library of SunEC provider becomes mandatory when using SVM #951
Comments
fcurts
changed the title
|
Update: After removing the SunEC provider from the 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 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. |
|
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: |
|
Update 3: The solution we've settled on for now is to remove the SunEC provider from the 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. |
|
Great info in your 3 updates thanks for the learnings, i've settled on adding BouncyCastle as a provider, and removing SunEC both via 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 |
|
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. |
|
Is there a way to disable SunEC without editing the java.security file? |
|
My approach above doesn’t edit the file, overrides by environment variable? Other than that I don’t think so |
|
@nhoughto That repository appears to have disappeared :) I'm passing |
|
Starting from an app that works (if it has libsunec.so, at least), with I tried both 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 @nhoughto Which version of GraalVM are you trying this with? |
|
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 👍🏼 |
|
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 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. |
|
WELP! That was it. (The relative path thing.) |
|
@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: |
|
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 |
|
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: ... and both dependencies are added in all cases (lein syntax): I am strictly modifying
Next up, I'll try modifying the code itself to not just consistently do |
|
Note that 3=bcprov advertises ECDHE support but it doesn't actually work: |
|
More tests! The name columns is "overrides+injects". Overrides are statements in java.security.overrides. Injects are parsed as follows: if there's an I have to leave to catch a train but I'll post some analysis later.
|
|
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. |
|
@lvh I am very interested in the solution to replace the ECC. |
|
@rtfpessoa My new ticket is ... not quite 1337. (#1336.) You should probably subscribe to that one :) |
|
What about using https://github.com/google/conscrypt to handle all SSL? |
|
That uses a native library too doesn’t it? boring ssl isn’t java..?
…On 15 Jun 2019, 10:11 PM +1000, Yuri Schimke ***@***.***>, wrote:
What about using https://github.com/google/conscrypt to handle all SSL?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes, it's included in the conscrypt dependency however. Not sure if that just works... |
|
Damn... |
|
I'm also having this same issue as soon as I try to access any HTTPS endpoint. Running binary generated by native-image. |
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.
|
@lvh n.b. you have a typo "bouncycaste", not sure if that is just here or in the config file |
|
Obsolete now that libsunec.so is statically linked. |
|
I have an issue with Could you help me please? |
The SunEC provider has an optional
sunecnative library that provides additional algorithms.We do not want to ship the
sunecnative 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:The error is preceded by the following warning:
We've tried several workarounds. The only one that worked is (code is in Kotlin):
Here,
System.loadLibrary("sunec")prevents theUnsatisfiedLinkError(although we don't know why), and disabling logging prevents the warning.The only usage of method
generateECKeyPairin our project is incom.oracle.svm.hosted.SecurityServicesFeature, line 133:We think this might be related to the issue we are seeing.
GraalVM CE 1.0.0-rc11, macOS 10.14.2
The text was updated successfully, but these errors were encountered: