JMeter javax.net.ssl.SSLHandshakeException периодически

Мы запускаем сценарий JMeter, который отправляет данные json на внутреннюю конечную точку https. Но мы периодически получаем исключение javax.net.ssl.SSLHandshakeException (примерно 3 раза из 100 вызовов) во время выполнения сценария.

Эта проблема очень похожа на следующий вопрос SO, но все обсуждаемые там решения для меня не работают: javax.net.ssl.SSLHandshakeException: handshake_failure при использовании JMeter с SSL (JDK8)

Я использую JDK8 и последнюю версию JMeter 4.0. Я включил отладку ssl и из сообщений ClientHello и ServerHello, похоже, что сервер поддерживает TLS 1.2 и набор шифров TLS_RSA_WITH_AES_128_CBC_SHA, который также поддерживается JMeter.

Но в журналах SSL для неудачных запросов JMeter я вижу следующее:

WRITE: TLSv1.2 Handshake, length = 64
READ: TLSv1.2 Alert, length = 2
RECV TLSv1.2 ALERT: fatal, handshake_failure
%% Недействительно: [Session-17, TLS_RSA_WITH_AES_128_CBC_SHA]

Я пробовал следующие решения:
1. Добавлен серверный сертификат в jre cacerts
2. Загрузил локальные jar-файлы политик для неподдерживаемых шифров и скопировал их в папку безопасности jre lib
3. Обновите httpclient jar (4.5) для JMeter
4. Явно включенный TLS 1.2 в конфигурации JMeter

Я использовал TestSSLServer для проверки возможности SSL нашего сервера, и вот что он возвращает:
SSLv3:
выбор сервера: принудительное выполнение настроек сервера
3- (ключ: RSA) RSA_WITH_RC4_128_SHA
3- ( ключ: RSA) RSA_WITH_AES_128_CBC_SHA
3- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA
3- (ключ: RSA) RSA_WITH_3DES_EDE_CBC_SHA
TLSv1.0: idem
TLSv1.2: выбор сервера: принудительно применять настройки сервера
3- (ключ: RSA) RSA_WITH_RC4_128_SHA
3- (ключ: RSA) RSA_WITH_AES_128_CBC_SHA
3- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA
3- (ключ: RSA) RSA_WITH_3DES_EDE_CBC_SHA
3- (ключ: RSA) RSA_WITH_AES_128_CBC_SHA256
3- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA256

Есть идеи относительно того, что может пойти не так?


java ssl jmeter sslhandshakeexception f5
person Ketan    schedule 08.07.2018    source источник
comment
На сегодняшний день лучший выбор: посмотрите журналы сервера, чтобы узнать, что в нем говорится о проблеме, затем исследуйте и исправьте ее. В противном случае установите sysprop javax.net.debug=ssl и сохраните вывод, который будет огромным (возможно, вам придется купить еще несколько дисков), и потратите дни или недели на его изучение. Ваши 1 и 4 никогда не могут вызвать это предупреждение, а ваш 2 не может, если сервер принимает AES128. (Принятие заметки - это не то же самое, что требование; ваше «ожидание» неоднозначно.)   -  person dave_thompson_085    schedule 08.07.2018
comment
Спасибо за ответ. Я отредактировал вопрос с результатами TestSSLServer, и похоже, что RSA_WITH_AES_128_CBC_SHA является одним из предпочтений сервера. На самом деле, у меня не так много возможностей для отладки на стороне сервера. И мне интересно, где вина, на стороне клиента или на стороне сервера.   -  person Ketan    schedule 08.07.2018

Ответы (2)


arrow_upward
1
arrow_downward

Я не мог понять точную причину, но теперь понимаю, что может пойти не так. Как предложил Дейв, я включил отладку SSL, просмотрел все журналы и сравнил неудавшиеся запросы с успешными.

Для неудачных запросов это то, что я видел в журналах:

  1. Клиент отправил привет, а сервер отправил привет
  2. Сервер отправил сертификат и сервер Hello Done
  3. Обмен клиентскими ключами и изменение спецификации шифра
  4. Законченный
  5. Ошибка здесь и сообщение No Change Cipher от сервера, ошибка handshake_failure

Как видите, сервер по какой-то причине не отвечает. После некоторого поиска в Google я наткнулся на следующий форум, посвященный проблемам SSL с f5. Наш сервис тоже проходит через f5. Я не могу подтвердить, так как у меня нет большого контроля над нашей серверной частью, но проблема ниже выглядит примерно так:

https://devcentral.f5.com/questions/big-ip-proxy-ssl-121-handshake-failure-47464

person Ketan    schedule 08.07.2018
comment
У нас была очень похожая проблема с F5 ProxySSL, нарушающая расширение расширенного главного секрета. Нашим решением было отключение на сервере. Кроме того, вы не упомянули в своем вопросе этот прокси-элемент (f5). - person Eugène Adell; 09.07.2018
comment
Да, раньше не думал, что это может быть связано с f5, но после просмотра журналов SSL и некоторого поиска это имеет смысл. Думаю, я должен отметить это как ответ. - person Ketan; 09.07.2018
comment
Самые последние версии Java (8u161 и 9.0.4) действительно поддерживают ExtendedMasterSecret, но они (будут) использовать его при каждом рукопожатии, это не будет прерывистым. И, к вашему сведению, последние версии Java больше не нуждаются в банках с неограниченной политикой ever; они, наконец, устранили этот недостаток десятилетней давности. Удачи. - person dave_thompson_085; 09.07.2018
comment
Обновление. Наша команда серверов проинформировала нас, что они выяснили проблему с настройкой SSL f5, и сказали, что это крайний случай, когда один и тот же IP-адрес постоянно попадает в службу. Сейчас у меня не так много подробностей, но я опубликую здесь, когда сделаю это. Спасибо за помощь Дэйву и Эжену. - person Ketan; 10.07.2018
comment
Очередное обновление. Эта проблема исправлена. Наша серверная команда внесла некоторые изменения в то, как был настроен f5 (у меня до сих пор нет подробностей), и мы запустили автоматизацию JMeter, и мы больше не видим исключения квитирования SSL :) - person Ketan; 11.07.2018

arrow_upward
0
arrow_downward

Это известная проблема, описанная ранее в идентификаторе ошибки 563488 для версий BIG-IP. чем 13.0, как описано в K34019109.

person Jason Rahm    schedule 09.07.2018