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

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

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

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

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

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

Ключи ECDSA представляют собой альтернативу, обеспечивающую лучшую безопасность и производительность. 256-битные ключи ECDSA обеспечивают 128-бит безопасности. Некоторые старые клиенты не поддерживает ключи ECDSA, но современные клиенты поддерживают. Можно получить лучшее от обоих решений и одновременно развернуть ключи RSA и ECDSA, если накладные расходы по управлению такой настройкой не будут слишком велики.

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

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

• Сгенерируйте закрытые ключи на доверенном компьютере с достаточной энтропией. Некоторые центры сертификации предлагают сгенерировать для вас закрытые ключи — не используйте такую функциональность.

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

• После взлома отзовите старые сертификаты и сгенерируйте новые ключи.

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

• Если сохранение одних и тех же ключей не важно для закрепления открытого ключа, вам также следует генерировать новые закрытые ключи всякий раз, когда вы получаете новый сертификат.

3. Обеспечьте в сертификате достаточное покрытие имен хостов

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

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

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

Убедитесь, что вы добавили все необходимые доменные имена в альтернативное имя субъекта (SAN), так как все последние версии браузеров не проверяют общее имя для проверки.

4. Получение сертификатов от надежного ЦС

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

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

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

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

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

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

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

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

6. Используйте DNS-запись CAA

DNS CAA — это стандарт, который позволяет владельцам доменных имен ограничивать, какие ЦС могут выдавать сертификаты для своих доменов. В сентябре 2017 года CA/Browser Forum обязал центры сертификации поддерживать его в рамках своих стандартных базовых требований к выдаче сертификатов. Благодаря внедрению CAA снижается поверхность атаки для мошеннических сертификатов, что делает сайты более безопасными. Если центры сертификации имеют автоматизированный процесс выдачи сертификатов, то он должен проверять запись DNS CAA, поскольку это уменьшит неправомерную выдачу сертификатов. Рекомендуется внести центр сертификации в белый список, добавив запись CAA для вашего сертификата. Добавьте ЦС, которым вы доверяете для выдачи вам сертификата.

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

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

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

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

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

2. Используйте безопасные протоколы

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

• SSL v2 небезопасен и не должен использоваться. Эта версия протокола настолько плоха, что ее можно использовать для атаки на ключи RSA и сайты с одинаковым именем, даже если они находятся на совершенно разных серверах (атака DROWN).

• SSL v3 небезопасен при использовании с HTTP (атака SSLv3 POODLE) и слаб при использовании с другими протоколами. Он также устарел и не должен использоваться.

• TLS v1.0 и TLS v1.1 — это устаревшие протоколы, которые не следует использовать, но на практике они обычно необходимы. Его основная слабость (BEAST) устранена в современных браузерах, но другие проблемы остались. TLS v1.0 объявлен устаревшим в соответствии с PCI DSS. Точно так же TLS v1.0 и TLS v1.1 устарели в январе 2020 года в современных браузерах.

• TLS v1.2 и v1.3 не имеют известных проблем с безопасностью.

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

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

Преимущества использования TLS v1.3:

• Улучшенная производительность (уменьшены задержки)

• Улучшенная безопасность

• Удалены устаревшие / небезопасные функции, такие как наборы шифров, сжатие и т. Д.

3. Используйте наборы безопасных шифров

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

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

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

• Анонимные наборы Диффи-Хеллмана (Anonymous Diffie-Hellman, ADH) не обеспечивают аутентификацию.

• Наборы шифров NULL (NULL cipher) не обеспечивают шифрования.

• Наборы экспортированных шифров небезопасны при согласовании в соединении

• Пакеты со слабыми шифрами (112 бит или меньше) используют шифрование, которое легко взломать, небезопасны.

• RC4 небезопасен.

• 64-битный блочный шифр (3DES/DES/RC2/IDEA) слаб.

• Наборы шифров с обменом ключами RSA (TLS_RSA) являются слабыми

Есть несколько наборов шифров, которым следует отдать предпочтение:

• Наборы шифров AEAD (Authenticated Encryption with Associated Data) — CHACHA20_POLY1305, GCM и CCM

• Шифры PFS (Perfect Forward Secrecy) — ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1 и все шифры TLS 1.3

В качестве отправной точки используйте следующую конфигурацию набора, предназначенную для ключей 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. Некоторые платформы используют нестандартные имена; пожалуйста, обратитесь к документации для вашей платформы для получения более подробной информации. Например, с 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

4. Выберите лучшие наборы шифров

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

5. Используйте прямую секретность

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

Для поддержки более широкого круга клиентов вам также следует использовать наборы DHE в качестве запасного варианта после ECDHE. Избегайте обмена ключами RSA без крайней необходимости. Предложенная конфигурация по умолчанию в Разделе 2.3 содержит комплекты, которые обеспечивают только прямую секретность.

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

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

В 2015 году группа исследователей опубликовала новые атаки на DHE - их работа известна как атака Logjam. Исследователи обнаружили, что обмен ключами DH с меньшей надежностью (например, 768 бит) может быть легко взломан и что некоторые известные 1024-битные группы DH могут быть взломаны государственными органами. Чтобы быть в безопасности, при развертывании DHE настройте его как минимум на 2048 битов безопасности.

Некоторые старые клиенты (например, Java 6) могут не поддерживать этот уровень надежности. Из соображений производительности большинству серверов следует предпочесть ECDHE, который и сильнее, и быстрее. В этом случае хорошим выбором будет именованная кривая secp256r1 (также известная как P-256).

7. Устранение известных проблем

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

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