Could someone teach me how to interpret the javax.net.debug result?

Question

I am trying to connect to a jms service using jdk1.8.0_xxx and am getting ssl handshake error. However, I couldn't really understand the output from the javax.net.debug.

System property jdk.tls.client.cipherSuites is set to 'null'
System property jdk.tls.server.cipherSuites is set to 'null'
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_DES_CBC_MD5
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_3DES_EDE_CBC_MD5
Ignoring disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_RSA_WITH_NULL_SHA256
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_RC4_40_SHA
Ignoring disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_MD5
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
adding as trusted cert:
  Subject: CN=******************************, DC=internal, DC=net
  Issuer:  CN=******************************, DC=internal, DC=net
  Algorithm: RSA; Serial number: ******************************
  Valid from Fri Apr 17 16:20:06 HKT 2009 until Mon Apr 17 16:29:08 HKT 2034

trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring disabled protocol: SSLv3
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_SHA for TLSv1
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_MD5 for TLSv1
No available cipher suite for TLSv1
ConnectionEstablishThread>xxxxxx.com:8888, handling exception: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
ConnectionEstablishThread>xxxxxx.com:8888, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure
ConnectionEstablishThread>xxxxxx.com:8888, WRITE: TLSv1.2 Alert, length = 2
ConnectionEstablishThread>xxxxxx.com:8888, called closeSocket()
javax.jms.JMSSecurityException: [BRM.10.5057] JMS: SSL handshake failed with Broker at "xxxxxx.com:8888; Error: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)"
        at com.webmethods.jms.protocol.link.LinkSsl.openSocket(LinkSsl.java:309)
        at com.webmethods.jms.protocol.link.LinkSsl.connect(LinkSsl.java:148)
        at com.webmethods.jms.protocol.ProtocolHandler.connect(ProtocolHandler.java:226)
        at com.webmethods.jms.protocol.BinaryProtocolHandler.connect(BinaryProtocolHandler.java:2051)
        at com.webmethods.jms.impl.WmConnectionImpl.connect(WmConnectionImpl.java:310)
        at com.webmethods.jms.impl.WmConnectionImpl.initConnection(WmConnectionImpl.java:288)
        at com.webmethods.jms.impl.WmConnectionImpl.<init>(WmConnectionImpl.java:226)
        at com.webmethods.jms.impl.WmConnectionImpl.<init>(WmConnectionImpl.java:194)
        at com.webmethods.jms.impl.WmConnectionFactoryImpl.createConnection(WmConnectionFactoryImpl.java:198)

Above the snippet of the log and here are my questions:
1. Are these referring to my jdk?

Ignoring disabled protocol: SSLv3
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_SHA for TLSv1
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_MD5 for TLSv1
No available cipher suite for TLSv1

I am assuming the following line indicates that TLSv1 handshake failed because my jdk doesn't support any of the ciphers presented by the host. Is that correct?

ConnectionEstablishThread>xxxxxx.com:8888, handling exception: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Does this mean that my app attempted to connect with TLSv1.2 but the host doesn't support TLSv1.2?

ConnectionEstablishThread>xxxxxx.com:8888, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure

If my understanding of the above logs are correct then the following logs confuse me. I tried to connect to another server using the same jdk and below the debug log.

%% No cached client session
update handshake state: client_hello[1]
upcoming handshake states: server_hello[2]
*** ClientHello, TLSv1
RandomCookie:  GMT: 1584742551 bytes = { 213, 203, 84, 190, 216, 229, 149, 85, 166, 91, 26, 24, 252, 68, 33, 90, 90, 28, 229, 98, 191, 191, 156, 2, 45, 218, 111, 233 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1}
Extension ec_point_formats, formats: [uncompressed]
Extension extended_master_secret
Extension server_name, server_name: [type=host_name (0), value=yyyyyyyy.com]
***
ConnectionEstablishThread>yyyyyyyy.com:8888, WRITE: TLSv1 Handshake, length = 143
ConnectionEstablishThread>yyyyyyyy.com:8888, READ: TLSv1 Handshake, length = 49
check handshake state: server_hello[2]
*** ServerHello, TLSv1
RandomCookie:  GMT: -1381494379 bytes = { 81, 25, 14, 23, 242, 20, 55, 191, 70, 99, 189, 88, 51, 116, 214, 154, 182, 113, 34, 227, 238, 100, 16, 197, 226, 247, 185, 139 }
Session ID:  {}
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized:  [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
** TLS_RSA_WITH_AES_256_CBC_SHA
update handshake state: server_hello[2]

If the following corresponds to ciphers supported by my jdk then why was it not shown in the previous logs?

Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

Hope that my questions are clear enough and appreciate all the helps. Thanks.

As far as I can see you've included in your question the debug messages from server A (failure) and the debug messages from a client when connecting to server B (success). What would be important are the debug messages from the client when connecting to server A (and failing) which match the failure messages you've included for server A. Currently there are too few information, i.e. the conclusions you currently draw cannot be drawn just from this information. — Steffen Ullrich, Mar 21 '20 at 20:40
Your conclusion 2 could be wrong. It could be that the connection fails not because your client doesn't support the ciphers but because your host doesn't present supported ciphers. I.e. it could be that your host only supports `SSL_RSA_WITH_NULL_SHA` and `SSL_RSA_WITH_NULL_MD5` which would mean no encryption supported and your client rejects unencrypted connections. — Thomas Kläger, Mar 21 '20 at 20:49
@SteffenUllrich thx for your response. I have included the complete debug log. — Slug, Mar 21 '20 at 20:59
@ThomasKläger Thx for your reponse. So, can I say that the cipher suites in the 2nd test are list of ciphers supported by both the server and client? — Slug, Mar 21 '20 at 21:03
@James: While you've included now a more complete server log you still did not include the debug log from the client which unsuccessfully tried to connect to this server. That's was what I've actually requested. — Steffen Ullrich, Mar 21 '20 at 21:04
Focus from this point down in first log : javax.jms.JMSSecurityException: [BRM.10.5057] It looks to my like you've got a connection factory issue - which to me implies the server JMS setup is incorrectly defined or undefined. It could be you've got something like the secure vs insecure ports mixed up, or something like that. Is tger — JGFMK, Mar 21 '20 at 21:14
@SteffenUllrich: these are client logs actually. Unfortunately I have no access to the target server. Would you have any idea what else I can check to determine what TLS version and ciphers the server supports? Also the client — Slug, Mar 21 '20 at 21:16
Is there some xml config in your war file that's wrong that is using insecure port when secure one was needed? — JGFMK, Mar 21 '20 at 21:19
@JGFMK: I don't think it's due to config issue because I am able to connect to the server using jdk1.8.0.181. it fails when I'm using jdk 1.8.0.222 — Slug, Mar 21 '20 at 21:26
Please have a look at https://stackoverflow.com/a/57273918/3081018 . My guess is that this is the same or similar problem, i.e. a newer security setting in a the later JDK version. — Steffen Ullrich, Mar 21 '20 at 21:30
@James since you have the version forked out like that, it's probably a disabled insecure cipher suite. Luckily there aren't too many [release notes](https://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html) to go through. Looks like they removed some root certificates too, and disabled the anon and null cipher suites. This could be a good question for an authoritative answer, if someone smart(er) comes by and manages to explain the whole shebang. — Kayaman, Mar 21 '20 at 21:39
@SteffenUllrich: thx for the link. I am fully aware of the jdk update and issue. However, I'm still interested in understanding the SSL debug log. — Slug, Mar 21 '20 at 21:45

score 0 · Answer 1 · answered Mar 21 '20 at 21:59

Are these referring to my jdk?

Not sure what you mean with this. But this is debug output produced by the TLS stack of your JDK.

I am assuming the following line indicates that TLSv1 handshake failed because my jdk doesn't support any of the ciphers presented by the host. Is that correct?

No. A TLS client does not know the ciphers a server supports. A clients tells the server which ciphers the client supports and the server will then choose one.

Does this mean that my app attempted to connect with TLSv1.2 but the host doesn't support TLSv1.2?

No. The client just tells the server that the handshake failed (since the client has no ciphers to use) and is sending this information as a TLS alert using the TLS 1.2 protocol.

If the following corresponds to ciphers supported by my jdk then why was it not shown in the previous logs?

Likely some settings for the client changed which ciphers are supported compared to the other client.

Could someone teach me how to interpret the javax.net.debug result?

1 Answers1