Рекомендации по внедрению SSL и TLS

Версия 1.6 (31 марта 2017 года)

SSL/ TLS - обманчиво простая технология. Его легко развернуть, и он просто работает, за исключением случаев, когда он этого не делает. Основная проблема заключается в том, что правильная настройка шифрования не такая простая задача. Чтобы гарантировать, что TLS обеспечивает необходимую безопасность, системные администраторы и разработчики должны приложить дополнительные усилия для правильной настройки своих серверов и доработки своих приложений.

В 2009 году мы начали работу над SSL Labs, потому что мы хотели понять, как использовался TLS, и чтобы устранить недостаток простых в использовании TLS инструментов и документации. Мы достигли некоторых из наших целей посредством сбора глобальной статистики использования TLS, а также разработки оценочного онлайн-инструмента, но нехватка документации все еще очевидна. Этот документ является шагом для решения данной проблемы.

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

1 Закрытый ключ и сертификат

В TLS вся безопасность начинается с криптографического идентификатора сервера; стойкого закрытого ключа необходимого для предотвращения атак злоумышленников с использованием имитации авторизации (атака с изменением авторства). Не менее важно иметь действительный и стойкий сертификат, который дает закрытому ключу право представлять конкретное имя хоста. Без этих двух основных строительных блоков ничто другое не может обеспечить безопасность.

1.1 Используйте 2048-битные закрытые ключи

Для большинства веб-сайтов достаточно реализовать криптостойкость, обеспечиваемую 2048-разрядными ключами RSA. Алгоритм открытого ключа RSA широко поддерживается, что делает выбор таких ключей предпочтительным и безопасным. При использовании 2048 бит, такие ключи обеспечивают устойчивость примерно на уровне 112 бит. Если вы хотите больше безопасности, чем эта, обратите внимание, что ключи RSA не очень хорошо масштабируются. Чтобы получить уровень безопасности не менее 128 бит, вам нужны 3072-разрядные ключи RSA, которые заметно медленнее. Ключи ECDSA предоставляют альтернативу, которая обеспечивает лучшую безопасность и лучшую производительность. При использовании 256-ти бит, ключи ECDSA обеспечивают уровень безопасности в 128 бит. Небольшое количество старых клиентских приложений не поддерживают ECDSA, но современные клиенты полностью поддерживают этот алгоритм. Можно получить лучшее из обоих алгоритмов и развернуть сервер с RSA и ECDSA-ключами одновременно, если вы не против накладных расходов на настройку такой схемы.

1.2 Защита закрытых ключей

Относитесь к своим секретным ключам как к важному активу, предоставляя доступ минимально возможной группе сотрудников, в разумных пределах. Рекомендуемые политики включают следующее:

• Создавайте секретные ключи на доверенном компьютере с достаточной энтропией. Некоторые ЦС предлагают создавать закрытые ключи для вас; это категорически неприемлемо.
• Необходимо изначально защитить ключи паролем, чтобы предотвратить компрометирование, когда они попадают в системы резервного копирования. Пароли закрытых ключей не очень помогают на рабочих серверах, потому что осведомленный злоумышленник всегда может извлекать ключи из памяти процесса. Существуют аппаратные устройства (так называемые аппаратные модули безопасности или HSM), которые могут защитить частные ключи даже в случае компрометации сервера, но они дороги и, следовательно, оправданы только для организаций с жесткими требованиями безопасности.
• После компрометации отмените старые сертификаты и создайте новые ключи.
• Обновляйте сертификаты ежегодно и чаще, если вы можете автоматизировать процесс. Большинство сайтов должны предполагать, что скомпрометированный сертификат невозможно будет достоверно отозвать; поэтому сертификаты с более короткими сроками жизни являются более безопасными на практике.
• За исключением случаев когда сохранение старых ключей важно для сохранения открытого ключа, вы должны генерировать новые закрытые ключи всякий раз, когда вы получаете новый сертификат.

1.3. Обеспечение достаточного покрытия имени хоста

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

