воскресенье, 29 января 2017 г.

Высокая безопасность SSL в Lighttpd

Перевод: Stong SSL Security on lighttpd
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Смягчение атак BEAST
  2. Факторизация ключей RSA-EXPORT (FREAK)
  3. Logjam (DH EXPORT)
  4. Heartbleed - кровоточащее сердце
  5. Сжатие SSL
  6. SSLv2 и SSLv3
  7. Poodle и TLS-FALLBACK-SCSV
  8. Набор шифров
  9. Логика приоритезации
  10. Явный запрет
  11. Forward Secrecy и параметры эфемерного Диффи-Хеллмана
  12. HSTS - строгая безопасность транспорта HTTP
  13. HKPK - расширение для фиксации публичного ключа HTTP
  14. Заключение


В этом руководстве показано, как настроить высокую безопасность SSL на веб-сервере Lighttpd. Для этого мы обновим OpenSSL до самой свежей версии, чтобы избежать атак Heartbleed, отключим сжатие SSL и шифры EXPORT, чтобы избежать атак FREAK, CRIME и Logjam, отключим SSL версии 3 и ниже, потому что эти протоколы уязвимы и зададим строгий набор шифров, который по возможности включает Forward Secrecy. Мы также включим HSTS и HPKP. Таким образом мы получим стойкую конфигурацию SSL с богатыми возможностями защиты и получим оценку A+ в тесте Qually Labs SSL.

Я написал веб-приложение с открытым исходным текстом для проверки SSL-серверов. Можно воспользоваться им для проверки конфигурации в дополнение к другим проверкам SSL. Проверка быстрая и отображает всю информацию, которая позволит принять собственное обоснованное решение (без оценок), а результаты сохраняются, так что можно сравнивать различные настройки. Сайт можно проверить по адресу https://ssldecoder.org.

Я также написал удобное веб-приложение, которое уведомляет о скором завершении срока действия сертификата. Исходные тексты открыты, поэтому можно разместить его локально. Уже установленное веб-приложение доступно по адресу https://certificatemonitor.org.

И наконец, я создал веб-сайт с примерами настройки стойких шифров для nginx, Apache, Lighttpd и для другого программного обеспечения: https://cipherli.st. Сайт может пригодиться, если нет времени читать это руководство целиком. Это руководство и веб-сайт https://cipherli.st обновляются по мере обнаружения новых уязвимостей.

Это руководство удовлетворяет строгими требованиями теста SSL Labs, выпущенного 21 января 2014 (Я уже прошёл этот тест, поэтому если вы последуете рекомендациям, то получите оценку A+).
Вы сможете найти дополнительную информацию по затронутым темам по следующим ссылкам:
Убедитесь, что вы сняли резервные копии со всех файлов, которые собираетесь редактировать!

На этом веб-сайте я использую Lighttpd 1.4.31 из репозитория Debian Wheezy. Версии из CentOS 5/6 EPEL мне не подошли, поскольку и Lighttpd и OpenSSL в них слишком старые. Debian Squeeze тоже не подошёл.

Смягчение атак BEAST

Вкратце: при взломе алгоритмов блочного шифрования части зашифрованного трафика могут быть тайно расшифрованы. Больше информации можно узнать по ссылке.

