Ошибка Curl NSS / SSL после обновления

Содержание

Вопрос или проблема
Ответ или решение
Описание проблемы
Возможные решения
Вывод

Вопрос или проблема

Я использую нестандартный внутренний сервер аутентификации. С последним раундом обновлений он начал выдавать ошибки, по-видимому, из-за изменения шифров. Это на сервере с CentOS6, полностью обновленном.

curl https://crowd.test.org:8443 \
   --cacert /etc/pki/ca-trust/source/anchors/ca.crt \
   -vvv
* About to connect() to crowd.test.org port 8443 (#0)
*   Trying 192.XXX.XXX.XXX... connected
* Connected to crowd.test.org (192.XXX.XXX.XXX) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/ca-trust/source/anchors/ca.crt
  CApath: none
* NSS error -12173
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
You have mail in /var/mail/root

Я проверил с помощью nmap и нашел поддерживаемый шифр, TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Проверил это на сайте curl и обнаружил, что следующее действительно работает.

curl https://crowd.mydomain.org:8443 --cacert \
  /etc/pki/ca-trust/source/anchors/ca2.crt \
  -vvv --tlsv1.0 --ciphers rsa_aes_128_sha

Как мне это исправить? Я уже использовал метод понижения, который традиционно использовал, но безуспешно.

yum history 
yum history undo 106

Основываясь на https://mozilla.github.io/python-nss-docs/nss.error-module.html, похоже, это означает, что сервер использует слабый эфемерный ключ Диффи-Хеллмана:

SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY = -12173

На серверах, где я видел эту ошибку, это действительно было так.

Ответ или решение

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

Описание проблемы

Контекст: При попытке подключения с помощью curl к внутреннему аутентификационному серверу, находящемуся на машине CentOS 6, возникает ошибка SSL.
Диагностика: В результате выполнения запроса curl, ошибка появляется следующим образом:
- NSS error -12173: Это свидетельствует о том, что сервер использует слабый временный ключ Диффи-Хеллмана, что не допускается текущими стандартами безопасности.
Проверка: Использование nmap подтвердило наличие поддержки шифра TLS_DHE_RSA_WITH_AES_128_CBC_SHA, что указывает на проблемы со старыми или неподходящими криптографическими параметрами на сервере.

Возможные решения

Обновление конфигурации сервера:
- Настройка более сильных шифров: Проверьте конфигурацию вашего сервера, чтобы он поддерживал более современные и безопасные шифровальные пакеты. Например, рекомендуется поддержка шифров на основе ECDHE.
- Замена временных ключей DH: Следует сгенерировать новые, более сильные DH параметры. Обычно это файл dhparam.pem, который можно создать с помощью команды openssl dhparam -out dhparam.pem 2048.
Обновление серверного программного обеспечения:
- Если ваше серверное программное обеспечение устарело и не поддерживает последние алгоритмы шифрования, рассмотрите возможность его обновления до более поздних версий, которые обеспечивают необходимую поддержку современных криптографических стандартов.
Обновление клиента:
- Если серверная часть уже обновлена, стоит проверить и обновить сам клиент curl и связанные библиотеки (например, NSS) до последней версии, совместимой с текущими стандартами безопасности. Это может потребовать пересборки curl с новым набором шифров.
Временное решение:
- Если обновление невозможно в данный момент, вы можете продолжать использовать совместимые шифры, как вы это сделали, добавив параметр --ciphers rsa_aes_128_sha, хотя это не рекомендуется в долгосрочной перспективе.

Вывод

Решение данной проблемы требует сбалансированного подхода, учитывающего безопасность и особенности вашей инфраструктуры. Обновление сертификатов и поддержка современных шифровальных стандартов должны быть приоритетными, так как они обеспечивают защиту от известных уязвимостей. Помимо технических мер, следует провести аудит безопасности, чтобы минимизировать риски эксплуатации устаревшего программного обеспечения.

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