JMeter javax.net.ssl.SSLHandshakeException с перерывами

Ketan спросил: 13 июня 2018 в 11:41 в: java

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

Эта проблема очень похожа на следующий вопрос SO, но все решения, обсуждаемые там, t для меня: 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 Рукопожатие, длина = 64
READ: TLSv1.2 Alert, length = 2
RECV TLSv1.2 ALERT: фатальный, handshake_failure
%% Invalidated: [Session-17, TLS_RSA_WITH_AES_128_CBC_SHA]

Я пробовал следующие решения:
1. Добавлен серверный сертификат jre cacerts
2. Загруженные локальные банки политики для неподдерживаемых шифров и скопировали их в папку безопасности jre lib
3. Обновите банку httpclient (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

Любые идеи относительно что может пойти не так?

dave_thompson_085 ответил: 13 июня 2018 в 01:22

Лучший выбор на данный момент, посмотрите на журнал (ы) сервера, чтобы увидеть, что он говорит, проблема, затем исследуйте и исправляйте это. В противном случае установите sysprop javax.net.debug=ssl и сохраните вывод, который будет огромным (вам может потребоваться купить еще несколько дисков) и провести через него дни или недели. Ваши 1 и 4 никогда не могут вызывать это предупреждение, а ваш 2 не может, когда сервер принимает AES128. (Признание принятия не совпадает с требованием, ваше "ожидание" неоднозначно.)

Ketan ответил: 13 июня 2018 в 03:55

Спасибо за ответ. Я отредактировал вопрос с результатами TestSSLServer, и похоже, что RSA_WITH_AES_128_CBC_SHA является одним из предпочтений сервера. Фактически, у меня нет большого контроля над серверной частью для отладки вещей. И мне интересно, где ошибка, на стороне клиента или на стороне сервера.

2 ответа

Ketan ответил: 14 июня 2018 в 10:50

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

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

Клиент отправил Hello & Сервер отправлен Привет
Сервер отправил cert & Сервер Hello Done
Обмен ключами клиентов и amp; Change Cipher Spec
Закончено
Сбой здесь и No Change Cipher сообщение от сервера, ошибка handshake_failure

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

https://devcentral.f5.com/questions/big-ip-proxy-ssl- 121-рукопожатие безотказного-47464

Eugène Adell ответил: 14 июня 2018 в 09:19

У нас была очень похожая проблема на F5 ProxySSL, которая нарушала расширение расширенного секретного ключа. Отключение на сервере было нашим решением. Кроме того, вы не упомянули в своем вопросе этот прокси-элемент (f5).

Ketan ответил: 14 июня 2018 в 10:49

Да, раньше не думал, что это может быть связано с F5, но, посмотрев на журналы SSL и некоторые поиски, это имеет смысл. Думаю, я должен отметить это как ответ.

dave_thompson_085 ответил: 15 июня 2018 в 08:15

Самые последние версии Java (8u161 и 9.0.4) поддерживают ExtendedMasterSecret, но они (будут) использовать его в каждом рукопожатии, это не будет прерывистым. И FYI аналогичным образом, последние версии Java больше не нуждаются в банках с неограниченной политикой ever ; они, наконец, удалили эту многолетнюю неудачу. Удачи.

Ketan ответил: 15 июня 2018 в 10:22

Обновление. Наша команда серверов сообщила нам, что они выяснили проблему с настройкой SSL f5 и сказали, что это крайний случай, когда один и тот же IP-адрес постоянно попадает в службу. У меня сейчас не так много подробностей, но опубликую здесь, как только я это сделаю. Спасибо, что помогли Дейву и Эжену.

Ketan ответил: 16 июня 2018 в 11:07

Еще одно обновление. Эта проблема исправлена. Команда нашего сервера внесла некоторые изменения в настройку f5 (у меня все еще нет спецификаций), и мы запустили автоматизацию JMeter, и мы больше не видим исключения для установления связи SSL :)

Jason Rahm ответил: 15 июня 2018 в 03:52

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

JMeter javax.net.ssl.SSLHandshakeException с перерывами

2 ответа

Дополнительное видео по вопросу: JMeter javax.net.ssl.SSLHandshakeException с перерывами

ssl adding server public certificate to client keystore

Rest API Testing using Jmeter || How to call Rest WebServices in Jmeter

JMeter Beginners Tutorial - JMeter Selenium Webdriver sampler