В новых версиях браузеров включено смягчение атаки BEAST со стороны клиента. Рекомендуется выключить все шифры TLS 1.0 и предлагать только RC4. Однако, [список атак против RC4 растёт],(http://www.isg.rhul.ac.uk/tls/) многие из них становятся осуществимыми на практике. Более того, есть причины считать, что АНБ взломало RC4, назвав это "большим прорывом".

Отключение RC4 влечёт за собой несколько последствий. Во-первых, пользователи говнобраузеров Internet Explorer в Windows XP вместо него будут использовать 3DES. Triple-DES более безопасен по сравнению с RC4, но обходится значительно дороже. Веб-сервер заплатит цену за этих пользователей. Во-вторых, RC4 смягчает BEAST. Но отключение RC4 делает пользователей TLS 1.0 подверженными этой атаке, заставляя их использовать AES-CBC (обычно от этого защищает приоритет со стороны сервера, настаивающий на использовании RC4). Но я уверен, что сам RC4 несёт в себе больше рисков, чем риск от атак BEAST. Действительно, смягчения со стороны клиента (которые имеются в Chrome и Firefox), избавляют от BEAST. Но риск от использования RC4 со временем только возрастает: криптоаналитики выявляют всё больше проблем.

Факторизация ключей RSA-EXPORT (FREAK)

FREAK - это уязвимость типа "человек в середине", обнаруженная группой криптографов из INRIA, Microsoft Research и IMDEA. FREAK означает "Factoring RSA-EXPORT Keys" - факторизация ключей RSA-EXPORT.

Уязвимость ведёт историю с 1990-х годов, когда правительство США запретило продажу программных криптографических средств за границу, если в них используются наборы шифров с ключами длиннее 512-бит.

Оказалось, что некоторые современные клиенты TLS, включая SecureTransport от Apple и OpenSSL, содержат ошибку. Эта ошибка приводит к тому, что применяются ключи RSA экспортного класса, даже если клиент не запрашивает экспортный класс RSA. Воздействие этой ошибки может быть очень неприятным: это позволяет "человеку в середине" реализовать атаку, в результате которой атакующий сможет понизить безопасность соединения, если клиент имеет уязвимость, а сервер поддерживает экспортный RSA.

Для атаки необходимо выполнение двух условий, поскольку сервер тоже должен принимать "RSA экспортного класса".

Человек в середине атакует следующим образом:
  • В приветственном сообщении клиент запрашивает обычный шифр RSA.
  • Человек в середине меняет это сообщение на запрос RSA экспортного класса.
  • Сервер возвращает в ответе 512-битный ключ RSA экспортного класса, подписанный его долгосрочным ключом.
  • Клиент принимает этот слабый ключ из-за ошибки в OpenSSL/SecureTransport.
  • Атакующий факторизует модуль RSA, чтобы восстановить соответствующий ключ RSA для дешифрования.
  • Когда клиент шифрует премастер-секрет, то атакующий может расшифровать его, чтобы восстановить мастер-секрет TLS.
  • С этого момента атакующий может расшифровывать передаваемую информацию и может подменять её.
Предложенный здесь набор шифров не включает класс шифров EXPORT. Убедитесь, что OpenSSL обновлён до последней доступной версии и заставьте клиентов обновить их программное обеспечение.

Logjam (DH EXPORT)

Исследователи из нескольких университетов и институтов провели исследования, в результате которых в протоколе TLS были найдены проблемы. В отчёте этих исследователей сообщается о двух способах атаки.

Обмен ключами Диффи-Хеллмана позволяет в зависимости от TLS согласиться на общий ключ и согласовать безопасный сеанс через незащищённое подключение.

Первая угроза заключается в том, что человек в середине может ослабить уязвимое подключение TLS до 512-битной криптографии экспортного класса, что позволит атакующему читать и изменять данные. Вторая угроза основывается на том, что многие серверы используют одинаковые простые числа для обмена ключами Диффи-Хеллмана, вместо того, чтобы каждый раз создавать свои собственные новые уникальные параметры.

Команда оценила, что академические команды способны взломать 768-битные простые числа, а на государственном уровне возможно взломать 1024-битные простые числа. Взлом одного 1024-битного простого числа позволит прослушивать до 18 процентов из миллиона самых популярных доменов HTTPS. Взлом второго простого числа позволит открыть до 66 процентов VPN-подключений и до 26 процентов SSH-серверов.

Далее в этом руководстве мы создадим собственные уникальные параметры Диффи-Хеллмана и воспользуемся набором шифров, который исключает шифры класса EXPORT. Убедитесь, что OpenSSL обновлён до самой свежей версии и заставьте клиентов обновить их программное обеспечение. Обновлённые браузеры для устранения проблемы отклоняют параметры Диффи-Хеллмана короче 768/1024 бит.

У Cloudflare есть подробное руководство по Logjam.

Heartbleed - кровоточащее сердце

Heartbleed - это ошибка безопасности, обнаруженная в апреле 2014 года в криптографической библиотеке OpenSSL, которая широко используется для реализации протокола TLS. Уязвимостью Heartbleed можно воспользоваться вне зависимости от того, используется ли уязвимая версия OpenSSL для TLS на сервере или на клиенте. Ошибка заключается в недостаточной проверке входных данных (из-за отсутствия проверки границ) в реализации расширения сердцебиения DTLS (RFC6520), из-за чего ошибка получила название heartbleed ("кровоточащее сердце", что созвучно названию расширения heartbeet - "сердцебиение"). Уязвимость классифицируется как чтение за пределами буфера - случай, когда можно прочитать больше информации, чем должно быть разрешено.

Какие версии OpenSSL затрагивает Heartbleed?

Состояние различных версий:
  • OpenSSL 1.0.1 и до 1.0.1f (включительно) уязвимы
  • OpenSSL 1.0.1g НЕ уязвима
  • Ветка OpenSSL 1.0.0 НЕ уязвима
  • Ветка OpenSSL 0.9.8 НЕ уязвима
Ошибка была добавлена в OpenSSL в декабре 2011 и встречалась в дикой природе начиная с релиза OpenSSL 1.0.1 от 14 марта 2012 года. Ошибка была исправлена в выпуске OpenSSL 1.0.1g от 7 апреля 2014 года.

Защититься от уязвимости можно обновив OpenSSL.

Сжатие SSL

Атака CRIME для своего тёмного дела использует сжатие SSL, поэтому его нужно отключить. Следующая опция отключит сжатие SSL:
ssl.use-compression = "disable"
По умолчанию сжатие SSL отключается в процессе компиляции Lighttpd. Если вы обнаружили, что оно включено, то либо воспользуйтесь указанной выше опцией, либо пересоберите OpenSSL без поддержки ZLIB. Таким образом в OpenSSL будет выключен метод сжатия DEFLATE. Даже после этого можно по-прежнему использовать обычное сжатие HTML DEFLATE.

SSLv2 и SSLv3

SSL версии 2 небезопасен, поэтому нужно отключить его. Мы также отключим SSL версии 3, поскольку TLS 1.0 содержит возможность переключиться атакующему на использование SSL версии 3, а затем отключить forward secrecy.

Итак, отредактируем файл конфигурации:
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Poodle и TLS-FALLBACK-SCSV

SSL версии 3 позволяет воспользоваться ошибкой POODLE. Это одна из важных причин для его отключения.

Google предложил расширение для SSL/TLS, которое называется TLSFALLBACKSCSV и позволяет предотвратить переключение на более слабые возможности SSL. Оно автоматически включается по умолчанию при обновлении OpenSSL до одной из указанных версий:
  • OpenSSL 1.0.1 поддерживает TLSFALLBACKSCSV в 1.0.1j и выше.
  • OpenSSL 1.0.0 поддерживает TLSFALLBACKSCSV в 1.0.0o и выше.
  • OpenSSL 0.9.8 поддерживает TLSFALLBACKSCSV в 0.9.8zc и выше.
Набор шифров

Forward Secrecy - прямая секретность - гарантирует целостность сеансового ключа в ситуации, когда скомпрометирован долгосрочный ключ. Perfect Forward Secrecy - совершенно прямая секретность - достигается тем, что для каждого сеанса выводится новый ключ.

Это означает, что при компрометации приватного ключа нельзя воспользоваться им для расшифровки записанного трафика SSL.

Наборы шифров, предоставляющие Perfect Forward Secrecy - это те, которые используют эфемерный обмен ключами Диффи-Хеллмана. Их недостаток - это накладные расходы, которые можно снизить использованием вариантов на эллиптических кривых.

Я рекомендую следующие два набора шифров, а после меня их стали рекомендовать и Mozilla Foundation.

Рекомендуемый набор шифров:
ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH"
Рекомендуемый набор шифров для обратной совместимости (IE6/WinXP):
ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
В старых версиях OpenSSL недоступные шифры будут пропущены автоматически. Всегда используйте полный набор шифров, указанных выше и позвольте OpenSSL выбирать те из них, которые поддерживаются.

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

Более старые версии OpenSSL могут не возвращать полный список алгоритмов. Алгоритмы AES-GCM и некоторые виды ECDHE появились сравнительно недавно и отсутствуют в большинстве версий OpenSSL, поставляемых в составе Ubuntu или RHEL.

Логика приоритезации
  • Шифры ECDHE+AESGCM выбираются в первую очередь. Это шифры TLS 1.2. В настоящее время для этих шифров нет известных способов атаки.
  • Предпочитаются наборы шифров PFS сначала с ECDHE, а затем с DHE.
  • AES 128 более предпочтителен, чем AES 256. Есть мнение, что дополнительная степень безопасности AES256 имеет высокую цену при не очевидном результате. На данный момент предпочтительнее AES128, потому что он предоставляет хорошую безопасность, сравнительно быстр и, похоже, более устойчив к атакам по времени.
  • В наборах шифров для обратной совместимости AES предпочтительнее, чем 3DES. Атаки BEAST смягчены в TLS 1.1 и выше, а в TLS 1.0 труднореализуемы. В наборах шифров без обратной совместимости 3DES отсутствует.
  • RC4 удалён полностью. 3DES используется для обратной совместимости. Обратитесь к обсуждению по ссылке #RC4_weaknesses
Явный запрет
  • aNULL содержит не аутентифицированный обмен ключами Диффи-Хеллмана, поэтому подвержены атакам типа "человек в середине".
  • eNULL содержит шифры без шифрования (данные передаются открытым текстом).
  • EXPORT - это устаревшие слабые шифры, которые помечены как разрешённые для экспорта по законам США.
  • RC4 содержит шифры, которые используют устаревший алгоритм ARCFOUR.
  • DES содержит шифры, которые используют устаревший стандарт шифрования данных - Data Encryption Standard.
  • SSLv2 содержит все шифры, которые были определены в старой версии стандарта SSL, ныне устаревшего.
  • MD5 содержит все шифры, которые используют устаревший алгоритм проверки целостности - message digest 5.
Forward Secrecy и параметры эфемерного Диффи-Хеллмана

Концепция Forward Secrecy проста: клиент и сервер согласуют ключ, который никогда не передаётся по сети и уничтожается при завершении сеанса. Приватный RSA-ключ сервера используется для подписи обмена ключами Диффи-Хеллмана между клиентом и сервером. Премастер-ключ получается из рукопожатия Диффи-Хеллмана, а затем используется для шифрования. Поскольку премастер-ключ относится к подключению между клиентом и сервером и используется только ограниченное время, он называется эфемерным.

При использовании Forward Secrecy - прямой секретности, если атакующий получит приватный ключ сервера, он не сможет расшифровать последующий обмен данными. Приватный ключ используется только для подписи рукопожатия Диффи-Хеллмана, которое не раскрывает премастер-ключ. Диффи-Хеллман гарантирует, что премастер-ключ никогда не покинет клиента и сервер и поэтому не сможет быть перехвачен "человеком в середине".

Все версии Lighttpd, по состоянию на момент выхода версии 1.4.7, полагаются на входные параметры для протокола Диффи-Хеллмана из OpenSSL. Поэтому эфемерный протокол Диффи-Хеллмана будет использовать настройки по умолчанию из OpenSSL, которые включают использование 1024-битного ключа для обмена ключами. Поскольку мы используем 2048-битный сертификат, клиенты, использующие эфемерный протокол Диффи-Хеллмана, будут использовать более слабый обмен ключами, чем клиенты, использующие не эфемерный протокол Диффи-Хеллмана.

Нам нужно сгенерировать более стойкие параметры для эфемерного протокола Диффи-Хеллмана:
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096
Добавим их в конфигурацию Lighttpd:
ssl.dh-file = "/etc/ssl/certs/dhparam.pem"
ssl.ec-curve = "secp384r1"
HSTS - строгая безопасность транспорта HTTP

По возможности лучше включить строгую безопасность транспорта HTTP (HSTS), которая предписывает браузеру связываться с сайтом только через HTTPS.

Обратитесь к моей статье по HSTS, чтобы узнать, как её настроить.

HKPK - расширение для фиксации публичного ключа HTTP

Также стоит включить расширение для фиксации публичного ключа HTTP.

Фиксация публичного ключа означает, что цепочка сертификатов должна включать публичный ключ из белого списка. Это гарантирует, что сертификаты для *.example.com могут быть подписаны только удостоверяющими центрами из белого списка, но не какими-либо другими удостоверяющими центрами из хранилища в браузере.

Я написал статью с объяснением теории и примерами конфигурации для Apache, Lighttpd и nginx.

Заключение

Чтобы указанные выше строчки файла конфигурации вступили в силу, нужно перезапустить Lighttpd:
/etc/init.d/lighttpd restart
Теперь воспользуемся проверкой SSL Labs, чтобы увидеть рейтинг A+. И, конечно, у нас получилась безопасная и строгая конфигурация SSL с запасом на будущее!

воскресенье, 22 января 2017 г.

Высокая безопасность SSL в nginx

Перевод: Strong SSL Security on nginx
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Атака BEAST и RC4
  2. Факторизация ключей RSA-EXPORT (FREAK)
  3. Logjam (DH EXPORT)
  4. Heartbleed
  5. Сжатие SSL (атака CRIME)
  6. SSLv2 и SSLv3
  7. Poodle и TLS-FALLBACK-SCSV
  8. Набор шифров
  9. Логика приоритезации
  10. Явный запрет
  11. Дополнительные настройки
  12. Forward Secrecy и параметры эфемерного Диффи-Хеллмана
  13. Вшивание OCSP
  14. HSTS - строгая безопасность транспорта HTTP
  15. HPKP - расширение для фиксации публичного ключа HTTP
  16. Заключение


В этом руководстве показано, как настроить высокую безопасность SSL на веб-сервере nginx. Для этого мы обновим OpenSSL до самой свежей версии, чтобы избежать атак Heartbleed, отключим сжатие SSL и шифры EXPORT, чтобы избежать атак FREAK, CRIME и Logjam, отключим SSL версии 3 и ниже, потому что эти протоколы уязвимы и зададим строгий набор шифров, который по возможности включает Forward Secrecy. Мы также включим HSTS и HPKP. Таким образом мы получим стойкую конфигурацию SSL с богатыми возможностями защиты и получим оценку A+ в тесте Qually Labs SSL.

Я написал веб-приложение с открытым исходным текстом для проверки SSL-серверов. Можно воспользоваться им для проверки конфигурации в дополнение к другим проверкам SSL. Проверка быстрая и отображает всю информацию, которая позволит принять собственное обоснованное решение (без оценок), а результаты сохраняются, так что можно сравнивать различные настройки. Сайт можно проверить по адресу https://ssldecoder.org.

Я также написал удобное веб-приложение, которое уведомляет о скором завершении срока действия сертификата. Исходные тексты открыты, поэтому можно разместить его локально. Уже установленное веб-приложение доступно по адресу https://certificatemonitor.org.

И наконец, я создал веб-сайт с примерами настройки стойких шифров для nginx, Apache, Lighttpd и для другого программного обеспечения: https://cipherli.st. Сайт может пригодиться, если нет времени читать это руководство целиком. Это руководство и веб-сайт https://cipherli.st обновляются по мере обнаружения новых уязвимостей.

Это руководство удовлетворяет строгими требованиями теста SSL Labs, выпущенного 21 января 2014 (Я уже прошёл этот тест, поэтому если вы последуете рекомендациям, то получите оценку A+).
Вы сможете найти дополнительную информацию по затронутым темам по следующим ссылкам:
Мы будем редактировать настройки nginx в файле /etc/nginx/sited-enabled/yoursite.com (в Ubuntu/Debian) или в файле /etc/nginx/conf.d/nginx.conf (в RHEL/CentOS).

Во всём руководстве нужно редактировать содержимое блока, настраивающего сервер на порту 443. В конце руководства можно найти полный пример конфигурации.

Убедитесь, что вы сняли резервные копии со всех файлов, которые собираетесь редактировать!

Атака BEAST и RC4

Вкратце: при взломе алгоритмов блочного шифрования части зашифрованного трафика могут быть тайно расшифрованы. Больше информации можно узнать по ссылке.

В новых версиях браузеров включено смягчение атаки BEAST со стороны клиента. Рекомендуется выключить все шифры TLS 1.0 и предлагать только RC4. Однако, [список атак против RC4 растёт],(http://www.isg.rhul.ac.uk/tls/) многие из них становятся осуществимыми на практике. Более того, есть причины считать, что АНБ взломало RC4, назвав это "большим прорывом".

Отключение RC4 влечёт за собой несколько последствий. Во-первых, пользователи говнобраузеров Internet Explorer в Windows XP вместо него будут использовать 3DES. Triple-DES более безопасен по сравнению с RC4, но обходится значительно дороже. Веб-сервер заплатит цену за этих пользователей. Во-вторых, RC4 смягчает BEAST. Но отключение RC4 делает пользователей TLS 1.0 подверженными этой атаке, заставляя их использовать AES-CBC (обычно от этого защищает приоритет со стороны сервера, настаивающий на использовании RC4). Но я уверен, что сам RC4 несёт в себе больше рисков, чем риск от атак BEAST. Действительно, смягчения со стороны клиента (которые имеются в Chrome и Firefox), избавляют от BEAST. Но риск от использования RC4 со временем только возрастает: криптоаналитики выявляют всё больше проблем.

Факторизация ключей RSA-EXPORT (FREAK)

FREAK - это уязвимость типа "человек в середине", обнаруженная группой криптографов из INRIA, Microsoft Research и IMDEA. FREAK означает "Factoring RSA-EXPORT Keys" - факторизация ключей RSA-EXPORT.

Уязвимость ведёт историю с 1990-х годов, когда правительство США запретило продажу программных криптографических средств за границу, если в них используются наборы шифров с ключами длиннее 512-бит.

Оказалось, что некоторые современные клиенты TLS, включая SecureTransport от Apple и OpenSSL, содержат ошибку. Эта ошибка приводит к тому, что применяются ключи RSA экспортного класса, даже если клиент не запрашивает экспортный класс RSA. Воздействие этой ошибки может быть очень неприятным: это позволяет "человеку в середине" реализовать атаку, в результате которой атакующий сможет понизить безопасность соединения, если клиент имеет уязвимость, а сервер поддерживает экспортный RSA.

Для атаки необходимо выполнение двух условий, поскольку сервер тоже должен принимать "RSA экспортного класса".

Человек в середине атакует следующим образом:
  • В приветственном сообщении клиент запрашивает обычный шифр RSA.
  • Человек в середине меняет это сообщение на запрос RSA экспортного класса.
  • Сервер возвращает в ответе 512-битный ключ RSA экспортного класса, подписанный его долгосрочным ключом.
  • Клиент принимает этот слабый ключ из-за ошибки в OpenSSL/SecureTransport.
  • Атакующий факторизует модуль RSA, чтобы восстановить соответствующий ключ RSA для дешифрования.
  • Когда клиент шифрует премастер-секрет, то атакующий может расшифровать его, чтобы восстановить мастер-секрет TLS.
  • С этого момента атакующий может расшифровывать передаваемую информацию и может подменять её.
Предложенный здесь набор шифров не включает класс шифров EXPORT. Убедитесь, что OpenSSL обновлён до последней доступной версии и заставьте клиентов обновить их программное обеспечение.

Logjam (DH EXPORT)

Исследователи из нескольких университетов и институтов провели исследования, в результате которых в протоколе TLS были найдены проблемы. В отчёте этих исследователей сообщается о двух способах атаки.

Обмен ключами Диффи-Хеллмана позволяет в зависимости от TLS согласиться на общий ключ и согласовать безопасный сеанс через незащищённое подключение.

Первая угроза заключается в том, что человек в середине может ослабить уязвимое подключение TLS до 512-битной криптографии экспортного класса, что позволит атакующему читать и изменять данные. Вторая угроза основывается на том, что многие серверы используют одинаковые простые числа для обмена ключами Диффи-Хеллмана, вместо того, чтобы каждый раз создавать свои собственные новые уникальные параметры.

Команда оценила, что академические команды способны взломать 768-битные простые числа, а на государственном уровне возможно взломать 1024-битные простые числа. Взлом одного 1024-битного простого числа позволит прослушивать до 18 процентов из миллиона самых популярных доменов HTTPS. Взлом второго простого числа позволит открыть до 66 процентов VPN-подключений и до 26 процентов SSH-серверов.

Далее в этом руководстве мы создадим собственные уникальные параметры Диффи-Хеллмана и воспользуемся набором шифров, который исключает шифры класса EXPORT. Убедитесь, что OpenSSL обновлён до самой свежей версии и заставьте клиентов обновить их программное обеспечение. Обновлённые браузеры для устранения проблемы отклоняют параметры Диффи-Хеллмана короче 768/1024 бит.

У Cloudflare есть подробное руководство по Logjam.

Heartbleed - кровоточащее сердце

Heartbleed - это ошибка безопасности, обнаруженная в апреле 2014 года в криптографической библиотеке OpenSSL, которая широко используется для реализации протокола TLS. Уязвимостью Heartbleed можно воспользоваться вне зависимости от того, используется ли уязвимая версия OpenSSL для TLS на сервере или на клиенте. Ошибка заключается в недостаточной проверке входных данных (из-за отсутствия проверки границ) в реализации расширения сердцебиения DTLS (RFC6520), из-за чего ошибка получила название heartbleed ("кровоточащее сердце", что созвучно названию расширения heartbeet - "сердцебиение"). Уязвимость классифицируется как чтение за пределами буфера - случай, когда можно прочитать больше информации, чем должно быть разрешено.

Какие версии OpenSSL затрагивает Heartbleed?

Состояние различных версий:
  • OpenSSL 1.0.1 и до 1.0.1f (включительно) уязвимы
  • OpenSSL 1.0.1g НЕ уязвима
  • Ветка OpenSSL 1.0.0 НЕ уязвима
  • Ветка OpenSSL 0.9.8 НЕ уязвима
Ошибка была добавлена в OpenSSL в декабре 2011 и встречалась в дикой природе начиная с релиза OpenSSL 1.0.1 от 14 марта 2012 года. Ошибка была исправлена в выпуске OpenSSL 1.0.1g от 7 апреля 2014 года.

Защититься от уязвимости можно обновив OpenSSL.

Сжатие SSL (атака CRIME)

Атака CRIME для своего тёмного дела использует сжатие SSL. Сжатие SSL по умолчанию выключено в nginx 1.1.6+/1.0.9+ (если используется OpenSSL 1.0.0+) и в nginx 1.3.2+/1.2.2+ (если используется более старая версия OpenSSL).

Если используется одна из более ранних версий nginx или OpenSSL и в дистрибутив не бэкпортировали эту опцию, то нужно пересобрать OpenSSL без поддержки ZLIB. Это приведёт к отключению сжатия по методу DEFLATE в OpenSSL. Даже после этого можно по-прежнему использовать обычное сжатие HTML DEFLATE.

SSLv2 и SSLv3

SSL версии 2 небезопасен, поэтому нужно отключить его. Мы также отключим SSL версии 3, поскольку TLS 1.0 содержит возможность переключиться атакующему на использование SSL версии 3, а затем отключить forward secrecy.

Итак, отредактируем файл конфигурации:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Poodle и TLS-FALLBACK-SCSV

SSL версии 3 позволяет воспользоваться ошибкой POODLE. Это одна из важных причин для его отключения.

Google предложил расширение для SSL/TLS, которое называется TLSFALLBACKSCSV и позволяет предотвратить переключение на более слабые возможности SSL. Оно автоматически включается по умолчанию при обновлении OpenSSL до одной из указанных версий:
  • OpenSSL 1.0.1 поддерживает TLSFALLBACKSCSV в 1.0.1j и выше.
  • OpenSSL 1.0.0 поддерживает TLSFALLBACKSCSV в 1.0.0o и выше.
  • OpenSSL 0.9.8 поддерживает TLSFALLBACKSCSV в 0.9.8zc и выше.
Дополнительную информацию можно найти в документации по nginx.

Набор шифров

Forward Secrecy - прямая секретность - гарантирует целостность сеансового ключа в ситуации, когда скомпрометирован долгосрочный ключ. Perfect Forward Secrecy - совершенно прямая секретность - достигается тем, что для каждого сеанса выводится новый ключ.

Это означает, что при компрометации приватного ключа нельзя воспользоваться им для расшифровки записанного трафика SSL.

Наборы шифров, предоставляющие Perfect Forward Secrecy - это те, которые используют эфемерный обмен ключами Диффи-Хеллмана. Их недостаток - это накладные расходы, которые можно снизить использованием вариантов на эллиптических кривых.

Я рекомендую следующие два набора шифров, а после меня их стали рекомендовать и Mozilla Foundation.

Рекомендуемый набор шифров:
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
Рекомендуемый набор шифров для обратной совместимости (IE6/WinXP):
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
В старых версиях OpenSSL недоступные шифры будут пропущены автоматически. Всегда используйте полный набор шифров, указанных выше и позвольте OpenSSL выбирать те из них, которые поддерживаются.

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

Более старые версии OpenSSL могут не возвращать полный список алгоритмов. Алгоритмы AES-GCM и некоторые виды ECDHE появились сравнительно недавно и отсутствуют в большинстве версий OpenSSL, поставляемых в составе Ubuntu или RHEL.

Логика приоритезации

  • Шифры ECDHE+AESGCM выбираются в первую очередь. Это шифры TLS 1.2. В настоящее время для этих шифров нет известных способов атаки.
  • Предпочитаются наборы шифров PFS сначала с ECDHE, а затем с DHE.
  • AES 128 более предпочтителен, чем AES 256. Есть мнение, что дополнительная степень безопасности AES256 имеет высокую цену при не очевидном результате. На данный момент предпочтительнее AES128, потому что он предоставляет хорошую безопасность, сравнительно быстр и, похоже, более устойчив к атакам по времени.
  • В наборах шифров для обратной совместимости AES предпочтительнее, чем 3DES. Атаки BEAST смягчены в TLS 1.1 и выше, а в TLS 1.0 труднореализуемы. В наборах шифров без обратной совместимости 3DES отсутствует.
  • RC4 удалён полностью. 3DES используется для обратной совместимости. Обратитесь к обсуждению по ссылке #RC4_weaknesses
Явный запрет

  • aNULL содержит не аутентифицированный обмен ключами Диффи-Хеллмана, поэтому подвержены атакам типа "человек в середине".
  • eNULL содержит шифры без шифрования (данные передаются открытым текстом).
  • EXPORT - это устаревшие слабые шифры, которые помечены как разрешённые для экспорта по законам США.
  • RC4 содержит шифры, которые используют устаревший алгоритм ARCFOUR.
  • DES содержит шифры, которые используют устаревший стандарт шифрования данных - Data Encryption Standard.
  • SSLv2 содержит все шифры, которые были определены в старой версии стандарта SSL, ныне устаревшего.
  • MD5 содержит все шифры, которые используют устаревший алгоритм проверки целостности - message digest 5.
Дополнительные настройки

Убедитесь, что в конфигурации есть эти строки:
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
При согласовании шифров в процессе рукопожатия SSLv3 или TLSv1 обычно используются предпочтения клиента. При включении этой директивы вместо них будут использоваться предпочтения сервера.

Дополнительная информация на sslpreferserver_ciphers.

Дополнительная информация на ssl_ciphers.

Forward Secrecy и параметры эфемерного Диффи-Хеллмана

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

При использовании Forward Secrecy - прямой секретности, если атакующий получит приватный ключ сервера, он не сможет расшифровать последующий обмен данными. Приватный ключ используется только для подписи рукопожатия Диффи-Хеллмана, которое не раскрывает премастер-ключ. Диффи-Хеллман гарантирует, что премастер-ключ никогда не покинет клиента и сервер и поэтому не сможет быть перехвачен "человеком в середине".

Все версии nginx, по состоянию на момент выхода версии 1.4.4, полагаются на входные параметры для протокола Диффи-Хеллмана из OpenSSL. Поэтому эфемерный протокол Диффи-Хеллмана будет использовать настройки по умолчанию из OpenSSL, которые включают использование 1024-битного ключа для обмена ключами. Поскольку мы используем 2048-битный сертификат, клиенты, использующие эфемерный протокол Диффи-Хеллмана, будут использовать более слабый обмен ключами, чем клиенты, использующие не эфемерный протокол Диффи-Хеллмана.

Нам нужно сгенерировать более стойкие параметры для эфемерного протокола Диффи-Хеллмана:
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096
А затем сообщим nginx использовать их для обмена ключами по эфемерному протоколу Диффи-Хеллмана:
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Вшивание OCSP

При подключении к серверу клиенты должны проверить действительность сертификата сервера по списку отозванных сертификатов (CRL) или через протокол интерактивного статуса сертификата (OCSP). Проблема списков отозванных сертификатов заключается в том, что такие списки вырастают до огромных размеров и их скачивание может затянуться на вечность.

OCSP намного легче, поскольку за один раз запрашивается одна запись. Но недостаток состоит в том, что при подключении к серверу нужно выполнить OCSP-запрос к стороннему ответчику, что увеличивает задержку и может оказаться причиной сбоев. Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.

Решение заключается в том, чтобы разрешить серверу отправлять в процессе рукопожатия TLS запись OCSP из кэша, так чтобы не затрагивать ответчика OCSP. Этот механизм избавляет клиента от необходимости связываться с ответчиком OCSP и называется вшиванием OCSP.

Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.

Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access - доступ к информации о подлинности.

Обратитесь к моему руководству о включении вшивания OCSP в nginx.

HSTS - строгая безопасность транспорта HTTP

По возможности лучше включить строгую безопасность транспорта HTTP (HSTS), которая предписывает браузеру связываться с сайтом только через HTTPS.

Обратитесь к моей статье по HSTS, чтобы узнать, как её настроить.

HKPK - расширение для фиксации публичного ключа HTTP

Также стоит включить расширение для фиксации публичного ключа HTTP.

Фиксация публичного ключа означает, что цепочка сертификатов должна включать публичный ключ из белого списка. Это гарантирует, что сертификаты для *.example.com могут быть подписаны только удостоверяющими центрами из белого списка, но не какими-либо другими удостоверяющими центрами из хранилища в браузере.

Я написал статью с объяснением теории и примерами конфигурации для Apache, Lighttpd и nginx.

Заключение

Чтобы указанные выше строчки файла конфигурации вступили в силу, нужно перезапустить nginx:
# Сначала проверим файл конфигурации:
/etc/init.d/nginx configtest
# Теперь перезапустим:
/etc/init.d/nginx restart
Теперь воспользуемся проверкой SSL Labs, чтобы увидеть рейтинг A+. И, конечно, у нас получилась безопасная и строгая конфигурация SSL с запасом на будущее!

Также прочитайте страницу Mozilla по этой теме.

воскресенье, 15 января 2017 г.

Файлы конфигурации корневого и промежуточного удостоверяющих центров

Переводы: Root CA configuration file, Intermediate CA configuration file
Автор: Джэми Нгуен (Jamie Nguyen)

Приложение А. Файл конфигурации корневого удостоверяющего центра
# Файл конфигурации OpenSSL для корневого удостоверяющего центра
# Скопируйте в /root/ca/openssl.cnf

[ca]
# `man ca`
default_ca = CA_default

[CA_default]
# Местонахождение каталогов и файлов
dir              = /root/ca
certs            = $dir/certs
crl_dir          = $dir/crl
new_certs_dir    = $dir/newcerts
database         = $dir/index.txt
serial           = $dir/serial
RANDFILE         = $dir/private/.rand

# Корневой ключ и корневой сертификат
private_key      = $dir/private/ca.key.pem
certificate      = $dir/certs/ca.cert.pem

# Настройки списков отозванных сертификатов
crlnumber        = $dir/crlnumber
crl              = $dir/crl/ca.crl.pem
crl_extensions   = crl_ext
default_crl_days = 30

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md       = sha256

name_opt         = ca_default
cert_opt         = ca_default
default_days     = 375
preserve         = no
policy           = policy_strict

[policy_strict]
# Корневой удостоверяющий центр должен подписывать только соответствующие промежуточные сертификаты
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = match
stateOrProvinceName    = match
organizationName       = match
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

[policy_loose]
# Разрешим промежуточному удостоверяющему центру подписывать более широкий диапазон сертификатов
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

[req]
# Опции утилиты `req` (`man req`)
default_bits       = 2048
distinguished_name = req_distinguished_name
string_mask        = utf8only

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md         = sha256

# Расширения, добавляемые при использовании опции -x509
x509_extensions    = v3_ca

[req_distinguished_name]
# Обратитесь к https://en.wikipedia.org/wiki/Certificate_signing_request
countryName                    = Название страны (двухбуквенный код)
stateOrProvinceName            = Название штата или провинции
localityName                   = Название местности
0.organizationName             = Название организации
organizationalUnitName         = Название подразделения организации
commonName                     = Общее имя
emailAddress                   = Адрес электронной почты

# На выбор, можно указать несколько значений по умолчанию
countryName_default            = GB
stateOrProvinceName_default    = England
localityName_default           =
0.organizationName_default     = Alice Ltd
organizationalUnitName_default =
emailAddress_default           =

[v3_ca]
# Расширения для типичного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign

[v3_intermediate_ca]
# Расширения для типичного промежуточного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true, pathlen:0
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign

[usr_cert]
# Расширения для клиентских сертификатов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = client, email
nsComment              = "Сертификат клиента создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage       = clientAuth, emailProtection

[server_cert]
# Расширения для сертификатов серверов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = server
nsComment              = "Сертификат сервера создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage               = critical, digitalSignature, keyEncipherment
extendedKeyUsage       = serverAuth

[crl_ext]
# Расширение для списков отозванных сертификатов (`man x509v3_config`)
authorityKeyIdentifier = keyid:always

[ocsp]
# Расширение для подписи сертификатов OCSP (`man ocsp`)
basicConstraints       = CA:FALSE
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, digitalSignature
extendedKeyUsage       = critical, OCSPSigning

Приложение Б. Файл конфигурации промежуточного удостоверяющего центра
# Файл конфигурации промежуточного удостоверяющего центра
# Скопируйте в /root/ca/intermediate/openssl.cnf

[ca]
# `man ca`
default_ca = CA_default

[CA_default]
# Местонахождение каталогов и файлов
dir              = /root/ca/intermediate
certs            = $dir/certs
crl_dir          = $dir/crl
new_certs_dir    = $dir/newcerts
database         = $dir/index.txt
serial           = $dir/serial
RANDFILE         = $dir/private/.rand

# Промежуточный ключ и промежуточный сертификат
private_key      = $dir/private/intermediate.key.pem
certificate      = $dir/certs/intermediate.cert.pem

# Настройки списков отозванных сертификатов
crlnumber        = $dir/crlnumber
crl              = $dir/crl/intermediate.crl.pem
crl_extensions   = crl_ext
default_crl_days = 30

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md       = sha256

name_opt         = ca_default
cert_opt         = ca_default
default_days     = 375
preserve         = no
policy           = policy_loose

[policy_strict]
# Корневой удостоверяющий центр должен подписывать только соответствующие промежуточные сертификаты
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = match
stateOrProvinceName    = match
organizationName       = match
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

[policy_loose]
# Разрешим промежуточному удостоверяющему центру подписывать более широкий диапазон сертификатов
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

[req]
# Опции утилиты `req` (`man req`)
default_bits       = 2048
distinguished_name = req_distinguished_name
string_mask        = utf8only

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md         = sha256

# Расширения, добавляемые при использовании опции -x509
x509_extensions    = v3_ca

[req_distinguished_name]
# Обратитесь к https://en.wikipedia.org/wiki/Certificate_signing_request
countryName                    = Название страны (двухбуквенный код)
stateOrProvinceName            = Название штата или провинции
localityName                   = Название местности
0.organizationName             = Название организации
organizationalUnitName         = Название подразделения организации
commonName                     = Общее имя
emailAddress                   = Адрес электронной почты

# На выбор, можно указать несколько значений по умолчанию
countryName_default            = GB
stateOrProvinceName_default    = England
localityName_default           =
0.organizationName_default     = Alice Ltd
organizationalUnitName_default =
emailAddress_default           =

[v3_ca]
# Расширения для типичного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign

[v3_intermediate_ca]
# Расширения для типичного промежуточного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true, pathlen:0
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign

[usr_cert]
# Расширения для клиентских сертификатов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = client, email
nsComment              = "Сертификат клиента создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage       = clientAuth, emailProtection

[server_cert]
# Расширения для сертификатов серверов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = server
nsComment              = "Сертификат сервера создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage               = critical, digitalSignature, keyEncipherment
extendedKeyUsage       = serverAuth

[crl_ext]
# Расширение для списков отозванных сертификатов (`man x509v3_config`)
authorityKeyIdentifier = keyid:always

[ocsp]
# Расширение для подписи сертификатов OCSP (`man ocsp`)
basicConstraints       = CA:FALSE
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, digitalSignature
extendedKeyUsage       = critical, OCSPSigning

воскресенье, 8 января 2017 г.

Протокол интерактивного статуса сертификата - OCSP

Перевод: Online Certificate Status Protocol
Автор: Джэми Нгуен (Jamie Nguyen)

OCSP был создан в качестве альтернативы спискам отозванных сертификатов - CRL. Подобно CRL, OCSP позволяет запрашивающей стороне (например, веб-браузеру) определить, отозван ли сертификат.

Когда удостоверяющий центр подписывает сертификат, обычно он добавляет в сертификат адрес сервера OCSP (например, http://ocsp.example.com). Это похоже на функцию crlDistributionPoints, используемую в случае CRL.

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

Для использования OCSP удостоверяющий центр должен добавлять местонахождение сервера OCSP в подписываемые им сертификаты. Воспользуйтесь опцией authorityInfoAccess в соответствующих разделах, которыми в нашем случае являются разделы [server_cert].
[server_cert]
# ... пропущено ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
Создание пары OCSP

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

Создадим приватный ключ и зашифруем его при помощи алгоритма шифрования AES-256.
# cd /root/ca
# openssl genrsa -aes256 \
  -out intermediate/private/ocsp.example.com.key.pem 4096
Создадим запрос на подписание сертификата - CSR. Особенности в целом должны совпадать с подписывающим удостоверяющим центром. Однако, в поле Common Name должно быть указано полное доменное имя.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
  -key intermediate/private/ocsp.example.com.key.pem \
  -out intermediate/csr/ocsp.example.com.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword               # Введите ключевую фразу для intermediate.key.pem: секретныйпароль
You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена
into your certificate request.                                           # в ваш запрос сертификата.
-----
Country Name (2 letter code) [XX]:GB                                     # Название страны (двухбуквенный код) [XX]:GB
State or Province Name []:England                                        # Название штата или провинции []:Англия
Locality Name []:                                                        # Название местности []:
Organization Name []:Alice Ltd                                           # Название организации []:ООО Алиса
Organizational Unit Name []:Alice Ltd Certificate Authority              # Название подразделения []:Удостоверяющий центр ООО Алиса
Common Name []:ocsp.example.com                                          # Общее имя []:ocsp.example.com
Email Address []:                                                        # Адрес электронной почты []:
Подпишем запрос на сертификат промежуточным удостоверяющим центром.
# openssl ca -config intermediate/openssl.cnf \
  -extensions ocsp -days 375 -notext -md sha256 \
  -in intermediate/csr/ocsp.example.com.csr.pem \
  -out intermediate/certs/ocsp.example.com.cert.pem
Проверим, что у сертификата имеются правильные расширения X509v3.
# openssl x509 -noout -text \
  -in intermediate/certs/ocsp.example.com.cert.pem
    X509v3 Key Usage: critical          # Использование ключа X509v3: критичное
        Digital Signature               #     Цифровая подпись
    X509v3 Extended Key Usage: critical # Использование расширенного ключа X509v3: критичное
        OCSP Signing                    #     Подписывание OCSP
Отзыв сертификата

Утилита OpenSSL ocsp может выступать в роли ответчика OCSP, но она предназначена только для тестирования. Существуют промышленные ответчики OCSP, но они не обсуждаются в рамках этого руководства.

Создадим сертификат сервера для проверки.
# cd /root/ca
# openssl genrsa -out intermediate/private/test.example.com.key.pem 2048
# openssl req -config intermediate/openssl.cnf \
  -key intermediate/private/test.example.com.key.pem \
  -new -sha256 -out intermediate/csr/test.example.com.csr.pem
# openssl ca -config intermediate/openssl.cnf \
  -extensions server_cert -days 375 -notext -md sha256 \
  -in intermediate/csr/test.example.com.csr.pem \
  -out intermediate/certs/test.example.com.cert.pem
Запустим ответчика OCSP локально. Прежде чем поместить статус отзыва в отдельный файл CRL, ответчик OCSP читает непосредственно файл index.txt. Ответ подписывается криптографической парой OCSP (с помощью опций -rkey и -rsigner).
# openssl ocsp -port 127.0.0.1:2560 -text -sha256 \
  -index intermediate/index.txt \
  -CA intermediate/certs/ca-chain.cert.pem \
  -rkey intermediate/private/ocsp.example.com.key.pem \
  -rsigner intermediate/certs/ocsp.example.com.cert.pem \
  -nrequest 1
Enter pass phrase for ocsp.example.com.key.pem: secretpassword # Введите ключевую фразу для ocsp.example.com.key.pem: секретныйпароль
В другом терминале отправим запрос к ответчику OCSP. Опция -cert указывает проверяемый сертификат.
# openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem \
  -url http://127.0.0.1:2560 -resp_text \
  -issuer intermediate/certs/intermediate.cert.pem \
  -cert intermediate/certs/test.example.com.cert.pem
Начало вывода показывает:
  • был ли получен успешный ответ (OCSP Response Status),
  • удостоверение ответчика (Responder Id),
  • состояние, отозван ли сертификат (Cert Status)
OCSP Response Data:                                                # Данные ответа OCSP:
    OCSP Response Status: successful (0x0)                         #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                             #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                               #     Версия: 1 (0x0)
    Responder Id: ... CN = ocsp.example.com                        #     Идентификатор ответчика: ... CN = ocsp.example.com
    Produced At: Apr 11 12:59:51 2015 GMT                          #     Сформирован: 11 апреля 2015 года в 12:59:51 по Гринвичу
    Responses:                                                     #     Ответы:
    Certificate ID:                                                #     Идентификатор сертификата:
        Hash Algorithm: sha1                                       #         Алгоритм хэширования: sha1
        Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 #         Хэш имени выпустившего: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
        Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9  #         Хэш ключа выпустившего: 69E8EC547F252360E5B6E77261F1D4B921D445E9
        Serial Number: 1003                                        #         Серийный номер: 1003
    Cert Status: good                                              #     Статус сертификата: хороший
    This Update: Apr 11 12:59:51 2015 GMT                          #     Это обновление: 11 апреля 2015 года в 12:59:51 по Гринвичу
Отзываем этот сертификат.
# openssl ca -config intermediate/openssl.cnf \
  -revoke intermediate/certs/test.example.com.cert.pem
Enter pass phrase for intermediate.key.pem: secretpassword # Введите ключевую фразу для intermediate.key.pem: секретныйпароль
Revoking Certificate 1003.                                 # Отозвание сертификата 1003.
Data Base Updated                                          # База данных обновлена
Как и прежде, запустим OCSP-ответчик и в другом терминале отправим запрос. В этот раз в выводе будут строки Cert Status: revoked и Revocation Time.
OCSP Response Data:                                                # Данные ответа OCSP:
    OCSP Response Status: successful (0x0)                         #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                             #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                               #     Версия: 1 (0x0)
    Responder Id: ... CN = ocsp.example.com                        #     Идентификатор ответчика: ... CN = ocsp.example.com
    Produced At: Apr 11 12:59:51 2015 GMT                          #     Сформирован: 11 апреля 2015 года в 13:03:00 по Гринвичу
    Responses:                                                     #     Ответы:
    Certificate ID:                                                #     Идентификатор сертификата:
        Hash Algorithm: sha1                                       #         Алгоритм хэширования: sha1
        Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 #         Хэш имени выпустившего: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
        Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9  #         Хэш ключа выпустившего: 69E8EC547F252360E5B6E77261F1D4B921D445E9
        Serial Number: 1003                                        #         Серийный номер
    Cert Status: revoked                                           #     Статус сертификата: отозван
    Revocation Time: Apr 11 13:01:09 2015 GMT                      #     Время отзыва: 11 апреля 2015 года в 13:01:09 по Гринвичу
    This Update: Apr 11 12:59:51 2015 GMT                          #     Это обновление: 11 апреля 2015 года в 13:03:00 по Гринвичу

воскресенье, 1 января 2017 г.

Списки отозванных сертификатов - CRL

Перевод: Certificate revocation lists
Автор: Джэми Нгуен (Jamie Nguyen)

Списки отозванных сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Приложение клиента, такое как веб-браузер, может использовать списки отозванных сертификатов для проверки подлинности сервера. Приложение сервера, такое как Apache или OpenVPN, могут использовать списки отозванных сертификатов для запрета доступа клиентам, которые утратили доверие.

Публикация списков отозванных сертификатов - это их размещение в публично доступном месте (например, http://example.com/intermediate.crl.pem). Сторонние потребители могут получить список отозванных сертификатов из этого места, чтобы проверить, были ли отозваны сертификаты, относящиеся к этому списку.
Замечание. Некоторые разработчики приложений считают списки отозванных сертификатов устаревшими и используют вместо них протокол интерактивного статуса сертификата (OCSP).
Подготовка файла конфигурации

Когда удостоверяющий центр подписывает сертификат, обычно он добавляет в сертификат место расположения списка отозванных сертификатов. Добавьте опцию crlDistributionPoints в соответствующие разделы. В нашем случае нужно добавить опцию в раздел [server_cert].
[server_cert]
# ... пропущено ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
Создание CRL
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
  -gencrl -out intermediate/crl/intermediate.crl.pem
Замечание. Обратитесь к разделу ОПЦИИ CRL на странице руководства инструмента ca, чтобы получить более подробную информацию о создании списков отозванных сертификатов.
Проверить содержимое списков отозванных сертификатов можно при помощи инструмента crl.
# openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text
Ещё нет отозванных сертификатов, поэтому вывод содержит "No Revoked Certificates".

Список отозванных сертификатов нужно регулярно пересоздавать. По умолчанию список отозванных сертификатов устаревает через 30 дней. Период устаревания управляется опцией default_crl_days в разделе [CA_default].

Отзыв сертификата

Рассмотрим пример. Алиса запустила веб-сервер Apache и у неё есть секретный каталог с фотографиями милых котиков. Алиса хочет предоставить доступ к этой коллекции своему другу - Бобу.

Боб создаёт приватный ключ и запрос на подпись сертификата (CSR).
$ cd /home/bob
$ openssl genrsa -out bob@example.com.key.pem 2048
$ openssl req -new -key bob@example.com.key.pem \
  -out bob@example.com.csr.pem
You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена
into your certificate request.                                           # в ваш запрос сертификата.
-----
Country Name (2 letter code) [XX]:US                                     # Название страны (двухбуквенный код) [XX]:US
State or Province Name []:California                                     # Название штата или провинции []:Калифорния
Locality Name []:San Francisco                                           # Название местности []:Сан-Франциско
Organization Name []:Bob Ltd                                             # Название организации []:ООО Боб
Organizational Unit Name []:                                             # Название подразделения []:
Common Name []:bob@example.com                                           # Общее имя []:bob@example.com
Email Address []:                                                        # Адрес электронной почты []:
Боб отправляет свой запрос на подпись сертификата Алисе, которая затем подписывает его.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
  -extensions usr_cert -notext -md sha256 \
  -in intermediate/csr/bob@example.com.csr.pem \
  -out intermediate/certs/bob@example.com.cert.pem
Sign the certificate? [y/n]: y                              # Подписать сертификат? [д/н]: д
1 out of 1 certificate requests certified, commit? [y/n]: y # 1 из 1 запросов на сертификат подписано, подтвердить? [д/н]: д
Алиса проверяет, что этот сертификат действителен:
# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
  intermediate/certs/bob@example.com.cert.pem
bob@example.com.cert.pem: OK
В файле index.txt должна появиться новая запись.
V 160420124740Z 1001 unknown ... /CN=bob@example.com
Алиса отправляет Бобу подписанный сертификат. Боб устанавливает сертификат в свой веб-браузер и теперь ему доступны Алисины фотографии кошечек. Ура!

К сожалению, впоследствии Боб поместил Алисины фотографии кошечек на сайт Новости Хакеров, как будто это его фотографии, и приобрёл высокую популярность. Алиса обнаружила это и хочет немедленно отобрать у него доступ.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
  -revoke intermediate/certs/bob@example.com.cert.pem
Enter pass phrase for intermediate.key.pem: secretpassword # Введите ключевую фразу для intermediate.key.pem: секретныйпароль
Revoking Certificate 1001.                                 # Отзывается сертификат 1001.
Data Base Updated                                          # База данных обновлена
Теперь в файле index.txt строчка, соответствующая сертификату Боба, начинается с символа R. Это означает, что сертификат был отозван.
R 160420124740Z 150411125310Z 1001 unknown ... /CN=bob@example.com
После отзыва сертификата Боба Алиса должна пересоздать список отозванных сертификатов.

Использование CRL сервером

Проверкой клиентских сертификатов обычно занимается приложение-сервер (например, Apache). Это приложение должно иметь локальный доступ к списку отозванных сертификатов.

В случае Алисы, она может добавить директиву SSLCARevocationPath в конфигурацию Apache и скопировать список отозванных сертификатов на веб-сервер. При следующем подключении Боба к веб-серверу, Apache проверит клиентский сертификат по списку отозванных сертификатов и запретит доступ.

Подобная директива crl-verify есть и в OpenVPN, так что доступ клиентам с отозванными сертификатами будет заблокирован.

Использование CRL клиентом

Сертификаты сервера обычно проверяет приложение клиента (например, веб-браузер). Это приложение должно иметь удалённый доступ к списку отозванных сертификатов.

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

Точки распространения списка отозванных сертификатов можно увидеть в информации о сертификате в разделе X509v3.
# openssl x509 -in cute-kitten-pictures.example.com.cert.pem -noout -text
    X509v3 CRL Distribution Points: # Точки распространения списка отозванных сертификатов X509v3
        Full Name:                  #     Полное имя
            URI:http://example.com/intermediate.crl.pem