началась проблема SSLV3_ALERT_HANDSHAKE_FAILURE?
Сертификат валидный, правда селф-сайнед. Аутентификация по кренделям - те же, что и раньше, точно рабочие. Разница только в питоне: скакнули с 3.8 на 3.10 и огребли.
если сертификат самоподписной то он не валиден) для системы
Мы выставили verify_cert=False. Это внутренний тул, так что можно) Повторюсь - с питоном 3.8 работало) Надо чтобы также с 3.10 заработало)
А сервер с эластиком свежий tls умеет? Насколько я помню, старые задеприкейтили.
хм а create_ssl_context из эластик пробовал с сертами?
На счёт сервера, хз чо там. Как посмотреть? Скажем так. Банальный GET сделанный из requests норм коннектится, возвращает 200.
У меня сертификатов нет. Контекст раньше не использовался. Я авторизуюсь по логин-паролю. И хотелось бы дальше также.
Примерно так: https://www.howtouselinux.com/post/ssl-vs-tls-and-how-to-check-tls-version-in-linux#:~:text=OpenSSL%20command%20is%20the%20easiest,host.com%3A443%20%2Dtls1_1 Не знаю, в чём разница с requests, 3.10 должен на sslv3 варнинг писать, если ничего не путаю. Может либа с более строгими опциями коннектится и не игнорирует варнинг.
ну попробуй вот так ssl_context = create_ssl_context() ssl_context.check_hostname = False ssl_context.verify_mode = ssl.CERT_NONE
Конечно)) Тот же хост.
я как раз за сервер больше
Очень странно на самом деле. Потому что SSLV3_ALERT_HANDSHAKE_FAILURE говорит о том, что клиент с сервером не смогли договориться по версиям протокола и шифрам. И в 3.10 как раз поубирали всякие старые и ненадёжные. https://bugs.python.org/issue43998
Вот и мне странно. Через requests я же тем же 3.10 лезу и норм.
Уточнил. Сервер версия - 7.17.2
Проверил с клиентом 7.17.3 - всё тоже самое, только питонячие эксепшены чуток другие - в старшей версии обернули в свой "выше этажом". А так, тот же SSLV3_ALERT_HANDSHAKE_FAILURE
А через реквесты отрабатывает так?
Дык requests не зависит от эластик клиент либы. Она просто работает)
Выглядит как будто у вас древняя версия ssl юзается. В браузере попробуйте открыть урл эластика, что пишется в инфе о соединении?
я про другое, если ревесты работают то грабли в либе точнее как она работает с 3.10
Да, тоже склоняюсь к тому, что либа elasticsearch кривая. Сейчас проверил с питоном 3.9 - работает! Т.е. сломалось на переходе 3.9 —> 3.10
Вообще некогда сейчас вникать, но вроде бы requests как-то переиначивала установку ssl-соединения, так что тест не чистый. С такой ошибкой проблема почти 100% в версии tls или используемых шифрах. requests может просто по тихой переопределять это поведение.
А 3.10 вы как ставили вообще?
походу https://bugs.python.org/issue43998
Сам ты кривой The deprecated protocols SSL 3.0, TLS 1.0, and TLS 1.1 are no longer officially supported. Python does not block them actively. However OpenSSL build options, distro configurations, vendor patches, and cipher suites may prevent a successful handshake. https://docs.python.org/3/whatsnew/3.10.html
Открой урл с каким-нибудь индексом и нажми на замочке в браузере
А можно целиком ошибку ещё?
elastic_transport.TlsError: TLS error caused by: TlsError(TLS error caused by: ClientConnectorSSLError(Cannot connect to host labesd110.infra.five9lab.com:9200 ssl:default [[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:997)]))
мож твое https://github.com/elastic/elasticsearch-py/issues/712
Вот этого не знаю. А как оно могло повлиять на историю с SSL?
попробуй админов-девпесов привлечь к поиску проблему, возможно они что-то подскажут
В общем, я дошёл до Wireshark) Итого: и requests, и aiohttp используют TLSv1.2 (что под капотом у синхронного ElasticSearch я пока не понял, но он тоже не работает) При этом разницу в Client Hello сообщениях я вижу только в списке Cipher Suites - из у requests 43 против 18. И эластик сервер в случае с requests выбирает такой набор, которого нет в списке у aiohttp. Вопрос: этот Cipher Suites можно как-то расширить, кастомизировать?
Обсуждают сегодня