воскресенье, 26 февраля 2017 г.

HSTS - строгая безопасность транспорта HTTP в Apache, nginx и Lighttpd

Перевод: HTTP Strict Transport Security for Apache, NGINX and Lighttpd
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Что такое "строгая безопасность транспорта HTTP"?
  2. Важное замечание о предварительной загрузке
  3. Настройка HSTS в Apache
  4. Lighttpd
  5. nginx
  6. Заголовок X-Frame-Options
    1. X-Frame-Options в Apache
    2. Lighttpd
    3. nginx
Строгая безопасность транспорта HTTP (часто сокращается как HSTS) - это функция безопасности, которая позволяет веб-серверу сообщать веб-браузерам, что должно использоваться подключение только по HTTPS вместо HTTP. В этом руководстве рассказывается, как настроить HSTS в Apache, nginx и Lighttpd. Руководство протестировано со всеми перечисленными серверами: nginx 1.1.19, Lighttpd 1.4.28 и Apache 2.2.22 в Ubuntu 12.04, Debian 6 и 7, а также в CentOS 6. Руководство может быть пригодным и для других дистрибутивов, а данные дистрибутивы указаны в качестве эталона.

Что такое "строгая безопасность транспорта HTTP"?

Процитируем Mozilla Developer Network - сеть разработчиков Mozilla:
Если веб-сайт принимает подключения по HTTP и перенаправляет их на HTTPS, то пользователь в этом случае обращается сначала к нешифрованной версии сайта и только потом перенаправляется. Например, если пользователь введёт http://www.foo.com/ или даже просто foo.com.

Это открывает возможность для атаки "человек в середине", при которой перенаправление может быть подменено для перенаправки пользователя на сайт злоумышленника вместо безопасной версии исходной страницы.

Функция строгой безопасности транспорта HTTP позволяет веб-сайту проинформировать веб-браузер, что он никогда не должен загружать этот сайт по протоколу HTTP и должен автоматически преобразовывать все попытки обратиться к сайту по протоколу HTTP в запросы по протоколу HTTPS.
Пример использования:
Вы заходите на бесплатную точку доступа WiFi в аэропорту и начинаете бродить по интернету, заходите на сайт банк-клиента для проверки баланса и чтобы оплатить несколько счетов. Неожиданно, используемая вами точка доступа оказывается ноутбуком злоумышленника, и он перехватывает исходный запрос HTTP и перенаправляет вас на сайт-клон банк-клиента, а не на настоящий сайт. Теперь ваши секретные данные доступны злоумышленнику.

Строгая безопасность транспорта решает проблему. После первого обращения к сайту банк-клиента по протоколу HTTPS, если сайт банк-клиента использует строгую безопасность транспорта, браузер будет знать, что все последующие запросы нужно автоматически преобразовывать в запросы по протоколу HTTPS. Это позволяет защититься от злоумышленников, пытающихся осуществить атаку типа "человек в середине".
Отметим, что HSTS не сработает, если вы ранее никогда не были на этом веб-сайте. Веб-сайт должен сообщить, что он доступен только по протоколу HTTPS.

Важное замечание о предварительной загрузке

В конфигурации ниже использовалась директива предварительной загрузки. По просьбе Лукаса Гэррона (Lucas Garron) из Google, я удалил её, поскольку у многих людей возникли с ней проблемы.

Учтите, что директива предварительной загрузки повлечёт за собой почти постоянные последствия. Если вы потестировали её, ошиблись или больше не хотите использовать HSTS, то сайт может оказаться в списке предварительной загрузки.

Важно, чтобы вы понимали то, что делаете и чтобы вы понимали, что директива предварительной загрузки в конечном счёте действует в браузере. Если конфигурация HTTPS неправильная, неисправная или вы больше не хотите использовать HTTPS, у вас возникнут проблемы. Обратитесь к этой странице.

Если вы всё ещё хотите использовать предварительную загрузку, просто добавьте preload в заголовок после точки с запятой.

Настройка HSTS в Apache

Отредактируйте файл конфигурации Apache (например, /etc/apache2/sites-enabled/website.conf и /etc/apache2/httpd.conf) и добавьте следующие настройки в секцию VirtualHost:
# Необязательная загрузка модуля headers:
LoadModule headers_module modules/mod_headers.so

<VirtualHost 67.89.123.45:443>
  Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
</VirtualHost>
Теперь веб-сайт будет при каждом посещении устанавливать заголовок со сроком годности два года (в секундах). Заголовок будет устанавливаться при каждом посещении. Например, завтра он опять будет иметь годность два года.

