У меня есть 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 и новому конфигу, но работает со старым (внутренняя ошибка от клиента после того, как сервер сделал привет).

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

2 ответа2

0

Абзац с указанием

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

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

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

0

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

Это изменение шифровщика не имеет смысла. Вы добавили термин 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 ?

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .