[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Steps to Reproduce: (was: Asked customer for specific configuration information)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13061) [GSS](7.3.z) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss moved JBEAP-18638 to WFLY-13061:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13061 (was: JBEAP-18638)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 19.0.0.Beta2
(was: 7.2.5.GA)
Fix Version/s: (was: 7.3.1.GA)
> [GSS](7.3.z) 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Summary: Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5 (was: [GSS](7.3.z) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2448:
--------------------------------
If you look at the stack trace, that's not the problem. The issue is that {{pingable_mbrs}} is changed during iteration, as iteration goes from {{[0..size-1]}}.
Hmm, this is terrible code and I've been meaning to change it for a long time... I either need to synchronize access to {{pingable_mbrs}}, or make it concurrent. Downside of the latter solution is that we might end up with an incorrect {{ping_dest}}...
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2448:
---------------------------
Comment: was deleted
(was: Hmm, I'm computing {{index+1 % size}}, but when size is 0, this won't work. I guess I'll add a check for isEmpty() and return null in that case...)
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2448:
--------------------------------
Hmm, I'm computing {{index+1 % size}}, but when size is 0, this won't work. I guess I'll add a check for isEmpty() and return null in that case...
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2448:
---------------------------
Fix Version/s: 5.0
4.2.0
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Dan Berindei (Jira)
Dan Berindei created JGRP-2448:
----------------------------------
Summary: FD_SOCK IndexOutOfBoundsException
Key: JGRP-2448
URL: https://issues.redhat.com/browse/JGRP-2448
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.8
Reporter: Dan Berindei
Assignee: Bela Ban
{{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
{noformat}
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:458)
at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
at org.jgroups.util.Util.pickNext(Util.java:2686)
at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months