Заголовок нужно устанавливать только в виртуальном хосте, работающем по протоколу HTTPS. Его не может быть в виртуальном хосте, работающем по протоколу HTTP.

Чтобы перенаправить посетителей на HTTPS-версию сайта, воспользуйтесь следующими настройками:
<VirtualHost *:80>
  [...]
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>
Если всегда будет происходить только перенаправление, то корень документов указывать не требуется.

Можно также воспользоваться modrewrite, хотя метод выше проще и безопаснее. Однако, вариант с modrewrite ниже перенаправляет пользователя на HTTPS-версию той страницы, на которую он хотел попасть, а конфигурация выше просто перенаправляет в /:
<VirtualHost *:80>
  [...]
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
  </IfModule>
</VirtualHost>
И не забудьте перезапустить Apache.

Lighttpd

В случае Lighttpd всё очень просто. Добавим в файл конфигурации Lighttpd (например, в /etc/lighttpd/lighttpd.conf) следующие строки:
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
  setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; ")
}
И перезапустим Lighttpd. В этой конфигурации срок действия такой же - два года.

nginx

Настройка nginx даже ещё короче. Добавьте следующую строку в блок server, относящийся к настройке HTTPS:
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";
Не забудьте перезапустить nginx.

Заголовок X-Frame-Options

Последний совет, который я хочу дать - это заголовок X-Frame-Options, который можно добавить к веб-сайту HTTPS, чтобы предотвратить его встраивание в frame или iframe. Это позволит избежать кликджекинга и может быть полезно для веб-сайтов HTTPS. Снова процитирую Mozilla Developer Network - сеть разработчиков Mozilla:

Заголовок в HTTP-ответе X-Frame-Options может использоваться для того, чтобы обозначить, должен ли браузер показывать страницу в "<frame>" или в "<iframe>". Сайты могут использовать этот заголовок для защиты от кликджекинга, чтобы быть уверенным в том, что их страницы не будут встроены в другие сайты.

Вы можете заменить DENY (запретить) на SAMEORIGIN (тот же источник) или ALLOW-FROM (разрешено при переходе с) URI. Обратитесь по ссылке выше за более подробной информацией (или к RFC).

X-Frame-Options в Apache2

Как и в прошлый раз, добавим строчку в конфигурацию Apache:
Header always set X-Frame-Options DENY
Lighttpd

То же самое можно сделать и в Lighttpd. Убедитесь, что не дублируете настройки, указанные выше. Если настройки уже есть, просто добавьте в них новое правило.
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
  setenv.add-response-header = ( "X-Frame-Options" => "DENY")
}
nginx

И снова, в блоке server:
add_header X-Frame-Options "DENY";

воскресенье, 19 февраля 2017 г.

Вшивание OCSP в Apache

Перевод: OCSP Stapling on Apache
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Что такое "вшивание OSCP"?
  2. Требования
  3. Конфигурация Apache
    1. SSLUseStapling
    2. SSLStaplingCache
  4. Тестирование
  5. Источники
При подключении к серверу, клиент должен проверить действительность сертификата сервера по списку отозванных сертификатов - CRL, или по протоколу интерактивного статуса сертификата - OCSP. Проблема CRL заключается в том, что списки могут вырасти до огромных размеров и скачивание может затянуться на вечность.

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

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

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

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

Это руководство также доступно для nginx.

Что такое "вшивание OCSP"?

Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS ответ клиенту возвращается веб-сервером, который прикладывает OCSP-ответ из кэша в сообщение CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в его приветственном SSL/TSL-сообщении.

Вшивание OCSP имеет несколько дополнительных плюсов:
  • Клиент получает статус сертификата веб-сервера, когда это требуется (в процессе рукопожатия SSL/TLS).
  • Не требуется устанавливать дополнительное HTTP-подключение к удостоверяющему центру, выпустившему сертификат.
  • Вшивание OCSP увеличивает безопасность, уменьшая количество векторов атаки.
Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:
Требования

Для настройки потребуется Apache версии 2.3.3 или выше и OpenSSL версии 0.9.8h или выше. Они не доступны в текущем релизе Ubuntu LTS (12.04), где есть только 2.2.22, а в CentOS 6 есть только 2.2.15. Поищите неофициальный репозиторий в PPA или соберите программы самостоятельно.

Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP. URI OCSP веб-сайта можно увидеть при помощи следующей команды:
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null \
 | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
 echo $certificate | openssl x509 -noout -ocsp_uri; \
done; \
IFS=$OLDIFS
Вот результаты для google.com:
http://clients1.google.com/ocsp
http://gtglobal-ocsp.geotrust.com
Замените google.com на ваш домен. Также отметим, что требуются GNU-версии sed и bash. Команда не работает в OS X и в BSD.

Конфигурация Apache

Добавим следующие настройки в секцию VirtualHost:
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Далее приведём объяснение этих двух строк:

SSLUseStapling

Вшивание OCSP освобождает клиента от необходимости обращаться к OCSP-ответчику самостоятельно, но необходимо отметить, что в соответствии со спецификацией RFC 6066, ответ сервера в поле CertificateStatus может содержать OCSP-ответ только для одного сертификата. Если же в сертификате сервера имеется цепочка сертификатов промежуточных удостоверяющих центров (что в наши дни встречается повсеместно), текущая реализация вшивания лишь частично достигает цели "снизить задержку и использование ресурсов". Обратитесь также к RFC 6961, где описывается TLS Multiple Certificate Status Extension - расширение TLS для проверки статуса нескольких сертификатов.

SSLStaplingCache

Настраивает кэш для хранения OCSP-ответов, которые будут использоваться в процедуре рукопожатия TLS, если включена директива SSLUseStapling. Необходима явная настройка кэша для вшивания OCSP. Поддерживаются те же типы хранилища, что и в SSLSessionCache, за исключением none и nonenotnull.

Глава о shmbc:

Создаёт высокопроизводительный циклический буфер (размером примерно size байт) в разделяемом сегменте оперативной памяти (создаётся через путь к файлу данных - /path/to/datafile) для синхронизации кэшей локальной памяти OpenSSL процессов сервера. Рекомендуется использовать его для кэширования сеансов. При использовании убедитесь, что загружен модуль mod_socache_shmcb.

Также можно указать несколько дополнительных опций. Например, время, через которое OCSP-ответ будет считаться устаревшим:
SSLStaplingResponseMaxAge 900
Эта директива разрешает держать ответ в кэше не более 15 минут (900 секунд).

Если сервер Apache находится за HTTP-прокси, может понадобиться выполнять OCSP-запросы через прокси. Для этого можно воспользоваться директивой SSLStaplingForceURL. Она заменяет URL из сертификата:
SSLStaplingForceURL http://internal-proxy.example.org
Перезапустите Apache, чтобы загрузить новую конфигурацию:
service apache2 restart
Теперь всё должно заработать. Давайте проверим.

Тестирование

Откройте терминал и воспользуйтесь следующей командой OpenSSL для подключения к вашему веб-сайту:
openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status
В ответе обратим внимание на следующее:
OCSP response:                                                   # Ответ OCSP:
======================================
OCSP Response Data:                                              # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                       #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                           #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                             #     Версия: 1 (0x0)
    Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC       #     Идентификатор ответчика
    Produced At: Feb 3 04:25:39 2014 GMT                         #     Сформирован: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Responses:                                                   #     Ответы:
    Certificate ID:                                              #     Идентификатор сертификата:
      Hash Algorithm: sha1                                       #       Алгоритм хэширования: sha1
      Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604 #       Хэш имени эмитента
      Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC  #       Хэш ключа эмитента
      Serial Number: 1003                                        #       Серийный номер
    Cert Status: good                                            #     Статус сертификата: хороший
    This Update: Feb 3 04:25:39 2014 GMT                         #     Это обновление: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Next Update: Feb 7 04:25:39 2014 GMT                         #     Следующее обновление: 7 февраля 2014 года в 04:25:39 по Гринвичу
Этот ответ означает, что всё работает. Если получен ответ, подобный следующему, то это значит что вшивание OCSP не работает:
OCSP response: no response sent # OCSP-ответ: ответ не получен
Вы также можете воспользоваться проверкой SSL Labs, чтобы проверить, что вшивание OCSP работает.

Источники

воскресенье, 12 февраля 2017 г.

Вшивание OCSP в nginx

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

Содержание
  1. Что такое "вшивание OSCP"?
  2. Требования
  3. Конфигурация nginx
  4. Тестирование
  5. Источники
При подключении к серверу, клиент должен проверить действительность сертификата сервера по списку отозванных сертификатов - CRL, или по протоколу интерактивного статуса сертификата - OCSP. Проблема CRL заключается в том, что списки могут вырасти до огромных размеров и скачивание может затянуться на вечность.

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

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

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

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

Это руководство также доступно для Apache.

Что такое "вшивание OCSP"?

Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS веб-сервер возвращает клиенту ответ, к которому прикладывает OCSP-ответ из кэша в поле CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в приветствии SSL/TSL.

Вшивание OCSP имеет несколько дополнительных плюсов:
  • Клиент получает статус сертификата веб-сервера, когда это требуется (в процессе рукопожатия SSL/TLS).
  • Не требуется устанавливать дополнительное HTTP-подключение к удостоверяющему центру, выпустившему сертификат.
  • Вшивание OCSP увеличивает безопасность, уменьшая количество векторов атаки.
Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:
Требования

Необходим nginx версии не ниже 1.3.7. Эта версия не доступна в текущем релизе Ubuntu LTS (12.04), где есть только 1.1.19, а в CentOS нужен EPEL или официальные репозитории. Однако, установить последнюю версию nginx довольно легко.

Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP. URI OCSP веб-сайта можно увидеть при помощи следующей команды:
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null \
 | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
 echo $certificate | openssl x509 -noout -ocsp_uri; \
done; \
IFS=$OLDIFS
Вот результаты для google.com:
http://clients1.google.com/ocsp
http://gtglobal-ocsp.geotrust.com
Конфигурация nginx

Добавьте следующую конфигурацию в блок server с настройками https (443):
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Чтобы вшивание OCSP заработало, должен быть известен эмитент сертификата сервера. Если файл ssl_certificate не содержит промежуточных сертификатов, сертификат эмитента сертификата сервера должен быть представлен в файле ssl_trusted_certificate.

Мой сертификат для raymii.org выпущен удостоверяющим центром Positive CA 2. Этот сертификат выпущен корневым удостоверяющим центром Addtrust External CA Root. В файле, указанном в директиве ssl_certificate, должны присутствовать оба сертификата. Если в вашем случае это не так, создайте файл с цепочкой сертификатов и используйте его следующим образом:
ssl_trusted_certificate /etc/ssl/certs/domain.chain.stapling.pem;
До версии 1.1.7 можно было настроить только одно имя сервера. Указание имени серверов с помощью адресов IPv6 поддерживается, начиная с версий 1.3.1 и 1.2.2. По умолчанию nginx будет искать и адреса IPv4 и IPv6. Если поиск адресов IPv6 не желателен, можно указать параметр ipv6=off. Решение имён в адреса IPv6 поддерживается начиная с версии 1.5.8.

По умолчанию nginx помещает ответы в кэш, используя значение TTL из ответа. Необязательный параметр valid позволяет заменить его на 5 минут. До версии 1.1.9 настройка времени кэширования была невозможной и nginx всегда помещал ответы в кэш на 5 минут.

Перезапустите nginx, чтобы загрузить новую конфигурацию:
service nginx restart
Теперь всё должно заработать. Давайте проверим.

Тестирование

Откройте терминал и воспользуйтесь следующей командой OpenSSL для подключения к вашему веб-сайту:
openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status
В ответе обратим внимание на следующее:
OCSP response:                                                   # Ответ OCSP:
======================================
OCSP Response Data:                                              #     Данные ответа OCSP
    OCSP Response Status: successful (0x0)                       #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                           #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                             #     Версия: 1 (0x0)
    Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC       #     Идентификатор ответчика
    Produced At: Feb 3 04:25:39 2014 GMT                         #     Сформирован: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Responses:                                                   #     Ответы:
    Certificate ID:                                              #     Идентификатор сертификата:
      Hash Algorithm: sha1                                       #       Алгоритм хэширования: sha1
      Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604 #       Хэш имени эмитента
      Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC  #       Хэш ключа эмитента
      Serial Number: 1003                                        #       Серийный номер
    Cert Status: good                                            #     Статус сертификата: хороший
    This Update: Feb 3 04:25:39 2014 GMT                         #     Это обновление: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Next Update: Feb 7 04:25:39 2014 GMT                         #     Следующее обновление: 7 февраля 2014 года в 04:25:39 по Гринвичу
Этот ответ означает, что всё работает. Если получен ответ, подобный следующему, то это значит что вшивание OCSP не работает:
OCSP response: no response sent # OCSP-ответ: ответ не получен
Вы также можете воспользоваться проверкой SSL Labs, чтобы проверить, что вшивание OCSP работает.

Источники

воскресенье, 5 февраля 2017 г.

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

