Я получаю сообщение об ошибке: SSL3_GET_RECORD: расшифровка не удалась или запись mac плохая

Вы не можете сказать по этой ошибке, согласовывает ли ваш сервер SSLv3 или TLSv1 (возможно, вы захотите взглянуть на этот вопрос по Unix и Linux и убедитесь, что он отключен где угодно в apache ...) --- исходный код 1.1.0f здесь, на GitHub намеренно размывает два ...

   if (enc_err < 0) {
    /*
     * A separate 'decryption_failed' alert was introduced with TLS 1.0,
     * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
     * failure is directly visible from the ciphertext anyway, we should
     * not reveal which kind of error occurred -- this might become
     * visible to an attacker (e.g. via a logfile)
     */
    al = SSL_AD_BAD_RECORD_MAC;
    SSLerr(SSL_F_SSL3_GET_RECORD,
           SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
    goto f_err;
}

Так что вы можете захотеть изменить порядок своего набора шифров:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

Этот пост на askubuntu об уязвимости POODLE имеет отличный список ресурсов для проверки SSL и сантехники.

Генератор конфигурации Mozilla является превосходно Государственная служба.

Комментарий "получение этой ошибки каждый пятый щелчок" немного странный. Ты имеешь ввиду щелчки, или каждая пятая строка - это плохой запрос в логах? Попробуйте запустить однопоточный apache (флаг -X) и посмотрите, делает ли это то же самое ... или, возможно, настройте SSLSessionTickets off.

Я думаю здесь, чтобы исключить потоки и согласованность / согласованность сеанса / кеша как источник проблем. Однопоточный запуск apache (запуск с флагом -X) - один из способов добиться этого, другой способ - установить MaxClients=1 (по крайней мере, с моделью MPM). Сеансовые билеты были источником проблем в прошлом с TLSv1.2, и они включены по умолчанию, это причина SSLSessionTickets off (обратите внимание, что это часть сообщения SSL «Server Hello», а не файл cookie сеанса или что-то подобное). Ошибка «каждый пятый щелчок» все еще беспокоит меня - я не могу не заметить, что большинство браузеров будут обрабатывать четыре запроса ресурсов в одном ...) и открывать новое соединение (новое подтверждение ssl и т.д.). для пятого ... без захвата пакета сложно сказать, что на самом деле происходит.

Казалось бы, вы устранили согласование шифра как источник ошибки (если я не ошибаюсь, вы можете продублировать условие ошибки при гораздо более строгих спецификациях шифра). Мне было бы любопытно узнать, можете ли вы вызвать ошибку, повторно согласовав SSL (например, просто для удовольствия): openssl s_client -connect server:443 а затем введите «R» и посмотрите, что написано в журналах.
Также посмотрите, работает ли кеширование сеанса с -reconnect опция для s_client.
Что-то контексты приема для SSL-запросов должны отличаться, и кажется, что лучший способ понять это (не считая побайтовой проверки того, что происходит по сети, что может быть трудно анонимизировать), - это строго ограничить размер того, что слушает (то есть количество слушателей).

Я бы попробовал другие инструменты отладки (при условии, что отправка захвата пакетов исключена ....)
- ssltap (в libnss3-tools на убунту)
- шифрование
- sslscan

ОБНОВИТЬ
Тыкаю в это через ssltap очень похоже на Ошибка OpenSSL # 3712 снова всплыла (в основном, повторное согласование ключей во время чтения / записи). Ищете достойный обходной путь, который не убьет производительность. Веселая штука!

Я видел это раньше, было это раньше.

В моем случае ответ оказался очень тонким.

Сетевой адаптер включил разгрузку сегмента TCP, которая из-за какой-либо ошибки искажала (или усекала, не могла вспомнить) последние несколько байтов некоторых сообщений, что впоследствии приводило к сбою MAC в записях SSL.

Это была виртуальная машина на VMWare.

Я бы попробовал отключить TSO / GSO / GRO в вашей среде и посмотреть, исчезнет ли проблема.

ethtool -K eth0 tso off gro off gso off ufo off

Есть некоторые странности с OpenSSL и многопоточностью. Какой MPM вы используете? Если это связано с многопоточностью, то «предварительная вилка» должна быть безопасной, в то время как «worker» и «event» могут быть затронуты.

Если ваш профиль нагрузки позволяет это, возможно, вы можете попробовать переключиться на prefork и посмотреть, сохраняется ли проблема.

Сначала убедитесь, что хром обновлен. В более старых версиях возникают проблемы с некоторыми шифрами. У меня была эта проблема с хромом на общих сайтах, таких как Amazon и т. Д.

Во-вторых, совет запретить протоколы в «списке шифров», которому вы следовали, является очень плохой идеей, потому что он не запрещает протоколы, он запрещает большинство шифров, включая те, которые работают «начиная с» SSLv3 (но не означает, что вы включаете SSL3, если вы разрешаете шифрование SSLv3), используйте более общий список, предоставленный генератором конфигурации SSL Mozilla для совместимости (обратите внимание, что SSLv2 больше не существует или поддерживается в httpd или openssl, поэтому нет причин запрещать его явно) и, возможно, ваша предыдущая комбинация была слишком строгой , Попробуй это:

SSLProtocol             all -SSLv3
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

Если у вас все еще есть проблемы, включите отладку для SSL и посмотрите, что должен сказать httpd (отправьте только одну или две попытки и отключите это ведение журнала, это слишком шумно):

LogLevel ssl:trace3

Примечания: вы также можете удалить SSLCertificateChainFile, поскольку эта директива устарела в версии 2.4. Вы можете добавить цепочку SSLCertificateFile и отсортировать все сертификаты от листа к корневому или даже изменить SSLCertificateChainFile на SSLCACertificateFile (хотя этот в основном используется для аутентификации SSL).

Вы также должны добавить (если еще не сделали), чтобы добавить:

SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)

Изменить: после нашего разговора давайте прибегнем к проверке установки openssl и / или если это действительно та же версия, которую использует ваш httpd:

Выполните эту команду и посмотрим, что в ней написано: openssl ciphers -v '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'

Также, чтобы убедиться, что версия openssl правильная, запустите следующее:

openssl version