PROBLEM WITH USING TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and BrainpoolP384r1

--000000000000cebed6059c18c906
Content-Type: text/plain; charset="UTF-8"

Good morning.

I am struggling to enable TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 on my
TLS1.2 client. The suite is provided by 'bctls-jdk15on-164' and used on a
windows10 machine with installed OpenJDK8. Further, is only supported by
the remote mutual authentication is mandatory at the server.
Here the java -version printout
openjdk version "1.8.0_222" OpenJDK Runtime Environment (build
1.8.0_222-b10) Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Windows 10
amd64-64-Bit Compressed References 20190717_421 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431 OMR - ec782f26 JCL - f147086df1e based on jdk8u222-b10)

The issue is, that for some reason SHA256 is selected in the client for
certificate verification rather than SHA384.

An java.lang.IllegalStateException is thrown with the information


HashAlgorithm.sha256(4) is not being tracked

For debugging, complete TLS handshake has been sniffed and I will
provide links to screenshots for the packets of interest further on.

Screenshot: https://i.stack.imgur.com/KpMYP.png

At First the client requests the desired cipher suite which can be seen:

Screenshot: https://i.stack.imgur.com/aFoKG.png

Further in the protocol, the Servers Certificate Request requests
SHA384 (0x0501) as can be seen in:

Screenshot: https://i.stack.imgur.com/jDrco.png

Next the exception is thrown at the client while generating the Certificate
Verify
It looks like the BCJSSE is trying to apply SHA256 for generating this
message instead of the requested SHA384. Since SHA256 is not supported by
the suite, the lib is throwing the exception (see above) resulting in a
breakup.
The server on the other hand is running into an connection timeout.

Remark: For some reason Wireshark is decoding the information in TSL
1.3 manner. That will not change the meaning and I am putting this up
for additional intel.
Note: I've also used OracleJDK8 instead of OpenJDK8 without solving the issue.

Note2: If TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is requested only,
the handshake succeeds.


Note3: The x.509 certificates (client and server) used are signed by
ecdsaWithSHA256 (1.2.840.10045.4.3.2)
maintaining a BrainpoolP256r1 public key.


Thanks for all the help provided.

--000000000000cebed6059c18c906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div><div dir=
=3D"ltr" data-smartmail=3D"gmail_signature"><div>Good morning.</div><div><b=
r></div><div>I am struggling to enable TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA=
384 on my TLS1.2 client. The suite is provided by &#39;bctls-jdk15on-164&#3=
9; and used on a windows10 machine with installed OpenJDK8. Further, is onl=
y supported by the remote mutual authentication is mandatory at the server.=
 <br></div><div>Here the java -version printout</div><div></div><div>
<span style=3D"font-family:monospace"><span>openjdk version &quot;1.8.0_222=
&quot; OpenJDK Runtime=20
Environment (build 1.8.0_222-b10) Eclipse OpenJ9 VM (build=20
openj9-0.15.1, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References=20
20190717_421 (JIT enabled, AOT enabled) OpenJ9   - 0f66c6431 OMR      -=20
ec782f26 JCL      - f147086df1e based on jdk8u222-b10)</span></span> <br></=
div><div><br></div><div>The issue is, that for some reason SHA256 is select=
ed in the client for certificate verification rather than SHA384.</div><div=
><br></div><div>An=20
<code>java.lang.IllegalStateException <span style=3D"font-family:arial,sans=
-serif">is thrown with the information <br></span></code><pre><code><span><=
br>HashAlgorithm</span><span>.</span><span>sha256</span><span>(</span><span=
>4</span><span>)</span><span> is not being tracked<br><span style=3D"font-f=
amily:arial,sans-serif"><br>For debugging, complete TLS handshake has been =
sniffed and I will provide links to screenshots for the packets of interest=
 further on.<br></span></span></code></pre><div>Screenshot: <a href=3D"http=
s://i.stack.imgur.com/KpMYP.png">https://i.stack.imgur.com/KpMYP.png</a></d=
iv><pre><code><span><span style=3D"font-family:arial,sans-serif">At First t=
he client requests the desired cipher suite which can be seen:</span><br></=
span></code></pre><div>
Screenshot:

<a href=3D"https://i.stack.imgur.com/aFoKG.png">https://i.stack.imgur.com/a=
FoKG.png</a><br><code><span></span></code></div><pre><code><span><span styl=
e=3D"font-family:arial,sans-serif">Further in the protocol, the Servers Cer=
tificate Request requests SHA384 (0x0501) as can be seen in:</span><br></sp=
an></code></pre><div>
Screenshot:

<a href=3D"https://i.stack.imgur.com/jDrco.png">https://i.stack.imgur.com/j=
Drco.png</a></div><div><br></div><div>Next the exception is thrown at the c=
lient while generating the Certificate Verify <br></div><div>
It looks like the <span style=3D"font-family:monospace">BCJSSE </span>is tr=
ying to apply SHA256 for generating this message instead of the requested S=
HA384. Since SHA256 is not supported by the suite, the lib is throwing the =
exception (see above) resulting in a breakup. <br></div><div>
<span style=3D"font-family:arial,sans-serif">The server on the other hand i=
s running into an connection timeout.</span>

</div><pre><code><span>
<span style=3D"font-family:arial,sans-serif">Remark: For some reason Wiresh=
ark is decoding the information in TSL 1.3 manner. That will not change the=
 meaning and I am putting this up for additional intel.</span>
<br><span style=3D"font-family:arial,sans-serif">Note: I&#39;ve also used O=
racleJDK8 instead of OpenJDK8 without solving the issue. </span><br></span>=
</code></pre><pre><span style=3D"font-family:arial,sans-serif"><code><span>=
<span style=3D"font-family:arial,sans-serif">Note2: If <span style=3D"font-=
family:monospace">TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 </span>is request=
ed only, the handshake succeeds. </span><br></span></code></span></pre><pre=
><code><span><span style=3D"font-family:arial,sans-serif">
Note3: The x.509 certificates (client and server) used are signed by <span =
style=3D"font-family:monospace"><span><span>ecdsaWithSHA256</span></span> <=
/span>(1.2.840.10045.4.3.2)
maintaining a BrainpoolP256r1 public key.</span>



</span></code></pre><pre><code><span>Thanks for all the help provided.<br><=
/span></code></pre><pre><code><span><br></span></code></pre>

 </div><div><br></div></div></div></div>
</div></div>

--000000000000cebed6059c18c906--