Перевод: Strong SSL Security on Apache2
Автор: Реми ван Элст (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. Forward Secrecy и параметры эфемерного Диффи-Хеллмана
  12. HSTS - строгая безопасность транспорта HTTP
  13. HPKP - расширение для фиксации публичного ключа HTTP
  14. Вшивание OCSP
  15. Заключение


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

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

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

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

Это руководство удовлетворяет строгим требованиями теста SSL Labs.
Вы сможете найти дополнительную информацию по затронутым темам по следующим ссылкам:
Убедитесь, что вы сняли резервные копии со всех файлов, которые собираетесь редактировать!

Атака BEAST и RC4

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

В новых версиях браузеров включено смягчение атаки BEAST со стороны клиента. Рекомендуется выключить все шифры TLS 1.0 и предлагать только RC4. Однако, список атак против RC4 растёт, многие из них становятся осуществимыми на практике. Более того, есть причины считать, что АНБ взломало 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, поэтому его нужно отключить. В Apache 2.2.24+ можно добавить следующую строку в файл конфигурации SSL, который уже был редактирован выше:
SSLCompression off
Если используется одна из более ранних версий Apache или OpenSSL и в дистрибутив не бэкпортировали эту опцию, то нужно пересобрать OpenSSL без поддержки ZLIB. Это приведёт к отключению сжатия по методу DEFLATE в OpenSSL. Даже после этого можно по-прежнему использовать обычное сжатие HTML DEFLATE.

SSLv2 и SSLv3

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

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

Снова отредактируем файл конфигурации:
SSLProtocol All -SSLv2 -SSLv3
All - это сокращение для +SSLv2 +SSLv3 +TLSv1. Если используется версия OpenSSL 1.0.1 или более поздняя, то All соответствует +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2. В строке выше включаются все протоколы, за исключением SSLv2 и SSLv3. Дополнительную информацию можно найти на веб-сайте Apache.

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 и выше.
Набор шифров

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

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

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

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

Рекомендуемый набор шифров:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
Рекомендуемый набор шифров для обратной совместимости (IE6/WinXP):
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-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.
Apache 2.2.x может работать только с наборами шифров с эфемерным Диффи-Хеллманом, но этого не достаточно. Во всех версиях Internet Explorer требуемые наборы шифров с эфемерным Диффи-Хеллманом не позволяют использовать Forward Secrecy. (Если вы не используете ключи DSA, но их никто не использует - это отдельная история.) Apache не поддерживает настройку параметров Диффи-Хеллмана ни в одной из версий, но существуют заплатки, которыми можно воспользоваться при установке из исходных текстов.

Даже если OpenSSL может предоставить ECDHE, Apache 2.2 в стабильном Debian не поддерживает этот механизм. Для полной поддержки Forward Secrecy нужен Apache 2.4.

В качестве обходного решения можно воспользоваться nginx в качестве обратного прокси, потому что в нём имеется полная поддержка ECDHE.

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

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

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

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

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

Единственный способ исправить Apache - обновление до версии 2.4.7 или более поздней. Начиная с этой версии Apache автоматически выбирает более стойкий ключ.

Если используется Apache версии 2.4.8 или более поздней и OpenSSL версии 1.0.2 или более поздней, можно сгенерировать и указать файл с параметрами Диффи-Хеллмана:
# Генерируем параметры:
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096
Добавьте в конфигурацию Apache следующую строку:
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"
Если используется Apache и библиотека LibreSSL или Apache 2.4.7 и библиотека OpenSSL версии 0.9.8a и выше, можно добавить сгенерированные параметры Диффи-Хеллмана в конец файла сертификата. Документация об этом приведена ниже:

Собственные параметры Диффи-Хеллмана и имя эллиптических кривых для эфемерных ключей можно также добавить в конец первого файла, указанного в SSLCertificateFile. Такая возможность доступна в версии 2.4.7 и более поздних. Такие параметры могут быть сгенерированы с помощью команд openssl dhparam и openssl ecparam. Параметры могут быть добавлены как есть в конец первого файла сертификата. Для настройки особых параметров может использоваться только первый файл, поскольку они применяются вне зависимости от используемого алгоритма аутентификации.

Примерно в мае в Debian бэкпортировали шифры ECDH для их использования в Apache 2.2, после чего появилась возможность использования Perfect Forward Secrecy: http://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache22.2.22-13+deb7u3changelog
> apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium

* Backport support for SSL ECC keys and ECDH ciphers. # Бэкпортирована поддержка ключей SSL ECC и шифров ECDH.
HSTS - строгая безопасность транспорта HTTP

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

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

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

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

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

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

Вшивание 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 в Apache.

Заключение

Чтобы указанные выше строчки файла конфигурации вступили в силу, нужно перезапустить Apache:
# Сначала проверим файл конфигурации:
apache2ctl -t
# Теперь перезапустим:
/etc/init.d/apache2 restart

# Если используется RHEL/CentOS:
apachectl -t
/etc/init.d/httpd restart
Теперь воспользуемся проверкой SSL Labs, чтобы увидеть рейтинг A+. И, конечно, у нас получилась безопасная и строгая конфигурация SSL с запасом на будущее!