Назад | Перейти на главную страницу

Apache2 - страницы SSL загружаются в Chrome, но не в Safari

У меня необычная проблема с SSL в Safari. В основном у меня есть сервер Debian, на котором запущен Apache 2 (2.4.10) с OpenSSL 1.0.1t в частной сети.

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

В Chrome - эта настройка работает нормально. Страница загружается, цепочка сертификатов SSL в порядке, Chrome не сообщает об ошибках и зеленом замке.

В Safari (10) - но это случилось и с v9 - и в iOS 10 - все, что я получаю, это «Safari не может открыть страницу xxx, потому что Safari не может установить безопасное соединение с сервером xxx».

Как ни странно, если я перезапускаю сервер Apache, он работает в Safari в течение нескольких секунд - достаточно, чтобы загрузить одну страницу - прежде чем снова произойдет сбой.

В cURL на рабочем столе - Неизвестная ошибка протокола SSL.

В openssl (s_client -connect) - подключено нормально с протоколом: TLSv1, шифром: EDH-RSA-DES-CBC3-SHA.

В nscurl -ats-diagnostics - ОТКАЗ при каждой попытке.


Я подумал, что это проблема с конфигурацией Apache, поэтому я вырезал все, что мог, что, по моему мнению, могло вызывать проблему, и теперь в моем ssl.conf я установил SSLProtocol на ALL -SSLv3 и SSLCipherSuite на MEDIUM: ! aNull и в файле .conf для виртуального хоста, на котором у меня есть SSLEngine, и единственная другая конфигурация SSL для файла сертификата, промежуточного и ключевого.


Но все-таки сайт упорно не хочет открыть в Safari. Что очень странно, так это то, что Chrome работает нормально! Любые общедоступные SSL-сайты, на которые я пытаюсь перейти в Safari, работают нормально.

Любые советы приветствуются!

Каждый раз, когда я говорю программе, такой как вы сказали Apache, строку набора шифров, например MEDIUM:!aNULL для меня лучше всего сначала протестировать его с openssl ciphers команда. Таким образом вы сможете обнаружить много любопытных форм поведения.

openssl ciphers -v 'MEDIUM:!aNULL'
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
KRB5-IDEA-CBC-SHA       SSLv3 Kx=KRB5     Au=KRB5 Enc=IDEA(128) Mac=SHA1
KRB5-IDEA-CBC-MD5       SSLv3 Kx=KRB5     Au=KRB5 Enc=IDEA(128) Mac=MD5
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1
KRB5-RC4-MD5            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=MD5

Из этого списка можно сделать вывод, что, как ни странно, СРЕДНИЙ означает, что вы хотите исключить Шифры HIGH и LOW. В наши дни СРЕДНЯЯ оказывается просто древней. Вы можете разумно ожидать, что любой набор шифров, зависящий от RC4 или MD5, будет отключен клиентами как небезопасный. Поддержка IDEA или SEED не могла быть широко распространена на клиентах, поскольку они никогда не были основными шифрами. Поддержка SHA (старый SHA1) прекратится в самое ближайшее время.

в openssl ciphers игнорировать второй столбец (SSLv3 это не означает, что вы действительно используете SSLv3, это просто минимум требуемый уровень SSL).

Я бы предложил использовать HIGH:-RC4:-MD5:-PSK:-aNULL:-eNULL или, если вы хотите быть супер-новым / супер-безопасным, используйте HIGH:-SHA:-RC4:-MD5:-PSK:-aNULL:-eNULL

Если вы хотите использовать сверхсложный явный список шифров (например, список, предлагаемый Mozilla), имейте в виду, что вам нужно время от времени обновлять список вручную, добавляя новые шифры, по мере перехода на более новые версии openssl.

Если вы хотите явно отдать предпочтение некоторым шифрам на Apache, вам, вероятно, потребуется SSLHonorCipherOrder off в противном случае заказ на стороне клиента будет авторитетным.

Глядя на твой след, думаю, я понял. Похоже, что виртуальный хост Apache, отвечающий на IPv6 через порт 443, настроен на «передачу» HTTP, а не HTTPS.

Я проверил это, пытаясь подключиться к: https://google.com:80/ (или на любом другом сайте) во время нюхания, и я получаю ровно 400 ответов, как в вашем случае.

Итак, проверьте конфигурацию Apache VirtualHost или просто отключите IPv6 на своем сервере, если вы не планируете его использовать.

С помощью MEDIUM может быть проблемой для современных браузеров, потому что они запрещают многие старые шифры.

Вы можете проверить Предложение Mozilla по поводу шифра, например, вы можете использовать его настройки «Промежуточная совместимость (по умолчанию)»: (это очень долго, просто скопируйте и вставьте)

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Спасибо за ответ. В конце концов я понял это, обнюхивая соединение между Safari и Apache, а затем Chrome и Apache. Как я уже сказал, сервер находится в частной сети, и я использую Avahi (zeroconf) для разрешения имен, поэтому я могу использовать что-то вроде web-server.local, и он автоматически разрешается на правильный IP-адрес. Safari пытался использовать ipv6 для подключения, а Chrome пытался использовать ipv4.

Wireshark дал мне очень необычные результаты, когда я попытался подключиться с помощью Safari - вот скриншот. Кажется, что начинает устанавливаться SSL-соединение, а затем сервер немедленно отправляет ошибку 400.

Вывод из Wireshark с Safari

Я попытался перейти прямо к IPv4-адресу в Safari - это сработало, если не считать очевидной ошибки несоответствия сертификата.

Поэтому я отключил IPv6 в Avahi (демон zeroconf) и в Apache на сервере. Перезагрузил и теперь работает.

Любое понимание того, почему он может вести себя так, было бы оценено!