Поддержка криптографии на эллиптических кривых сервером dxdt.ru
В рамках поддержки перспективного направления, я добавил на 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/
Похожие записки:
- Ретроспектива заметок: февраль 2008 года
- Записки за сентябрь 2024
- Общее представление о шифрах и бэкдоры
- Различительная способность "обезличенных" данных
- TLS и подмена сертификата на jabber.ru
- Многобайтовые постквантовые ключи и TLS
- Влияние систем ИИ на процессы в мире
- Подводные кабели и связность Интернета
- ИИ для принятия решений
- Удаление "неактивных" google-аккаунтов
- TLS-сертификаты dxdt.ru
Комментарии читателей блога: 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 побороть – я пока не придумал.