Даже если вы планируете использовать только одно доменное имя, помните, что вы не можете контролировать, как ваши пользователи приходят на сайт или как другие ссылаются на него. В большинстве случаев вы должны убедиться, что сертификат работает с префиксом www и без него (например, он работает как для example.com, так и для www.example.com ). Эмпирическое правило состоит в том, что у безопасного веб-сервера должен быть сертификат, действительный для каждого DNS-имени, настроенного для указания на этот сервер.

Шаблонные сертификаты (wildcard) можно использовать в определенных случаях, но не используйте их, если это может открыть дочерние ключи более многочисленной группе людей, и особенно если видимость выйдет за границы структурных подразделений организации. Другими словами, чем меньше людей имеют доступ к закрытым ключам, тем лучше. Также имейте в виду, что совместное использование сертификатов создает связь, которой можно злоупотреблять для передачи уязвимостей с одного веб-сайта или сервера на все другие сайты и серверы, которые используют один и тот же сертификат (даже если лежащие в основе закрытые ключи отличаются).

1.4 Получайте сертификаты от надежного центра сертификации

Выберите сертифицирующий центр (ЦС), который является надежным и серьезно относится к безопасности и своей деятельности. При выборе центра сертификации учитывайте следующие критерии:

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

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

Предлагаемые услуги Выбранный ЦС, как минимум, должен обеспечивать поддержку как списков отзыва сертификатов (CRL), так и Online Certificate Status Protocol (OCSP) с надежной доступностью и производительностью сети. Многие сайты довольствуются сертификатами для доменов, но вы также должны подумать, потребуется ли вам когда-либо расширенные сертификаты (EV). В любом случае вы должны выбрать алгоритм шифрования для открытого ключа. Большинство веб-сайтов сегодня используют RSA, но ECDSA может стать более востребованным в будущем из-за его преимуществ для производительности.

Дополнительные функции управления сертификатами Если вам нужно большое количество сертификатов и вы будете работать в сложных условиях, выберите ЦС, который даст вам хорошие инструменты для управления ими.

Поддержка Выберите ЦС, который даст вам хорошую поддержку, если и когда она вам нужна.

Замечание

Для достижения наилучших результатов приобретите свои сертификаты заблаговременно и по крайней мере за одну неделю до их размещения на сервере. Эта практика (1) помогает избежать предупреждений о сертификатах для некоторых пользователей, у которых не правильно установлено время на компьютерах, и (2) помогает избежать сбоев проверки отзыва с помощью ЦС, которым требуется дополнительное время для распространения новых сертификатов как действительных на OCSP серверы. Со временем попробуйте продлить этот период "пересменки" до 1-3 месяцев. Аналогично, не ждите, пока срок действия ваших сертификатов подойдет к концу, чтобы их заменить. Начиная перевыпуск сертификатов ранее на несколько месяцев, можно захватить большее количество людей, чьи часы неверно настроены.

1.5 Используйте стойкие алгоритмы подписи сертификата

Безопасность сертификата зависит (1) от стойкости закрытого ключа, который использовался для подписания сертификата, и (2) силы хеширования, используемого в подписи. До недавнего времени большинство сертификатов основывались на функции хэширования SHA1, которая в настоящее время считается небезопасной. Как следствие, мы сейчас переходим на SHA256. По состоянию на январь 2016 года вы не сможете получить сертификат SHA1 из открытого центра сертификации. Существующие сертификаты SHA1 будут продолжать работать (с предупреждениями в некоторых браузерах), но только до конца 2016 года.

2. Конфигурация

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

2.1 Используйте полные цепочки сертификатов

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

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

2.2 Используйте защищенные протоколы

В семействе SSL/TLS существует пять протоколов: SSL v2, SSL v3, TLS v1.0, TLS v1.1 и TLS v1.2:

