Hi Christoph,
Thanks for the report. We are already aware of an issue with BCJSSE not
respecting the server's supported_signature_algorithms
(CertificateRequest) when selecting the client credentials to use for
client authentication.
I think that issue explains the behaviour you are seeing here too, but
I'll check your case specifically when I go to fix it.
Did you say somewhere what the server software was?
Regards,
Pete Dettman
On 14/1/20 7:32 pm, Christoph Bröter wrote:
> 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.
> |
>
> |
> |
>
>
Locked
