Missing ECDHE Ciphers in 8-jdk-alpine #3002
Assignees
Labels
alpine-linux
Issues that affect or relate to the Alpine LINUX OS
bug
Issues that are problems in the code as reported by the community
Reported to OpenJDK / JBS
Issues that have been reported upstream to the OpenJDK community
testing
Issues that enhance or fix our test suites
Comments
github-actions
bot
added
alpine-linux
|
The list of ciphers seen in the (legacy) adoptopenjdk alpine 8 image shows a fuller set of ciphers (using https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html to list the ciphers): Ubuntu based default AdoptOpenJDK 8 image: Alpine specific AdoptOpenJDK 8 image: |
|
Added to PMC agenda |
|
maybe related to this one alpinelinux/aports#1697 |
karianna
added
the
bug
|
build team will look into this. |
|
The ciphers are also missing in the newly created alpine image (JDK8u342). |
|
I was wondering if there is any update to this request and, if possible, any potential ETA to provide an Alpine Java 8 version with the mission ciphers? |
|
Thinking out loud. We currently download and integrate the same cipher suite as Mozilla. I'm not sure if ECDHE is supported in that set, that would be my next step for investigation. Will ping the build team |
|
Thank you for the update. Bouncy Castle license is similar to MIT License. The following simple script is adding bouncy castle jar file to JAVA_HOME - resolving the missing ciphers issue. update_bouncy_castle_in_java_security.sh #!/bin/sh if [[ ! -z "${JAVA_HOME}" ]]; then export JAVA_LIB_FOLDER=$JAVA_HOME/lib chmod 777 "$JAVA_SECURITY_FILE" cat "$JAVA_SECURITY_FILE.$$" | awk 'BEGIN{x=0}{if ($1 ~ /^security.provider./) {split($1,c,"=") ; split(c[1],d,".") ; if (d[3]==2) {x=1 ; print "security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider"} ; print "security.provider."d[3]+x"="c[2]} else {print $0}}' > "$JAVA_SECURITY_FILE" export BOUNCY_CASTLE_DOWNLOAD_BASE_URL=https://www.bouncycastle.org/download wget -O $BOUNCY_CASTLE_PATH $BOUNCY_CASTLE_DOWNLOAD_URL |
|
I found that Once I installed the issue went away. |
|
@gdams Could missing adoptium/containers#319 might be related too. |
|
Quite possibly @jerboaa, I'll do some testing |
|
Yup as per @codeseedr's comment: Without With |
|
I guess the question becomes should we ship |
|
probably should move this issue into https://github.com/adoptium/containers to continue discussion. |
Would be something to consider, yes. Or find a way for |
|
To follow the Alpine philosophy, we should try to avoid shipping libgcc :-), hopefully we can fix libsunec.so here. |
|
I used some ugly (but working) hack: When the image itself uses The key to solve the issue may be to check how |
|
https://bugs.openjdk.org/browse/JDK-8306037 is the upstream issue. |
karianna
added
the
Reported to OpenJDK / JBS
perfect solution |
Thank you so much, this is exactly the solution I needed for my situation. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What are you trying to do?
Confirm that JDK 8 termurin alpine image has same set of ciphers as other JDK 8 temurin operating system versions. Seeing SSL handshake errors in code when using latest JDK 8 termurin alpine image that were not seen when using the same code with the older AdoptOpenJDK 8 alpine image.
Expected behaviour:
No SSL handshake errors when relying on ECDHE Ciphers in using an image derived from the JDK 8 termurin alpine image
Expect to see the same list of ciphers in the Alpine 8 JDK image as seen in non-Alpine 8 JDK images.
Observed behaviour:
darkedges reported this issue succinctly in #2963 but decided to close the issue. I've opened this so that the community can find a resolution in the code base.
Any other comments:
The text was updated successfully, but these errors were encountered: