]
Ingo Weiss updated WFLY-13061:
------------------------------
Workaround Description: (was: The customer has temporarily worked around it by
manually patching their version of bouncy castle, but they have a client that requires the
delivery to use all supported JBoss EAP components.)
Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and
Java 11.0.5
-----------------------------------------------------------------------------
Key: WFLY-13061
URL:
https://issues.redhat.com/browse/WFLY-13061
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 19.0.0.Beta2
Reporter: Ingo Weiss
Assignee: Bartosz Baranowski
Priority: Major
Labels: bouncycastle, java11, picketlink
Attachments: PSSSignatureSpi.java
Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There
is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash
due to a missing null pointer check. The issue is patched upstream, and they would like
the patch applied to the version we release with JBoss EAP.
The attached java file is the file from Bouncy castle 1.60 with the upstream patch
applied so it can be compared to the originaly version
Their complete report:
{quote}
This results in BC implementations of various crypto algorithms being used, e.g., for TLS
connections.
Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta
1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used.
This key exchange mechanism requires the data transferred between the peers to be signed
using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check
during its initialization phase.
The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in
OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed
JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a
number of JDK security fixes. I also strongly believe that BC instead of the JDK is the
right place to resolve the defect.
An issue has been opened with BC in [4] which has resulted in a merged pull request in
[5], but since there is no ETA on a release of BC that will incorporate this fix, we need
a viable interim solution to the problem, otherwise TLS connections with JBoss will not
work in our environment.
I've merged the fix from [5] locally to version 1.60 of the BC provider and
successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my
own patched version of bcprov-jdk15on. Since our client insists on an official solution
from Red Hat, I'd like to know if you could build a one-off patch for BC provider for
us. I will attach the changed class
org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this
ticket.
[1]
https://www.bouncycastle.org/java.html
[2]
https://downloads.bouncycastle.org/betas/
[3]
https://bugs.openjdk.java.net/browse/JDK-8216039
[4]
https://github.com/bcgit/bc-java/issues/633
[5]
https://github.com/bcgit/bc-java/pull/632
{quote}