• SSL v2 не является безопасным и не должен использоваться. Эта версия протокола настолько плоха, что ее можно использовать для атаки ключей RSA и сайтов с тем же именем, даже если они находятся на совершенно разных серверах (атака DROWN).
• SSL v3 небезопасен при использовании с HTTP (уязвим к POODLE) и слаб при использовании с другими протоколами. Он тоже устарел и не должен использоваться.
• TLS v1.0 также является устаревшим протоколом, который не должен использоваться, но он все еще используется для определенных задач. Его основная слабость (BEAST) была устранена в современных браузерах, но остаются другие проблемы.
• TLS v1.1 и v1.2 оба не имеют известных проблем безопасности, но только v1.2 поддерживает современные криптографические алгоритмы.

TLS v1.2 должен быть вашим основным протоколом, потому что это единственная версия, которая предлагает современное аутентифицированное шифрование (также известное как AEAD). Если вы не используете TLS v1.2 сегодня, ваш уровень безопасности равен нулю.

Для поддержки старых клиентов вам, возможно, придется продолжать поддерживать TLS v1.0 и TLS v1.1. Однако в ближайшем будущем вам следует планировать отключение TLS v1.0. Например, стандарт PCI DSS требует, чтобы все сайты, принимающие платежи по кредитным картам, удалили поддержку TLS v1.0 к июню 2018 года.

В настоящее время ведется работа по разработке TLS v1.3 с целью устранения всех устаревших и небезопасных функций и внесения улучшений, которые обеспечат безопасность наших коммуникаций в следующие десятилетия.

2.3 Используйте безопасные пакеты шифрования

