Поддержка криптографии на эллиптических кривых сервером dxdt.ru

dxdt.ru ECCВ рамках поддержки перспективного направления, я добавил на dxdt.ru поддержку криптосистемы ECDSA – это электронная подпись, использующая эллиптические кривые (в отличие от RSA). Для того, чтобы браузер мог использовать ECDSA, кроме поддержки браузером требуется специальный SSL-сертификат, выпущенный с подписью ECDSA. То есть, “традиционный” сертификат – не годится, так как он использует подпись RSA и, соответственно, в его составе опубликован ключ RSA, что, понятно, не позволяет применить ECDSA. (Кстати, не стоит путать ECDSA и DSA – сертификаты, использующие последнюю, в сети не встречаются, кроме редчайщих тестовых, а сама эта криптосистема признана невостребованной и вытесняется из браузеров.)

Итак, требуется сертификат, поддерживающий ECDSA – оказывается, пока что мало кто такие предлагает, хотя сертификаты удостоверяющих центров с ECC (криптографией на эллиптических кривых) есть. Я воспользовался Namecheap.com, где обнаружились относительно недорогие сертификаты Comodo PositiveSSL, для которых поддерживается ECC. Чтобы получить сертификат с ECDSA – нужно подготовить соответствующие ключи и соответствующий CSR (запрос на выпуск сертификата). Типовые CSR для RSA – не годятся: отправка такого CSR приведёт к тому, что вам выпустят RSA-сертификат. Сделать правильно можно силами OpenSSL:

$ openssl ecparam -name prime256v1 -genkey -out ec-prime256v1-private.pem

– генерирует ключ (секретный). Для ключа нужно выбрать кривую (криптосистемы используют различные кривые, из типовых наборов). Я выбрал кривую под названием prime256v1. Конечно, правильный выбор кривой – весьма важный шаг, известно, что “не все кривые одинаково полезны”. Но нужно учитывать и другие факторы: доступность кривой в сборке серверного ПО, фактические требования по защите информации. А также приходится учитывать невероятную путаницу, которая сложилась вокруг эллиптических кривых, используемых в практической криптографии. Например, prime256v1, как её называет OpenSSL, также известна как NIST P-256, кривая, рекомендованная для использования в информационных системах штатовских государственных структур – с некоторых пор, не лучший выбор. В общем, про кривые я как-нибудь напишу отдельно. Пока что на dxdt.ru используется prime256v1. Это “256-битная” кривая, что соответствет текущим представлениям об обеспечении достаточной секретности. (Естественно, ключ лучше защитить паролем.)

$ openssl req -new -key ec-prime256v1-private.pem -sha256 -out req.pem

– выводит CSR в req.pem (запрос на выпуск сертификата – этот файл нужно переслать в удостоверяющий центр). Здесь используется сгенерированный прошлой командой ключ, а также указана хеш-функция, требуемая для электронной подписи. Так как у нас “256-битная” кривая, то использовать хеш-функцию большей “размерности” смысла нет.

Полученный сертификат я сейчас установил на сервер параллельно с RSA-сертификатом, который был раньше. То есть, браузеры (или боты), которые не поддерживают ECDSA – смогут установить соединение с RSA. Сервер может отличить таких клиентов на основе списка шифронаборов, который они передают в начальной стадии соединения. Думаю, что какое-то время RSA-сертификат будет присутствовать (у меня в запасе есть бесплатный от WoSign).

Надо заметить, что dxdt.ru таким образом оказывается в числе редких сайтов, поддерживающих современные ECDSA-сертификаты. В Рунете, впрочем, таких сайтов около 7,5 тыс. (уточнение 01/08/15: это уникальных сертификатов для Рунета около 7,5 тыс.), но это сайты, использующие сервис CloudFlare, который активно продвигает ECC и автоматически подключает своим клиентам TLS (даже если их сайты не умеют поддерживать HTTPS). Отдельных веб-узлов, не CloudFlare, отдающих валидные ECDSA-сертификаты – в Рунете пока практически нет.

Адрес записки: https://dxdt.ru/2015/07/28/7573/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 2

  • 1. 29th July 2015, 17:33 // Читатель nikola написал:

    Добрый день! а можно показать конфигурацию вебсервера для одновременной поддержки двух типов сертификатов? спасибо

  • 2. 29th July 2015, 21:55 // Александр Венедюхин:

    Да, конечно.

    Я использую Apache 2.2.15 + mod_ssl под CentOS 6.6. (Рекомендовал бы Apache ветки 2.4, современной версии, потому что там лучше обстоят дела с настройками ECC; Apache 2.2.xx – вообще не должен бы уметь ECDSA и прочие штуки, но изменения были портированы в штатную ветку CentOS.)

    Вот фрагменты конфига mod_ssl (полностью ssl.conf не привожу, но настройки касаются только параметров, которые указаны ниже):

    # /etc/httpd/conf.d/ssl.conf


    ServerName dxdt.ru:443
    […]

    SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
    SSLHonorCipherOrder on
    SSLCipherSuite “-ALL:EECDH+ECDSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”

    SSLCertificateFile /etc/httpd/certs/dxdt.ru-rsa-comodo.crt
    SSLCertificateFile /etc/httpd/certs/dxdt.ru-ecdsa-comodo.crt

    SSLCertificateKeyFile /etc/httpd/pki/keys/dxdt.ru-rsa-private.key
    SSLCertificateKeyFile /etc/httpd/pki/keys/dxdt.ru-ec-prime256v1-private.key

    SSLCertificateChainFile /etc/httpd/certs/comodo-univ-bundle.crt

    То есть, я указываю оба ключа и оба сертификата, которые находятся в разных файлах. Нетривиальных моментов тут ровно два:

    1) при добавлении EC-ключа мой экземпляр Apache вдруг начинает использовать типовую группу в 1024 бита для DHE (протокола Диффи-Хеллмана). Это плохо, но, как оказалось, лечится дописыванием новых параметров DH в _начало_ файла с _RSA-сертификатом_ (параметры нужно сгенерировать openssl dhparam). Эта проблема касается только ветки 2.2, в 2.4 есть специальные опции для управления параметрами DHE (в принципе, DHE вообще можно выкинуть, заменив на ECDH(E), если только вы не поддерживаете какие-то древние клиентские конфигурации);

    2) промежуточные сертификаты придётся сложить в один файл, он обязательно должен быть отдельным от серверных сертификатов. У меня это comodo-univ-bundle.crt, куда я собрал _все_ промежуточные сертификаты – и от ECDSA, и от RSA. К сожалению, в такой конфигурации, сервер вываливает в TLS-хендшейк все промежуточные, что делает набор избыточным (да и вообще – некрасиво), но как это в Apache 2.2 побороть – я пока не придумал.