Настройка криптошорткатов и поддержка современных криптографических схем в Delphi 12.2 с использованием OpenSSL 1.0.2u для обеспечения безопасности соединений TLS 1.2

Delphi , Синтаксис , Шифрование

Проблемы с ECDHE-ECDSA шифрами в Indy с OpenSSL 1.0.2u и пути решения

В статье мы рассмотрим проблему отсутствия современных криптографических схем, в частности ECDHE-ECDSA, при использовании библиотеки Indy с OpenSSL 1.0.2u в Delphi 12.2. Обсудим причины возникновения проблемы, предложенные решения и возможные альтернативы.

Суть проблемы:

Пользователь столкнулся с ситуацией, когда при использовании Indy с OpenSSL 1.0.2u и принудительном использовании TLS 1.2, сервер не предлагает современные криптографические схемы, такие как ECDHE-RSA-AES256-GCM-SHA384. При использовании списка шифров, включающего ECDHE+AESGCM:ECDHE+AES256:ECDHE+AES128:RSA+AESGCM:!aNULL:!MD5:!DSS, остаются только шифры на основе RSA, а ECDHE-ECDSA отсутствуют. Это вызывает опасения по поводу безопасности соединения, поскольку ECDHE-ECDSA обеспечивает более надежный обмен ключами и forward secrecy.

Причины возникновения проблемы:

Проблема кроется в особенностях OpenSSL 1.0.2u. Судя по всему, OpenSSL 1.0.2u не поддерживает ECC (Elliptic Curve Cryptography) алгоритмы, либо они были отключены при компиляции DLL-шек из-за патентных ограничений на момент их создания. Это означает, что даже если openssl ciphers показывает поддержку ECDHE-ECDSA, это не гарантирует, что DLL-шки, используемые Indy, фактически реализуют эти шифры.

Предложенное решение (и его недостатки):

Первоначально пользователь пытался решить проблему путем обновления Indy до Indy.proposedUpdate-OpenSSLFinal. Однако, это привело к невозможности компиляции используемых библиотек TMS Sparkle и RemoteDB, которые зависят от Indy.

Альтернативное решение: Перекомпиляция OpenSSL DLL-шек

Наиболее вероятным решением является перекомпиляция DLL-шек OpenSSL 1.0.2u с включением поддержки ECC алгоритмов. Поскольку патентные ограничения, предположительно, были сняты, перекомпиляция позволит включить необходимые шифры. Это потребует наличия исходного кода OpenSSL 1.0.2u и инструментария для компиляции (например, MinGW). После успешной компиляции необходимо заменить оригинальные DLL-шки на перекомпилированные.

Пример (условный, требует адаптации к конкретной среде компиляции):

Предположим, у вас есть исходный код OpenSSL 1.0.2u и MinGW. Процесс может выглядеть следующим образом:

1. Настройка компиляции: Убедитесь, что MinGW настроен и доступен в системе.
2. Конфигурирование OpenSSL: Запустите скрипт Configure из исходного кода OpenSSL, указав необходимые параметры для включения ECC. Это может потребовать добавления флагов компиляции. Например:

./Configure --prefix=/path/to/openssl --enable-ssl --enable-ec_nistp_64_gcc_128  # Пример, требует уточнения

1. Компиляция: Запустите make для компиляции исходного кода.

make

1. Установка: Установите скомпилированные DLL-шки в подходящую директорию.

Важно: Этот процесс требует глубоких знаний работы с OpenSSL и MinGW. Неправильная компиляция может привести к нестабильной работе приложения или проблемам с безопасностью.

Рекомендации и альтернативные подходы:

• Использование Windows HTTPSys Stack: Как было отмечено в одном из обновлений, перенос приложения на использование Windows HTTPSys Stack является наиболее надежным и перспективным решением. Windows HTTPSys Stack предоставляет встроенную поддержку современных криптографических схем и регулярно обновляется Microsoft, что обеспечивает актуальность безопасности. Это требует значительных усилий по переписыванию сетевого кода, но обеспечивает долгосрочную стабильность и безопасность.

• Переход на более новую версию OpenSSL: Если возможно, рассмотрите возможность обновления OpenSSL до более новой версии, которая поддерживает современные криптографические алгоритмы и стандарты. Однако, учитывая зависимость от TMS Sparkle и RemoteDB, это может быть затруднительно.

• Проверка DLL-шек: Как предложил Remy Lebeau, необходимо проверить, какие шифры фактически поддерживаются используемыми DLL-шками OpenSSL, а не полагаться на вывод openssl ciphers. Это можно сделать, используя функции SSL_CTX_get_ciphers() или SSL_get1_supported_ciphers() непосредственно в коде.

Пример кода (Object Pascal, Delphi):

uses
  System.SysUtils,
  IdSSLOpenSSL,
  IdSSL;

procedure CheckSupportedCiphers(SSLContext: TIdSSLContext);
var
  CipherList: string;
begin
  CipherList := SSLContext.CipherList;
  //  Вывод списка поддерживаемых шифров (требуется дополнительная обработка)
  //  В данном примере только демонстрация, как получить CipherList
  Writeln('Supported Ciphers: ' + CipherList);
end;

Заключение:

Проблема отсутствия ECDHE-ECDSA шифров в Indy с OpenSSL 1.0.2u требует внимательного подхода. Перекомпиляция DLL-шек является потенциальным решением, но требует опыта и осторожности. Наиболее предпочтительным вариантом является переход на Windows HTTPSys Stack, который обеспечивает надежную и актуальную поддержку современных криптографических алгоритмов. В любом случае, необходимо тщательно проверить поддерживаемые шифры и убедиться в безопасности соединения.

Создано по материалам из источника по ссылке.

Проблема отсутствия поддержки ECDHE-ECDSA шифров в Indy с OpenSSL 1.0.2u и возможные решения, включая перекомпиляцию OpenSSL или переход на Windows HTTPSys Stack.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Шифрование ::