Чтобы безопасно общаться, вы должны сначала убедиться, что вы общаетесь напрямую с желаемой стороной (а не через кого-то, кто будет подслушивать) и безопасно обмениваться данными. В протоколах SSL и TLS пакеты шифрования (сiphersuite https://habrahabr.ru/company/yandex/blog/258673/) определяют, как происходит безопасная передача данных. Для реализации идеи обеспечения безопасности посредством разнообразия, они состоят из различных компонентов. Если один из компонентов окажется слабым или небезопасным, вы сможете переключиться на другой.

Вы должны полагаться главным образом на пакеты AEAD, которые обеспечивают надежную аутентификацию и обмен ключами, прямую секретность и шифрование не менее 128 бит. Некоторые другие, более слабые пакеты могут по-прежнему поддерживаться при условии, что они взаимодействуют только с старыми клиентами, которые не поддерживают ничего лучше.

Существует несколько устаревших криптографических примитивов, которых следует избегать:

• Анонимные пакеты Диффи-Хеллмана (ADH) не предоставляют аутентификацию.
• В пакета NULL-шифров нет шифрования.
• Экспортные блоки шифрования небезопасны при установлении соединения, но они также могут использоваться для взаимодействия с сервером, который предпочитает более стойкие пакеты (атака FREAK).
• Пакеты со слабыми шифрами (обычно 40 и 56 бит) используют шифрование, которое можно легко взломать.
• RC4 небезопасен.
• 3DES медленный и слабый.

Используйте следующую конфигурацию, предназначенную для ключей RSA и ECDSA, в качестве отправной точки:

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Внимание!

Мы рекомендуем вам всегда сначала тестировать конфигурацию TLS в закрытой тестовой среде, перенося изменения на основной сервер только тогда, когда есть уверенность, что все работает так, как должно. Обратите внимание, что приведенный выше список является приблизительным и что не все системы (особенно старые) поддерживают все пакеты. Вот почему сначала важно производить тестирование.

В приведенной выше для примера конфигурации используются стандартные имена пакетов TLS. Некоторые платформы используют нестандартные имена; более подробную информацию можно найти в документации для вашей платформы. Например, в OpenSSL будут использоваться следующие имена пакетов:

    ECDHE-ECDSA-AES128-GCM-SHA256
    ECDHE-ECDSA-AES256-GCM-SHA384
    ECDHE-ECDSA-AES128-SHA
    ECDHE-ECDSA-AES256-SHA
    ECDHE-ECDSA-AES128-SHA256
    ECDHE-ECDSA-AES256-SHA384
    ECDHE-RSA-AES128-GCM-SHA256
    ECDHE-RSA-AES256-GCM-SHA384
    ECDHE-RSA-AES128-SHA
    ECDHE-RSA-AES256-SHA
    ECDHE-RSA-AES128-SHA256
    ECDHE-RSA-AES256-SHA384
    DHE-RSA-AES128-GCM-SHA256
    DHE-RSA-AES256-GCM-SHA384
    DHE-RSA-AES128-SHA
    DHE-RSA-AES256-SHA
    DHE-RSA-AES128-SHA256
    DHE-RSA-AES256-SHA256

2.4. Выбирайте лучший пакет шифрования

В версиях протокола SSL v3 и в более поздних версиях клиенты представляют список поддерживаемых ими наборов шифров, а серверы выбирают один набор из списка для использования для соединения. Однако не все серверы делают это хорошо; некоторые из них будут выбирать первый поддерживаемый пакет из клиентского списка. Наличие серверов, активно выбирающих наилучший доступный набор шифров, имеет решающее значение для достижения наилучшей безопасности.

2.5 Используйте прямую секретность (forward secrecy, FS)

Прямая секретность (иногда также называемая безупречной секретностью - perfect forward secrecy, PFS) - это функция протокола, которая обеспечивает безопасный обмен данными, которые не зависят от закрытого ключа сервера. При использовании пакетов шифрования, которые не обеспечивают прямую секретность, кто-то, кто может восстановить закрытый ключ сервера, может расшифровать все ранее записанные зашифрованные разговоры. Вам необходимо поддерживать и выбирать пакеты ECDHE, чтобы обеспечить прямую секретность для современных веб-браузеров. Для поддержки более широкого круга клиентов вы также должны использовать пакеты DHE в качестве резерва после ECDHE. Допускайте обмен ключами RSA только если это абсолютно необходимо. Мы предлагаем использовать только те пакеты, из раздела 2.3. которые обеспечивают прямую секретность.

2.6. Используйте безопасный обмен ключами

Для обмена ключами среднестатистические сайты обычно выбирают между классическим эфемерным обменом ключами Диффи-Хеллмана (DHE) и его вариантом эллиптической кривой ECDHE. Существуют и другие алгоритмы обмена ключами, но они в какой-то мере небезопасны. Обмен ключами RSA по-прежнему очень популярен, но он не обеспечивает прямую секретность (FS).

В 2015 году группа исследователей опубликовала новые типы атак против DHE; их работа известна как атака Logjam [2]. Исследователи обнаружили, что обмены нестойкими DH ключами (например, 768 бит) могут быть легко взломаны и что некоторые известные 1024-битные DH ключи могут быть взломаны государственными органами. Чтобы быть в безопасности, при развертывании DHE, настройте его как минимум на 2048 бит безопасности. Некоторые старые клиенты (например Java 6) могут не поддерживать этот уровень криптостойкости. По соображениям производительности большинство серверов должны предпочесть ECDHE, который является более стойким и быстрым. Кривая secp256r1 (также известная как P-256 ) является хорошим выбором в этом случае.

2.7 Устраните известные уязвимости

В последние годы было несколько серьезных атак на SSL и TLS, но они, как правило, не касаются вас, если вы обновляете программное обеспечение и следуете рекомендациям в этом руководстве. (Если вы этого не делаете, я бы посоветовал проверить ваши системы с помощью SSL Labs и посмотреть на результат). Однако ничто не является абсолютно безопасным, поэтому рекомендуется внимательно следить за тем, что происходит в сфере безопасности. Быстро применяйте патчи разработчиков, если и когда они станут доступными; в противном случае вы можете полагаться только на удачу.

3 Производительность

Безопасность - главная тема этого руководства, но мы также должны обратить внимание на производительность; безопасный сервис, который не удовлетворяет критериям эффективности, без сомнения не будет востребован. При правильной настройке TLS может быть довольно быстрым. С современными протоколами, например, HTTP/2 он может быть даже быстрее, чем обычный обмен данными.

3.1 Избегайте слишком большой безопасности

Криптографическое рукопожатие, которое используется для установления защищенных соединений, представляет собой операцию на стоимость (объем накладных расходов) которой сильно влияет размер закрытого ключа. Использование слишком короткого ключа небезопасно, но использование слишком длинного ключа приведет к «слишком большой» безопасности и замедлит работу. Для большинства веб-сайтов использование ключей RSA, более сильных, чем 2048 бит, и ключей ECDSA, более сильных, чем 256 бит, приводит к потери мощности процессора и может негативно повлиять на взаимодействие с пользователем. Точно так же мало пользы приносит увеличение стойкости фазы обмена эфемерными ключами выше 2048 бит для DHE и 256 бит для ECDHE. Нет никаких явных преимуществ использования шифрования выше 128 бит.

3.2 Используйте возобновляемые сессии

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

3.3 Используйте WAN Optimization и HTTP/2

В наши дни накладные расходы TLS происходят не из криптографических операций с использованием процессора, а из-за задержек сети. Рукопожатие TLS, которое может начаться только после завершения рукопожатия TCP, требует большего объема пакетов и тем дороже, чем дальше от сервера находится клиент. Лучший способ свести к минимуму задержку - это не создавать новые подключения, другими словами, поддерживать существующие соединения в течение длительного времени (keep-alives). Другие методы, обеспечивающие хорошие результаты, включают поддержку современных протоколов, таких как HTTP/2, и использование WAN оптимизации (обычно через сети доставки контента - CDN).

3.4. Используйте кэш

При передаче данных через TLS браузеры могут считать, что весь трафик формируется динамически. Обычно они используют память для кэширования определенных ресурсов, но как только вы закроете браузер, все содержимое может быть потеряно. Чтобы повысить производительность и обеспечить долгосрочное кэширование некоторых ресурсов, явно пометьте статичные ресурсы (например, изображения) меткой "public" в заголовке ответа сервера (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching).

3.5 Используйте OCSP Stapling

OCSP Stapling является расширением протокола OCSP, который передает OCSP данные как часть рукопожатия TLS, непосредственно с сервера. В результате клиенту не нужно связываться с серверами OCSP для внеполосной проверки, и общее время соединения TLS значительно уменьшается. OCSP Stapling является важным методом оптимизации, но вы должны знать, что не все веб-серверы обеспечивают надежную реализацию этой технологии. В сочетании с ЦС, у которого есть медленный или ненадежный OCSP сервер, такие веб-серверы могут создавать проблемы с производительностью. Для достижения наилучших результатов имитируйте условия сбоя, чтобы увидеть, могут ли они повлиять на доступность ваших ресурсов.

3.6 Используйте быстрые криптографические примитивы (алгоритмы)

В дополнение к обеспечению лучшей безопасности мой рекомендуемый пакет шифров также обеспечивает максимальную производительность. По возможности используйте процессоры, поддерживающие аппаратное ускорение AES. Далее, если вы действительно хотите получить дополнительный прирост производительности (возможно, ненужную для большинства сайтов), рассмотрите возможность использования ключей ECDSA.

4 Безопасность приложений и HTTP

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

4.1 Шифруйте все

Тот факт, что шифрование является дополнительным, вероятно, является одной из самых больших проблем безопасности сегодня. Мы видим следующие проблемы:

• Нет TLS на сайтах, которые в этом нуждаются
• Существуют сайты с TLS, которые его не испотлзуют
• Сайты, которые смешивают содержимое TLS и не-TLS, иногда даже на одной странице
• Сайты с ошибками программирования, которые дискредитируют TLS

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

4.2 Не допускайте появления смешанного контента

Страницы смешанного содержания - это те, которые передаются через TLS, но включают в себя ресурсы (например, файлы JavaScript, изображения, файлы CSS), которые не передаются через TLS. Такие страницы не защищены. Например, активный злоумышленник (MITM) может перехватить один незащищенный ресурс JavaScript и захватывать весь сеанс пользователя. Даже если вы будете следовать рекомендациям предыдущего раздела и будете шифровать весь веб-сайт, вы все равно можете обнаружить некоторые ресурсы, в незашифрованном виде с сторонних веб-сайтов.

4.3 Доверие к сторонним ресурсам

Веб-сайты часто используют сторонние сервисы, работающие на JavaScript, загруженного с другого сервера. Хорошим примером такой услуги является Google Analytics, которая используется на большинстве сайтов Интернета. Такое включение стороннего кода создает неявное доверительное соединение, которое эффективно дает другой стороне полный контроль над вашим веб-сайтом. Третья сторона не может быть злонамеренной, но крупные поставщики таких услуг все чаще рассматриваются в качестве целей. Простые рассуждения: если крупный поставщик взломан, злоумышленник автоматически получает доступ ко всем сайтам, которые использует сервис.

Если вы следуете рекомендациям раздела 4.2, то по крайней мере внешние ресурсы будут зашифрованы и, таким образом, будут защищены от атак MITM. Однако вы должны сделать еще один шаг: узнайте, какие сервисы вы используете и удалите, замените их более безопасными альтернативами или примите риск их дальнейшего использования. Новая технология, называемая целостностью подресурсов (SRI), может быть использована для снижения потенциального воздействия через сторонние ресурсы. [3]

4.4 Защищайте файлы cookie

Для правильной защиты веб-сайт требует TLS, но также требуется чтобы все его файлы cookie были явно помечены как безопасные на этапе создания. Невозможность защитить файлы cookie позволяет активному злоумышленнику MITM получать какую-то информацию с помощью уловок, даже на веб-сайтах, которые на 100% зашифрованы. Для получения наилучших результатов рассмотрите возможность добавления проверки подлинности криптографической целостности или даже шифрования в файлы cookie.

4.5 Сжатие TLS

Атака CRIME 2012 года показала, что сжатие TLS невозможно реализовать надежно. Единственное решение - полностью отключить сжатие TLS. В следующем году последовали еще две атаки. TIME и BREACH основаны на особенностях в ответах сервера, сжатых с использованием HTTP-сжатия. В отличие от сжатия TLS, сжатие HTTP является необходимостью и не может быть отключено. Таким образом, для устранения этих атак необходимо внести изменения в код приложения. [4]

Атаки TIME и BREACH нелегко выполнять, но если кто-то мотивирован настолько, чтобы использовать их, это примерно равносильно успешной атаке Cross-Site Request Forgery (CSRF).

4.6 Развертывание строгой транспортной безопасности HTTP

Строгая транспортная безопасность HTTP (HTTP Strict Transport Security, HSTS) - это надстройка безопасности для TLS. Спецификация была разработана и предложена для обеспечения того, что безопасность остается неповрежденной даже в случае проблем конфигурации и ошибок реализации. Чтобы активировать защиту HSTS, вы добавляете новый заголовок ответа на свои веб-сайты. После этого браузеры, которые поддерживают HSTS (все современные браузеры в это время), применяют его.

Цель HSTS проста: после активации она не позволяет использовать какую-либо небезопасную связь с веб-сайтом, который ее использует. Эта цель достигается путем автоматического преобразования всех незашифрованныех ссылок в безопасные. В качестве бонуса он также отключает предупреждения о подозрительных пееходах. (Предупреждения сертификатов являются индикатором активной атаки MITM. Исследования показали, что большинство пользователей пропускают эти предупреждения, поэтому в ваших интересах никогда не разрешать их.)

Добавление поддержки HSTS - единственное самое важное усовершенствование, которое вы можете сделать для безопасности TLS на ваших веб-сайтах. Новые сайты всегда должны быть настроены с учетом HSTS, а старые адаптированы для ее поддержки, когда это возможно и как можно скорее. Для лучшей безопасности рассмотрите возможность предварительной загрузки HSTS, [5], которая встраивает вашу конфигурацию HSTS в современные браузеры, обеспечивая безопасность даже первого подключения к вашему сайту.

Следующий пример конфигурации активирует HSTS на главном имени хоста и всех его поддоменах в течение одного года, а также включает предварительную загрузку HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4.7. Развертывание политики безопасности контента

Политика безопасности контента (Content Security Policy, CSP) - это механизм безопасности, который веб-сайты могут использовать для ограничения функций браузера. Несмотря на то, что CSP изначально разрабатывался для решения проблем Cross-Site Scripting (XSS), он постоянно развивается и поддерживает функции, которые полезны для повышения безопасности TLS. В частности, его можно использовать для ограничения смешанного контента, когда речь идет о сторонних веб-сайтах, для которых HSTS не помогает.

Чтобы развернуть CSP для предотвращения смешанного стороннего содержимого, используйте следующую конфигурацию:

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'; connect-src https: wss:

Замечание

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

4.8 Не кэшуруйте критичные данные

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

4.9. Настройте другие аспекты безопасности

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

5. Проверка

Благодаря множеству параметров конфигурации, доступных для настройки, трудно предугадать, какое влияние окажут определенные изменения. Кроме того, иногда изменения происходят случайно; обновления программного обеспечения могут приводить к незаметным изменениям. По этой причине мы рекомендуем сначала использовать комплексный инструмент оценки SSL/TLS, чтобы проверить вашу конфигурацию и убедиться, что в безопасности текущей конфигурации, а затем периодически проверять изменился ли уровень безопасности. Для общедоступных веб-сайтов мы рекомендуем бесплатный тест от SSL Labs. [6]

6. Дополнительные темы

Ниже описаны узкие вопросы, которые в настоящее время выходят за рамки нашего руководства. Они требуют более глубокого понимания SSL/TLS и инфраструктуры открытых ключей (PKI), и они все еще обсуждаются экспертами.

6.1 Привязка открытого ключа

Привязка открытого ключа предназначена для предоставления операторам веб-сайтов средств для ограничения того, какие ЦС могут выдавать сертификаты для своих веб-сайтов. Эта функция была недавно развернута Google (жестко зашита в их браузере, Chrome) и оказалась очень полезной для предотвращения атак и информирования общественности о них. В 2014 году Firefox также добавил поддержку жесткой привязки ключей. Теперь доступен стандарт для HTTP под названием Public Key Pinning Extension [7]. Привязка открытого ключа затрагивает самую большую слабость PKI (тот факт, что любой ЦС может выдавать сертификат для любого веб-сайта), но это увеличивает процент накладных расходов; развертывание требует значительных усилий и опыта, и создает риск потери контроля над вашим сайтом (если вы сохраните неправильную привязку). Привязку стоит рассматривать как компонент защиты только в том случае, если вы управляете сайтом, который может быть подвергнут реальной атаке через мошеннический сертификат.

6.2 DNSSEC и DANE

Расширения безопасности системы доменных имен (DNSSEC) - это набор технологий, которые добавляют целостность в систему доменных имен. Сегодня активный сетевой атакующий может легко захватить любой запрос DNS и подделать произвольные ответы. С DNSSEC все ответы могут быть криптографически отслежены до корня DNS. DNS-аутентификация именных объектов (DANE) - это отдельный стандарт, который построен поверх DNSSEC для обеспечения привязок между DNS и TLS. DANE может использоваться для повышения безопасности существующей экосистемы PKI на основе ЦС или позволить вообще обходится без нее.

Несмотря на то, что не все согласны с тем, что DNSSEC является хорошим направлением для Интернета, поддержка его продолжает улучшаться. Браузеры еще не поддерживают ни DNSSEC, ни DANE (предпочитая аналогичные функции, предоставляемые HSTS и HPKP), но есть свидетельства того, что они начинают использоваться для повышения безопасности доставки электронной почты.

Ссылки

[1] Transport Layer Security (TLS) Parameters (IANA, retrieved 18 March 2016)

[2] Weak Diffie-Hellman and the Logjam Attack (retrieved 16 March 2016)

[3] Subresource Integrity (Mozilla Developer Network, retrieved 16 March 2016)

[4] Defending against the BREACH Attack (Qualys Security Labs; 7 August 2013)

[5] HSTS Preload List (Google developers, retrieved 16 March 2016)

[6] SSL Labs (retrieved 16 March 2016)

[7] RFC 7469: Public Key Pinning Extension for HTTP (Evans et al, April 2015)

См. также

• Руководство по оценочному анализу SSL серверов

Источники

Оригинал этой статьи на английском языке можно найти тут