5 1 1 1 1 1 1 1 1 1 1 Рейтинг 4.18 [11 Голоса (ов)]

Безопасность SSL высшего класса А+ на Nginx

Эта инструкция раскроет, как настроить высокий уровень безопасности SSL на веб-сервере Nginx. Мы сделаем это путем обновления OpenSSL до последней версии, чтобы снизить опасность таких атак, как Heartbleed, отключения SSL сжатия и экспорта шифра для смягчения таких типов атак, как FREAK, CRIME и LogJAM, отключения SSLv3 и ниже из-за уязвимости в протоколе, создадим мощный криптоключ позволяющий применить шифрование, когда это возможно. Мы также включим HSTS и HPKP. Таким образом, мы получим мощную и профессиональную конфигурацию SSL, а также получаем наивысший класс A+ в Qually Labs SSL Test.

Содержание

  1. BEAST атаки и RC4
  2. Факторинг RSA-EXPORT Ключей (FREAK)
  3. Затор (ДХ ЭКСПОРТ) [Logjam (DH EXPORT)]
  4. Частотоотбор (Heartbleed)
  5. SSL Сжатие (CRIME атака)
  6. SSLv2 и SSLv3
  7. Подлог и TLS-FALLBACK-SCSV
  8. Шифрование Люкс (POODLE)
  9. Логика приоритизации
  10. Обязательные сбросы
  11. Дополнительные настройки
  12. Принудительная Секретность и Эфемерные Параметры Диффи Хеллмана
  13. OCSP Скрепление [OCSP Stapling]
  14. HTTP Strict Transport Security (HSTS)
  15. HTTP Public Key Pinning Extension (HPKP)
  16. Вывод

Мы собираемся изменить настройки Nginx в файле /etc/nginx/sited-enabled/yoursite.com (на Ubuntu/Debian) или в /etc/nginx/conf.d/nginx.conf (на RHEL/CentOS).

Вам необходимо отредактировать части между блоком сервера в конфигурации сервера для 443 порта (ssl config). В конце инструкции вы сможете найти пример полной конфигурации.

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

BEAST атаки и RC4

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

Последние версии браузеров позволили смягчить 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 (обычное "исправление" BEAST с серверной стороны на повышенный приоритет RC4).

Существует уверенность, что недостатки в RC4 значительно перевешивают риски, связанные с BEAST. Действительно, с уменьшением на стороне клиента (которое обеспечивают оба Chrome и Firefox), BEAST не является проблемой. Но риск от RC4 только набирает обороты: Подробный криптоанализ всплывет на поверхность в ближайшее время.

Факторинг RSA-EXPORT Ключей [Factoring RSA-EXPORT Keys (FREAK)]

FREAK является уязвимостью человек-в-середине [man-in-the-middle (MITM)], обнаруженой группой криптографов INRIA, Microsoft Research и IMDEA. FREAK означает "Фактор RSA-Экспорта Ключей"

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

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

Есть два типа атаки, при которой сервер должен также принять "экспорт класс RSA".

Атака MITM работает следующим образом

  1. В Hello сообщении клиента, он запрашивает стандартный 'RSA' набор шифров.
  2. MITM злоумышленник изменяет это сообщение, чтобы запросить 'export RSA'.
  3. Сервер отвечает 512-битным ключом RSA экспорта, подписанного его долгосрочным ключом.
  4. Клиент принимает этот слабый ключ из-за ошибки OpenSSL/SecureTransport.
  5. Атакующий фактор RSA модуля, восстанавливает соответствующий ключ дешифрования RSA.
  6. Когда клиент шифрует 'pre-master secret' сервера, злоумышленник теперь может его расшифровать, чтобы восстановить TLS 'master secret'.
  7. С этого момента, злоумышленник видит открытый текст и может вводить все, что хочет.

Набор шифров, предложенный на этой странице не дает возможности использования шифров экспорт класса. Убедитесь, что ваш OpenSSL обновлен до последней доступной версии и призывайте своих клиентов также использовать обновленное программное обеспечение.

Затор (ДХ ЭКСПОРТ) [Logjam (DH EXPORT)]

Исследователи из нескольких университетов и институтов провели исследование, которое показало проблему в протоколе TLS. В докладе исследователи указывают на два метода атаки.

Разрешая обмен ключами Диффи-Хеллмана [Diffie-Hellman], которые используют TLS для согласования общего ключа и ведут согласование безопасного соединения через обычное текстовое соединение.

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

Вторая угроза в том, что многие серверы и используют одни и те же простые числа для Диффи-Хеллмана обмена ключами, вместо создания своих собственных уникальных DH параметров.

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

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

На Cloudflare имеется подробное руководство по атакам типа Затор (ДХ ЭКСПОРТ) [Logjam (DH EXPORT)].

Частотоотбор (Heartbleed)

Частотоотбор (Heartbleed) - это ошибка безопасности, обнаруженная в апреле 2014 года в криптографической библиотеке OpenSSL, которая широко используется в реализации протокола Транспортный Уровень Безопасности [Transport Layer Security (TLS)]. Частотоотбор (Heartbleed) может быть использован независимо от того, является ли сторона, использующая уязвимый экземпляр OpenSSL для TLS, сервером или клиентом.

В результатах проверки правильности ввода (из-за отсутствия проверки границ) в реализации частотоотбора DTLS расширения (RFC6520), таким образом, название "бага" происходит от "частотоотбор" ("heartbeat"). Уязвимость классифицируется как более читаемым буфером, ситуацией возможности чтения большего количества данных, чем должно быть разрешено.

Какие версии 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. Это позволит отключить использование в OpenSSL метода сжатия DEFLATE. Если вы сделаете это, то вы можете использовать регулярный метод сжатия HTML DEFLATE.

SSLv2 и SSLv3

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

Опять же отредактируйте в конфигурационном файле:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Подлог и TLS-FALLBACK-SCSV

SSLv3 позволяет эксплуатировать ошибку Подлога (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.

Шифрование Люкс

Принуждение Секретности обеспечивает целостность ключа сеанса в том случае, если будет скомпрометирован долгосрочный ключ. PFS решает эту задачу путем применения вывода нового ключа для каждого сеанса.

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

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

Рекомендованы следующие два набора шифров, и некоторые от 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 выберет те, которые он поддерживает.

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

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

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

ECDHE+AESGCM шифры выбираются в первую очередь. Это TLS 1.2 шифры. Ни одна из известных в настоящее время атак не направлена на эти шифры.

PFS шифрометоды являются предпочтительными, с ECDHE первые, а затем DHE.

AES 128 предпочтительнее AES 256. Было много дискуссий о том, стоят ли накладные расходы AES256 дополнительной безопасности далеко не очевидного результата. На данный момент AES128 является предпочтительным, поскольку он обеспечивает хорошую безопасность, очень быстр, и, кажется, более устойчивым к временным атакам.

Для обеспечения обратной совместимости шифрометода, AES предпочтительней 3DES. BEAST атаки на AES смягчаются в TLS 1.1 и выше, чего трудно достичь в TLS 1.0. В не обратно совместимом шифрометоде, 3DES нет.

RC4 удаляется полностью. 3DES используется для обеспечения обратной совместимости. Смотрите обсуждение в #RC4_weaknesses.

Обязательные сбросы

  • aNULL содержит не прошедшие проверку подлинности обмена ключами Диффи-Хеллмана, которые являются объектом атак Человек-В-Середине [Man-In-The-Middle (MITM)]
  • eNULL содержит шифры нуль-шифрования (в открытом виде)
  • EXPORT унаследованные слабые шифры, которые были отмечены как экспортируемый законодательством США
  • RC4 содержит шифры, которые используют устаревший алгоритм ARCFOUR
  • DES содержит шифры, которые используют устаревший стандарт шифрования данных
  • SSLv2 содержит все шифры, которые были определены в старой версии стандарта SSL, теперь не рекомендуется
  • MD5 содержит все шифры, которые используют устаревшее дайджест сообщение 5 в качестве алгоритма хеширования

Дополнительные настройки

Убедитесь, что вы также добавили эти строки:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

 

При выборе шифра во время SSLv3 или TLSv1 рукопожатия, как правило, используется предпочтение клиента. Если эта директива включена, то приоритетно будет использовано предпочтение сервера.

Принудительная Секретность и Эфемерные Параметры Диффи Хеллмана

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

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

Все версии Nginx начиная с 1.4.4 опираются на OpenSSL для входных параметров Диффи-Хеллмана (DH) [Diffie-Hellman (DH)]. К сожалению, это означает, что Эфемерность Диффи-Хеллмана (DHE) будет использовать по умолчанию OpenSSL, которые включают 1024-битный ключ для обмена ключами. Так, как мы используем 2048-битный сертификат, DHE клиенты будут использовать более слабый обмен ключами, чем не эфемерные DH клиенты.

Нам необходимо сформировать более стойкий DHE параметр:

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

А затем заставить Nginx использовать его для DHE обмена ключами:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

OCSP Скрепление [OCSP Stapling]

При подключении к серверу, клиенты должны проверить достоверность сертификата сервера, используя либо Список Отзыва Сертификата (CRL)[Certificate Revocation List (CRL)], или Поддержку Протокола Состояния Сертификата (OCSP) [Online Certificate Status Protocol (OCSP)] запись. Проблема в том, что CRL списки выросли до огромных размеров и не всегда доступны для загрузки.

OCSP гораздо более легковесен так, как только одна запись извлекается одновременно. Но побочный эффект заключается в том, что OCSP запросы должны быть сделаны на 3-й части OCSP ответчиком при подключении к серверу, к чему добавляются задержки и возможные сбои. На самом деле, OCSP ответчики, используемые ЦС (CA), часто настолько ненадежны, что браузер будет терпеть неудачу по времени, если ответ не будет получен своевременно. Это снижает безопасность, позволяя злоумышленнику использовать DoS на OCSP ответчик, чтобы отключить проверку.

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

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

Большинство серверов будет кэшировать ответ OCSP на срок до 48 часов. Через равные промежутки времени, сервер будет подключаться к OCSP ответчику ЦС (Центр Сертификации) (CA), чтобы получить свежую запись OCSP. Расположение OCSP ответчика берется из поля Информации Полномочий Доступа [Authority Information Access] подписанного сертификата.

HTTP Strict Transport Security

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

HTTP Public Key Pinning Extension

Вы должны также включить HTTP Public Key Pinning Extension.

Public Key Pinning означает, что цепочка сертификатов должна включать в себя открытый ключ из белого списка. Это гарантирует, что только белый список Центров Сертификации (ЦС) [whitelisted Certificate Authorities (CA)] может подписывать сертификаты для * .example.com, а не какой-либо ЦС их хранимого вашим браузером.

Вывод

Если вы применили вышеуказанные строки конфигурации необходимо перезапустить nginx:

# Сперва проверьте конфигурацию:

/etc/init.d/nginx configtest

# Затем перезагрузите:

/etc/init.d/nginx restart

Теперь используйте тест SSL Labs, чтобы увидеть как вы получите высокий A класс. И, конечно же, уверенность безопасности, стойкости и доказательство профессиональной конфигурации SSL!

Статья основана на английском руководстве по настройке веб-сервера: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

Наша Рассылка

Еженедельные новости, материалы о информационных технологиях и веб