PROBLEM WITH USING TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and BrainpoolP384r1

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

PROBLEM WITH USING TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and BrainpoolP384r1

CBroeter
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.
At First the client requests the desired cipher suite which can be seen:
Further in the protocol, the Servers Certificate Request requests SHA384 (0x0501) as can be seen in:

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.


Reply | Threaded
Open this post in threaded view
|

Re: PROBLEM WITH USING TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and BrainpoolP384r1

Peter Dettman-3
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.
> |
>
> |
> |
>
>