Обновление Apache приводит к сбою подтверждения связи SSL с клиентом Java

у меня есть apache 2.4.10 для обновления до 2.4.12, лежащий в основе openssl 0.9.8, со следующей конфигурацией SSL:

SSLCipherSuite DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!EXPORT
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on

С обновлением, я хочу изменить наборы шифров

SSLCipherSuite DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA:DES-CBC3-SHA:DHE-RSA-AES256-CBC-SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:!EXPORT 

версии OpenSSL и Java:

OpenSSL 0.9.8j-fips 07 Jan 2009

java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode)

очевидно, все должно остаться этим же со всеми клиентами. Однако есть клиент Java 7 SE, который отказывается соединяться с новым Apache 2.4.12 и новым config, но работает со старым (внутренняя ошибка клиента после приветствия сервера).

есть ли у кого-нибудь идеи?

1
задан rexkogitans
30.12.2022 14:20 Количество просмотров материала 3049
Распечатать страницу

2 ответа

не полный ответ, но некоторые идеи/направления:

что изменить cipherlist составляет бессмысленно. Термин, который вы добавили TLS_DHE_RSA_WITH_AES_256_CBC_SHA в стандартном формате RFC, также используется Java и некоторые другие вещи, такие как Wireshark, но не формат, используемый OpenSSL; формат OpenSSL DHE-RSA-AES256-SHA, который был/уже в свой список. Также,!EXPORT здесь бесполезно; он удалит любые наборы экспорта, которые имели были добавлены, но ни один не был, и это предотвратит любые дальнейшие спецификации от добавляя их обратно, но нет никаких дополнительных спецификаций.

некоторые ранние версии Java 7 SSL (JSSE), я не помню точно, но, вероятно, включая 7.03, имели свой шифр-лист по умолчанию в неправильном порядке, что может привести к выбору беднее, чем необходимо шифровальных, но ваш SSLHonorCipherOrder on игнорирует заказ клиента, так что не может быть.

последние версии httpd начали по умолчанию использовать большие группы DH (для DHE, который вы предпочитаете), и что создает проблемы для Java 7 (и раньше) по крайней мере, используя свои криптографические провайдеры по умолчанию. Но http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile говорит, что эти изменения были 2.4.7 и .10, так .10 до .12 не должны вносить никаких изменений, о которых я знаю. запрос: у вас на самом деле есть DH 1024bit настроен какhttp://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#javadh предлагает?

если это не так, мне понадобится больше data. Что написано в httpd журнал(Ы), когда проблема возникает? Можете ли вы получить более подробную информацию от клиента Java с проблемой, как точное сообщение об исключении? (Это клиент, которым вы можете управлять сами, или он принадлежит другому человеку или лицам?) Можете ли вы получить сетевой захват неудачной попытки с Wireshark или tcpdump или подобным? Если все остальное терпит неудачу, может ли кто-нибудь запустить клиент Java с -Djavax.net.debug=ssl или эквивалентный, и получить (довольно объемный) результирующий вывод?

0
отвечен dave_thompson_085 2022-12-31 22:08

абзац о том,

некоторые ранние версии Java 7 SSL

by @dave_thompson_085 привело меня к окончательному решению. Проблема и решение хорошо описаны на веб-сайт Apache.

существует блок, который будет добавлен к файлу PEM, который заставляет определенный TLS v1.0 параметры сеанса, необходимые Java SE 7.

0
отвечен rexkogitans 2023-01-01 00:25

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх