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

7

У меня есть свой собственный сервер (на котором я работаю Apache/2.4.27), и сегодня я понял, что с (Brave и Google Chrome - разные компьютеры) я получаю с моих сайтов эту ошибку;

This site can’t provide a secure connection

mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

И странно то, что я получаю эту ошибку каждый пятый клик на моем сайте.

Из моего файла conf:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mywebsite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
SSLCompression off

от options-ssl-apache.conf;

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder     on
SSLCompression          off

Я проверил файл журнала с сайта, но ничего, здесь тоже ничего нет; /var/log/apache2/error.log

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

РЕДАКТИРОВАТЬ:

Если я попытаюсь openssl s_client -connect mywebsite.com:443, он вернется:

Я использую: OpenSSL 1.1.0f

CONNECTED(00000003)

...

3073276480:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:469:

ДРУГОЕ РЕДАКТИРОВАНИЕ:

Как предложил @quadruplebucky, я изменил options-ssl-apache.conf на:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite           HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder     on
SSLCompression          off

#SSLSessionTickets       off

Я также попытался добавить SSLProtocol all -SSLv2 -SSLv3в свой файл conf Virtualhost, и в то же время я изменил пару вещей здесь;/etc/apache2/mods-available/ssl.conf

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

SSLHonorCipherOrder on

#   The protocols to enable.
#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
#   SSL v2  is no longer supported
SSLProtocol all -SSLv2 -SSLv3

РЕДАКТИРОВАТЬ:

После изменения LogLevel в Infoнего возвращается:

[Sat Jul 08 13:34:53.374307 2017] [ssl:info] [pid 8710] [client] AH02008: SSL library error 1 in handshake (server mywebsite:443)
[Sat Jul 08 13:34:53.374717 2017] [ssl:info] [pid 8710] SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
[Sat Jul 08 13:34:53.374750 2017] [ssl:info] [pid 8710] [client] AH01998: Connection closed to child 1 with abortive shutdown (server mywebsite:443)

РЕДАКТИРОВАТЬ:

Если я запускаю с опцией -crlf, вот так:

openssl s_client -crlf -connect mywebsite:443

Я не получаю ошибку?

Еще одна вещь, если я изменю LogLevel на debug, до этой ошибки я получаю следующее:

[Tue Jul 11 23:00:38.641568 2017] [core:debug] [pid 26561] protocol.c(1273): [client 188.64.25.162:23165] AH00566: request failed: malformed request line
[Tue Jul 11 23:00:38.641634 2017] [headers:debug] [pid 26561] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()

После этого произойдет та же ошибка:

SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message

openssl version
OpenSSL 1.1.0f  25 May 2017
user134969
источник
Это не должно быть возможным для любой ошибки конечной конфигурации к «плохим шифрованию или макинтош» причины (оповещения 20). Есть ли что-нибудь в сети между этими клиентами и этим сервером, например, брандмауэр, IDS, IPS, DLP или даже «умный» маршрутизатор? Можете ли вы проверить несколько раз (так как это может зависеть от данных и, следовательно, квазислучайно) подключение с самого сервера или с компьютера в том же сегменте, что и сервер?
dave_thompson_085
покажите соответствующее содержимое виртуального хоста * .443 (весь виртуальный хост, если необходимо), а также вывод «apachectl -S», чтобы мы могли отменить неверную конфигурацию.
Ездра
сообщение об ошибке жалуется на SSL v3, но в вашей конфигурации он отключен ...
alexus
Вы говорите, что используете OpenSSL 1.1.0f. Это как на сервере, так и на машине, где вы ввели команды s_client выше? На какой платформе работает ваш сервер? Возможно, вы захотите узнать, возникает ли ошибка с определенными наборами шифров, например, что произойдет, если вы добавите "-cipher AES128-SHA" в конец вашей команды s_client?
Мэтт Касвелл
ninjaed: @alexus: имена функций и файлов, а также некоторые литералы ssl3*и SSL3*в OpenSSL также используются для TLS (от 1.0 до 1.2) из-за технических сходств между этими протоколами. user134969: 'длина слишком короткая' также никогда не должна вызываться никаким конфигом. Если это повторяется, пожалуйста, попробуйте получить s_client -debug(с обычным RSA, -cipherесли вы не сделали этого на сервере) и захват Wireshark для того же события, чтобы мы могли посмотреть на фактические данные проводника и сравнить их с тем, что видит программа.
dave_thompson_085

Ответы:

8

По этой ошибке нельзя определить, ведет ли ваш сервер переговоры по 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» SSL, а не cookie-файла сеанса или подобного). Ошибка «каждый пятый щелчок» все еще беспокоит меня - я не могу не заметить, что большинство браузеров передают четыре запроса ресурсов в одном ...) и открывают новое соединение (новое рукопожатие ssl и т. Д.) для пятого ... без захвата пакета трудно сказать, что на самом деле происходит.

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

Другие инструменты отладки, которые я бы попробовал (предполагая, что публикация перехватов пакетов исключена ...)
- ssltaplibnss3-toolsUbuntu)
- cipherscan
- sslscan

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

quadruplebucky
источник
1
Я бы также поиграл с более явными объявлениями SSLCipherSuite (в соответствии с тем, что генерирует конфигурация Mozilla), установил LogLevel на info или debug, tcpdump / wireshark pcaps, etcetera, что угодно, чтобы понять, что на самом деле происходит.
quadruplebucky
1
Почему бы вам не попробовать такой инструмент, как cipherscan github.com/mozilla/cipherscan или sslscan github.com/rbsec/sslscan (также во многих репозиториях), чтобы попытаться выяснить, что на самом деле происходит, прежде чем регрессировать?
quadruplebucky
С SSLProtocol -SSLv3подключением определенно не было SSL3. Помните, что в OpenSSL функции (и исходные файлы), названные с помощью ssl3, все еще являются частью всех протоколов TLS до 1.2. Удаление шифров SSLv3 (и TLSv1 только в 1.1.0) фактически предотвращает согласование любого протокола ниже TLS1.2, но с современными браузерами, которые должны быть в порядке.
dave_thompson_085
@ user134969: чтобы wireshark расшифровал эти соединения (и, таким образом, помог бы вам в этом), вам необходимо (временно) ограничить обмен ключами обычным RSA; это проще всего сделать на стороне Apache SSLCiphers RSA+AES. (И предоставьте файл закрытого ключа сервера в Edit / Preferences / Protocols / SSL.) Chrome раньше жаловался на обычный RSA (то есть не PFS), но я только что проверил, и мой, кажется, теперь счастлив.
dave_thompson_085
@quadruplebucky Можете ли вы указать мне, где находится "ssl3_record.c" в системе?
user134969
6

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

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

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

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

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

ethtool -K eth0 tso off gro off gso off ufo off
Мэтью Ифе
источник
Он возвращает: Невозможно изменить udp-fragmentation-offload
user134969
Сделайте то же самое, но пропустите «НЛО»
Мэтью Ифе
1
Еще одна достаточно глупая вещь, которая может привести к усечению пакетов, - это проблемы с MTU (когда не должно быть больших кадров, когда требуется включение), или перехват MSS, требуемый по TCP, если вы отправляете свои данные по туннелю.
Мэтью Ифе
3

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

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

Андреас Рогге
источник
так что, по крайней мере, многопоточность исключена :)
Андреас Рогге
0

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

Во-вторых, совет запретить протоколы в «списке шифров», которым вы следовали, является очень плохой идеей, потому что он не запрещает протоколы, он запрещает большинство шифров, включая те, которые работают «начиная с» 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 (отправьте только 1 попытку или две и отключите эту запись, это слишком шумно):

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
Ezra-ы
источник
Нет, не решил - проверьте мои правки, я разместил журнал при использовании ssl: trace3 ...
user134969
является openssl скомпилированной или скомпилированной вручную версией?
Ездра
@ user134969 Я добавляю команду, чтобы вы могли видеть, есть ли у вас в наличии стандартные шифры или достаточно шифров, если есть проблемы с ними.
Ездра