Может ли кто-нибудь научить меня интерпретировать результат javax.net.debug?


Я пытаюсь подключиться к службе jms с помощью jdk1.8.0_xxx и получаю сообщение об ошибке рукопожатия ssl. Однако я не мог понять вывод 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)

Выше фрагмент журнала и вот мои вопросы:
1. Они относятся к моему 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
  1. Я предполагаю, что следующая строка указывает на то, что рукопожатие TLSv1 не удалось, потому что мой jdk не поддерживает ни один из шифров, представленных хостом. Это правильно?
ConnectionEstablishThread>xxxxxx.com:8888, handling exception: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
  1. Означает ли это, что мое приложение пыталось подключиться с помощью TLSv1.2, но хост не поддерживает TLSv1.2?
ConnectionEstablishThread>xxxxxx.com:8888, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure


Если я правильно понимаю приведенные выше журналы, то следующие журналы меня смущают. Я попытался подключиться к другому серверу, используя тот же jdk и ниже журнала отладки.

%% 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]


Если следующее соответствует шифрам, поддерживаемым моим jdk, то почему оно не отображалось в предыдущих журналах?

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]


Надеюсь, что мои вопросы достаточно ясны, и ценю всю помощь. Спасибо.


java ssl tls1.2 tls1.0
person Slug    schedule 21.03.2020    source источник
comment
Насколько я вижу, вы включили в свой вопрос отладочные сообщения с сервера A (сбой) и отладочные сообщения от клиента при подключении к серверу B (успех). Что было бы важно, так это отладочные сообщения от клиента при подключении к серверу A (и сбое), которые соответствуют сообщениям об ошибках, которые вы включили для сервера A. В настоящее время слишком мало информации, т.е. выводы, которые вы сейчас делаете, не могут быть сделаны только из этой информации.   -  person Steffen Ullrich    schedule 21.03.2020
comment
Ваш вывод 2 может быть неправильным. Возможно, соединение не установлено не потому, что ваш клиент не поддерживает шифры, а потому, что ваш хост не поддерживает поддерживаемые шифры. т.е. возможно, ваш хост поддерживает только SSL_RSA_WITH_NULL_SHA и SSL_RSA_WITH_NULL_MD5, что означает, что шифрование не поддерживается, и ваш клиент отклоняет незашифрованные соединения.   -  person Thomas Kläger    schedule 21.03.2020
comment
@SteffenUllrich, спасибо за ваш ответ. Я включил полный журнал отладки.   -  person Slug    schedule 21.03.2020
comment
@ThomasKläger Спасибо за ответ. Итак, могу ли я сказать, что наборы шифров во втором тесте — это список шифров, поддерживаемых как сервером, так и клиентом?   -  person Slug    schedule 22.03.2020
comment
@James: Хотя вы теперь включили более полный журнал сервера, вы все еще не включили журнал отладки от клиента, который безуспешно пытался подключиться к этому серверу. Это было то, что я на самом деле просил.   -  person Steffen Ullrich    schedule 22.03.2020
comment
Сфокусируйтесь с этой точки вниз в первом журнале: javax.jms.JMSSecurityException: [BRM.10.5057] Мне кажется, что у вас проблема с фабрикой соединений, что для меня означает, что настройка JMS сервера определена неправильно или не определена. Возможно, вы перепутали безопасные и небезопасные порты или что-то в этом роде. Тгер   -  person JGFMK    schedule 22.03.2020
comment
@SteffenUllrich: на самом деле это журналы клиентов. К сожалению, у меня нет доступа к целевому серверу. У вас есть идеи, что еще я могу проверить, чтобы определить, какую версию TLS и шифры поддерживает сервер? Также клиент   -  person Slug    schedule 22.03.2020
comment
Есть ли в вашем военном файле неправильная конфигурация xml, которая использует небезопасный порт, когда необходим безопасный?   -  person JGFMK    schedule 22.03.2020
comment
@JGFMK: я не думаю, что это связано с проблемой конфигурации, потому что я могу подключиться к серверу, используя jdk1.8.0.181. это не удается, когда я использую jdk 1.8.0.222   -  person Slug    schedule 22.03.2020
comment
Пожалуйста, взгляните на stackoverflow.com/a/57273918/3081018. Я предполагаю, что это та же или похожая проблема, то есть более новый параметр безопасности в более поздней версии JDK.   -  person Steffen Ullrich    schedule 22.03.2020
comment
@James, поскольку у вас есть такая разветвленная версия, вероятно, это отключенный набор небезопасных шифров. К счастью, примечаний к выпуску не так уж много. проходить через. Похоже, они также удалили некоторые корневые сертификаты и отключили наборы анонимных и нулевых шифров. Это может быть хорошим вопросом для авторитетного ответа, если придет кто-то умный и сумеет объяснить всю эту ерунду.   -  person Kayaman    schedule 22.03.2020
comment
@SteffenUllrich: спасибо за ссылку. Я полностью осведомлен об обновлении и проблеме jdk. Тем не менее, мне все еще интересно понять журнал отладки SSL.   -  person Slug    schedule 22.03.2020

Ответы (1)


arrow_upward
0
arrow_downward

  1. Это относится к моему jdk?

Не уверен, что вы имеете в виду с этим. Но это вывод отладки, созданный стеком TLS вашего JDK.

  1. Я предполагаю, что следующая строка указывает на то, что рукопожатие TLSv1 не удалось, потому что мой jdk не поддерживает ни один из шифров, представленных хостом. Это правильно?

Нет. Клиент TLS не знает, какие шифры поддерживает сервер. Клиенты сообщают серверу, какие шифры поддерживает клиент, и затем сервер выбирает один из них.

  1. Означает ли это, что мое приложение пыталось подключиться с помощью TLSv1.2, но хост не поддерживает TLSv1.2?

Нет. Клиент просто сообщает серверу, что рукопожатие не удалось (поскольку у клиента нет шифров для использования), и отправляет эту информацию в виде предупреждения TLS с использованием протокола TLS 1.2.

Если следующее соответствует шифрам, поддерживаемым моим jdk, то почему это не отображалось в предыдущих журналах?

Вероятно, некоторые настройки клиента изменились, какие шифры поддерживаются по сравнению с другим клиентом.

person Steffen Ullrich    schedule 21.03.2020