OpenSSL, проверка настроек сервера, шифры ECDHE

Пару попутных комментариев при очередном апдейте openssl на серверах…

OpenSSL поддерживает криптографию на эллиптических кривых начиная с версии 1.0.0. В базе FreeBSD до сих пор поставляют старую 0.9.8, новую нужно ставить из портов. Для того чтобы новые пакеты при сборке использовали новую версию openssl установленную их портов надо в /etc/make.conf добавить строчку WITH_OPENSSL_PORT=yes.

Если это первая установка openssl из портов, то нужно пересобрать все пакеты зависящие от OpenSSL для того что бы они связались с новыми версиями библиотеки.

Добавляем запись и пересобираем OpenSSL

Пройдемся быстренько по опциям

Со всякими оптимизациями все понятно, SCTP мне не нужен. ZLIB – поддержка компрессии, для веб-серверва не нужна, он обычно сам пакует, но для почтовика или для ssl vpn-клиентов работающих по tls/dtls может быть весьма полезна. RFC3779 – расширения X.509 для привязки ip-префиксов и номеров AS к сабжу сертификата, мне не надо. EC – набор оптимизированных под 64bit эллиптических кривых, работают чуть пошустрее (ссылка на тест внизу).

Из консоли бинарник будет вызываться старый, а это нам не надо.

Переопределим алиас для дальнейшей работы.

После установки из портов новый OpenSSL свои бинарники кладет в /usr/local/ а настройки ищет в /usr/local/openssl/.

Еще может пригодиться пакет ca_root_nss с корневыми сертификатами от мозиллы для проверки сертификатов подписаных “доверенными” центрами сертификации. Обновляем/ставим..

portupgrade ca_root_nss

После уставновки “оно” сделалает симлинк на сертификаты в /etc/ssl/

Посмотрим список алгоритмов

openssl ciphers -v

Теперь можно проверить поддержку шифров/протоколов/сертификатов на серверах с поддержкой SSL.
Проверим, к примеру, гуглю

Все ОК, установилось соединение по протоколу TLSv1.2, Secure Renegotiation поддерживается. Набор криптоалгоритмов ECDHE-RSA-RC4-SHA – обмен Диффи-Хеллмана эфемерными ключами на эллиптических кривых с rsa подписью, а значит у нас есть PFS. Гугл молодец, вовремя обновляет SSL-библиотеки и держит на почтовиках нормальный подписаный сетификат. А приоритет шифру RC4 они похоже выставили чтобы защитить старых клиентов от BEAST уязвимости, не на ресурсах процессоров же они экономят?

Проверить свой собственный сертификат подписаный промежуточными CA можно так:

Проверим сами себя на рабочем сервере и убедимся что цепочка отдается верно:

========

Тут тоже все ОК – TLSv1.2, zlib сжатие, обмен ключами на эллиптических кривых и aes в режиме GC, цепочка сертификатов сервера прошла проверку.

Из наших “популярных” почтовиков ни яндекс ни меил.ру ssl на MXах не поддерживают – ресурсы экономят чтоли…

Посмотрим на почтовик сбербанка

Интересно, TLSv1 и aes128 с rsa, при этом сетфикат у сервера есть, выдан на имя сервера и подписан у тавта.
А если ему сказать я что кроме DH на эллиптических кривых ничего не умею?

Эллиптические кривые умею… тлс1.2 не умею… Ну и ладно, для почтовика это не критично, в конце концов smtp может и “голышем” бегать. Бывают случаи и пострашнее… Как-то давным-давно я проверял https на сервере альфаклика – там все было “красиво”, на сервере не закрыли анонимные шифры и beast уязвимость. Ну черт с ним с бистом, про него никто не знал, но пропарить в конфиге анонимные шифры? Клиент клика будет видеть зеленую адресную строку с дорогущим авторизованым сертификатом удостоверяющим организацию, а в канале передачи данных будет сидеть посредник. Клиентов альфаклика от тотального факапа спасало только то что по-умолчанию в браузерах запрещено анонимное шифрование. И для успешного проведения атаки клиенту сначала нужно “впарить” браузер с доступными шифрами без аутентификации, но ведь это гораздо проще чем подделать сертификат? Я писал в поддержку два раза но меня похоже так и не поняли… Интересно с тех пор что-нибудь изменилось? А давайте проверим? 😉

Смотри, починили… молодцы… Жаль я тогда скриншотов не понаделал, теперь никто не поверит :). Вот еще похожий случай.

Немного ссылок:
SSL/TLS & Perfect Forward Secrecy

OpenSSL Command-Line HOWTO

Mitigating the BEAST attack on TLS

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">