Closed hping2 closed 2 weeks ago
Hey Roy, I think this is also related with our programatic error, the issue can be closed with invalid.
We had a weak SecureRandom() set at CryptoServicesRegistrar.setSecureRandom(new SecureRandom()), this might cause the TLS handshake internally skips the Ecliptic Curve algorithms as we see at the ClientHello message.
We are blocked by BC approved mode on java-8.
Server side using
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
with java-17. Client side using:bc-fips-1.0.2.4.jar, bcpkix-fips-1.0.7.jar, bctls-fips-1.0.19.jar
and java-81.8.0_432
. With BC Approved mode, the TLS handshake failed, on the server side TLS debug log, we saw:no cipher suites in common
, on client side, we sawjavax.net.ssl.SSLException: org.bouncycastle.tls.TlsFatalAlertReceived: handshake_failure(40)
. For NOT in bc approved mode, TLS works without issue.Client side java.security:
From server side TLS debugging, with BC approved mode ON I saw client side
ClientHello
only has supported_group versions:[ffdhe2048, ffdhe3072, ffdhe4096]
which are DHE only, it doesn’t support ECDHE, later handshake failed with"no cipher suites in common"
. While in the non-approved mode case, I read ClientHello[secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096]
(those secp256r1 … secp521r1 are for ECDHE), and TLS has no problem.I have one client side error stack and two server side TLS debug loggings. For comparisons, one is for the case Without BC Approved mode and the other is With BC Approved mode, both are with same server cipher settings, same agent side setting except the BC_Approved mode switch off/on.
According to the doc, I believe BC supports ECDHE related ciphers in the Approved mode, but it is not working on my setup.
Stack trace for BC approved mode on client side logging:
Stack trace for BC approved mode on and failed TLS on server side logging:
Stack trace for BC approved mode OFF and successful TLS on server side logging: