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 я вижу следующее:
ЗАПИСЬ: TLSv1.2 рукопожатие, длина = 64
ЧИТАТЬ: TLSv1.2 Alert, length = 2
RECV TLSv1.2 ALERT: фатальный, handshake_failure
%% Недействительно: [Сеанс-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
Есть идеи относительно того, что может пойти не так?
Спасибо за ответ. Я отредактировал вопрос с результатами TestSSLServer, и похоже, что RSA_WITH_AES_128_CBC_SHA является одним из предпочтений сервера. На самом деле, у меня нет особого контроля на стороне сервера, чтобы отлаживать вещи. И мне интересно, где ошибка, на стороне клиента или на стороне сервера.
Ответы 2
Я не мог понять точную причину, но теперь понимаю, что может пойти не так. Как предложил Дейв, я включил отладку SSL, просмотрел все журналы и сравнил неудавшиеся запросы с успешными.
Для неудачных запросов это то, что я видел в журналах:
- Клиент отправил привет, а сервер отправил привет
- Сервер отправил сертификат и сервер Hello Done
- Обмен клиентскими ключами и изменение спецификации шифра
- Законченный
- Ошибка здесь и сообщение No Change Cipher от сервера, ошибка handshake_failure
Как видите, сервер по какой-то причине не отвечает. После некоторого поиска в Google я наткнулся на следующий форум, посвященный проблемам SSL с f5. Наш сервис тоже проходит через f5. Я не могу подтвердить, так как у меня нет большого контроля над нашей серверной частью, но проблема ниже выглядит примерно так:
https://devcentral.f5.com/questions/big-ip-proxy-ssl-121-handshake-failure-47464
У нас была очень похожая проблема с F5 ProxySSL, нарушающая расширение расширенного главного секрета. Нашим решением было отключение на сервере. Кроме того, вы не упомянули в своем вопросе этот прокси-элемент (f5).
Да, раньше не думал, что это может быть связано с f5, но после просмотра журналов SSL и некоторого поиска это имеет смысл. Думаю, я должен отметить это как ответ.
Самые последние версии Java (8u161 и 9.0.4) действительно поддерживают ExtendedMasterSecret, но они (будут) использовать его при каждом рукопожатии, это не будет прерывистым. И, к вашему сведению, последние версии Java больше не нуждаются в банках с неограниченной политикой Когда-либо; они, наконец, устранили этот недостаток десятилетней давности. Удачи.
Обновление. Наша команда серверов проинформировала нас, что они выяснили проблему с настройкой SSL f5, и сказали, что это крайний случай, когда один и тот же IP-адрес постоянно попадает в службу. У меня сейчас нет подробностей, но я опубликую здесь, когда сделаю это. Спасибо за помощь Дэйву и Эжену.
Очередное обновление. Эта проблема исправлена. Наша серверная команда внесла некоторые изменения в то, как был настроен f5 (у меня до сих пор нет подробностей), и мы запустили автоматизацию JMeter, и мы больше не видим исключения квитирования SSL :)
Это известная проблема, описанная в идентификатор ошибки 563488 для версий BIG-IP до 13.0, как описано в K34019109.
На сегодняшний день лучший выбор: посмотрите журналы сервера, чтобы узнать, что в нем говорится о проблеме, затем исследуйте и исправьте ее. В противном случае установите sysprop
javax.net.debug=sslи сохраните вывод, который будет огромным (возможно, вам придется купить еще несколько дисков), и потратите дни или недели на его изучение. Ваши 1 и 4 никогда не могут вызвать это предупреждение, а ваш 2 не может, если сервер принимает AES128. (Принятие заметки - это не то же самое, что требование; ваше «ожидание» неоднозначно.)