Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SSLHandshakeException due to missing TLS cipher suites in Domino JVM

In my XPages application the following exception is raised when I try to open a HTTPS connection to another server which only allows TLSv1 and newer (no SSLv3):

javax.net.ssl.SSLHandshakeException: No appropriate protocol

Setting javax.net.debug=ssl:handshake provides this additional information:

SSLContextImpl:  Using X509ExtendedKeyManager com.ibm.jsse2.hd
SSLContextImpl:  Using X509TrustManager com.ibm.jsse2.pc
IBMJSSE2 will ignore com.ibm.jsse2.overrideDefaultProtocol since was set to a non recognized value TLSv1
Installed Providers = IBMJSSE2, IBMJCE, IBMJGSSProvider, IBMCertPath, IBMSASL, IBMXMLCRYPTO, IBMXMLEnc, Policy, IBMSPNEGO
JsseJCE:  Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
trigger seeding of SecureRandom
done seeding SecureRandom
IBMJSSE2 will enable CBC protection
IBMJSSE2 to send SCSV Cipher Suite on initial ClientHello
JsseJCE:  Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set to none or default
IBMJSSE2 will not require renegotiation indicator during initial handshake per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default taken
IBMJSSE2 will not perform identity checking against the peer cert check during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check set to OFF or default
IBMJSSE2 will not allow unsafe server certificate change during renegotiation per jdk.tls.allowUnsafeServerCertChange set to FALSE or default
Is initial handshake: true
JsseJCE:  Using KeyAgreement ECDH from provider IBMJCE version 1.2
JsseJCE:  Using signature SHA1withECDSA from provider TBD via init 
JsseJCE:  Using signature NONEwithECDSA from provider TBD via init 
JsseJCE:  Using KeyFactory EC from provider IBMJCE version 1.2
JsseJCE:  Using KeyPairGenerator EC from provider TBD via init 
JsseJce:  EC is available
Ignoring disabled cipher suite: SSL_RENEGO_PROTECTION_REQUEST for TLSv1
No available cipher suite for TLSv1
Thread-8, handling exception: javax.net.ssl.SSLHandshakeException: No appropriate protocol
Thread-8, SEND TLSv1 ALERT: fatal, 
description = handshake_failure

The main problem seems to be "No available cipher suite for TLSv1".

Getting the default and supported cipher suites (getDefaultCipherSuites() / getSupportedCipherSuites()) from the SSL server socket factory (SSLServerSocketFactory.getDefault()) reveals that only SSL cipher suites are available in the Domino JVM, but none for TLS.

The code I'm using to establish the HTTPS connection works fine in a non-Domino JVM with TLS cipher suites.

Can anybody tell me how to make TLS cipher suites available in the Domino JVM? Or generally help me if there is a different problem and I misinterpreted the debug information?


Additional information:

Domino version: 9.0.1 FP7

Java runtime version: pwa6460sr16fp30-20160726_01 (SR16 FP30)

JVM version: JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64 jvmwa6460sr16fp30-20160725_312906 (JIT enabled, AOT enabled) J9VM - 20160725_312906 JIT - r9_20160725_121766 GC - GA24_Java6_SR16_20160725_1417_B312906

Unrestricted JCE policy files have been installed in the Domino JVM.

like image 565
xpages-noob Avatar asked Oct 29 '22 16:10

xpages-noob


1 Answers

The problem seems to be related to how some Java SDKs limit the available cipher suites. The Dropbox Java SDK, for example, uses a hard-coded list of cipher suite names which all start with "TLS_". In the Domino JVM, however, all cipher suite names start with "SSL_". As a consequence, all cipher suites get disabled in the created SSL sockets because none of their names match.

like image 96
xpages-noob Avatar answered Nov 09 '22 15:11

xpages-noob