pingidentity / ldapsdk

UnboundID LDAP SDK for Java
Other
331 stars 79 forks source link

[ SDK 4.0.14 / IBM SDK8] No negotiable cipher suite #99

Open frichard35 opened 3 years ago

frichard35 commented 3 years ago

Hi,

we try using the latest version of spring boot which comes with the SDK 4.0.14. We have the below error :

Caused by: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server /127.0.0.1:10389:  SSLHandshakeException(No negotiable cipher suite), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb')
    at com.unboundid.ldap.sdk.ConnectThread.getConnectedSocket(ConnectThread.java:269)
    at com.unboundid.ldap.sdk.LDAPConnectionInternals.<init>(LDAPConnectionInternals.java:166)
    ... 44 more
Caused by: javax.net.ssl.SSLHandshakeException: No negotiable cipher suite
    at com.ibm.jsse2.E.v(E.java:365)
    at com.ibm.jsse2.D.u(D.java:247)
    at com.ibm.jsse2.av.j(av.java:152)
    at com.ibm.jsse2.av.i(av.java:444)
    at com.ibm.jsse2.av.a(av.java:1009)
    at com.ibm.jsse2.av.startHandshake(av.java:778)
    at com.unboundid.util.ssl.SetEnabledProtocolsAndCipherSuitesSocket.startHandshake(SetEnabledProtocolsAndCipherSuitesSocket.java:897)
    at com.unboundid.ldap.sdk.ConnectThread.run(ConnectThread.java:156)

We didn't have this error with the SDK 4.0.13.

After digging a little, it seems that the selector TLSCipherSuiteSelector is refusing all the cipher starting with SSL and in the ibm jdk all the ciphers start with 'SSL' :

https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ibm.java.security.component.71.doc/security-component/jsse2Docs/ciphersuites.html

In the following list, the string "SSL" is interchangeable with "TLS" and vice versa,

As a workaround we will remove the usage of SSLUtil in our code.

If you try to reproduce the problem, the easiest way to get an ibmjdk is with their docker images : https://hub.docker.com/_/ibmjava/

Have a nice day, thx for your work.

François

dirmgr commented 3 years ago

Thanks for reporting this. I'm sorry that I wasn't able to get to this yesterday, but I have just committed a set of changes that should address the problem. I updated the logic so that if there are no suites that start with "TLS", then it will not automatically drop suites whose names start with "SSL". Further, if it still has not identified any recommended suites at the end of processing, then it will just fall back to the set of suites enabled in the JVM by default.

I also updated the logic that defines the order in which the suites are returned so that SSL suites are properly ordered in preference of key agreement algorithm, which was already being done for TLS suites. It now also de-prioritizes suites that use null or export-grade encryption, and those that use anonymous authentication.

frichard35 commented 3 years ago

You're welcome. This part is complex, maybe the best move will have been to map the cipher with their standard names before doing any filtering.... but :

The first reply on this page suggests that OracleJRE (and Openjdk?) is using standard names : https://stackoverflow.com/questions/19846020/how-to-map-a-openssls-cipher-list-to-java-jsse

But this other one seems to tell another story : https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q113220_.htm

frichard35 commented 3 years ago

And don't spend to much time with IBM SDK8 there will be no IBM SDK8+. IBM is now focusing on AdoptOpenJdk with their flavour OpenJ9.

Thx again for your work.