В данном приложении собраны рекомендации, основанные на лучших практиках развёртывания SSL/TLS, работу над публикацией которых я начал в 2012 году в SSL Labs и до сих пор продолжаю поддерживать. В данную книгу они включены с разрешения Qualys, Inc.
Для получения полного понимания экосистемы SSL/TLS и PKI потребуется много времени и преданности делу. Исходя из моего опыта, большинству людей не нужно знать всё, но определиться с тем, что им действительно необходимо знать, довольно сложно. Как раз для таких людей и предназначено это руководство: сжатый (в обоснованно разумных пределах) документ, дающий полную картину проблем, с которыми сталкивается тот, кто хочет развернуть безопасный сервер SSL/TLS.
В TLS вся защита начинается с криптографической идентификации сервера; стойкий закрытый ключ необходим для предотвращения атак перевоплощения (impersonation attacks) со стороны злоумышленников. Столь же важно иметь валидный и надёжный сертификат, который даёт закрытому ключу право представлять конкретное имя хоста. Без этих двух краеугольных камней всё остальное не может быть безопасным.
Для большинства веб-сайтов безопасность, обеспечиваемая 2048-битными ключами RSA, достаточна. Алгоритм шифрования с открытым ключом RSA широко поддерживается, поэтому ключи такого типа считаются хорошим и безопасным выбором по умолчанию. При длине в 2048 бита они обеспечивают уровень криптостойкости около 112 бит. Если же вам нужен более высокий уровень криптостойкости, имейте ввиду, что ключи RSA не очень хорошо масштабируются. Для получения уровня криптостойкости в 128 бит вам потребуются ключи RSA длиной 3072 бита, работа с которыми будет заметно медленнее. В качестве альтернативы можно рассмотреть ключи ECDSA, обеспечивающие лучшую криптостойкость и производительность. При длине в 256 бит они обеспечивают уровень криптостойкости в 128 бит. Лишь небольшое число старых клиентов не поддерживают ECDSA, на современных клиентах поддержка реализована. Существует возможность воспользоваться сильными сторонами обоих алгоритмов и развернуть инфраструктуру одновременно с ключами RSA и ECDSA, если вас не останавливают затраты на управление такой конфигурацией.
Рассматривайте ваши закрытые ключи как важный актив, предоставляя доступ к ним минимально возможной группе сотрудников, но сохраняя при этом практичность ваших мер. Рекомендуемые политики:
Генерируйте закрытые ключи на доверенном компьютере с достаточной энтропией. Некоторые удостоверяющие центры предлагают генерировать закрытые ключи для вас; не пользуйтесь услугами таких УЦ.
Защищайте ключи паролем с самого начала, чтобы предотвратить компрометацию, когда они хранятся в системах резервного копирования. Паролирование закрытых ключей в рабочей среде не слишком помогает, поскольку знающий злоумышленник всегда может извлечь ключи из памяти процесса. Существуют аппаратные устройства, называемые Аппаратные модули безопасности (Hardware Security Modules, HSM), которые могут защитить закрытые ключи даже в случае взлома сервера, но они дороги и потому оправданы только для организаций со строгими требованиями безопасности.
После компрометации отзовите старые сертификаты и сгенерируйте новые ключи.
Обновляйте сертификаты ежегодно или даже чаще, если вы можете автоматизировать этот процесс. Большинство сайтов должны полагать, что скомпрометированный сертификат будет невозможно гарантировано отозвать; поэтому на практике сертификаты с короткими сроками действия являются более безопасными.
За исключением случаев, когда сохранение старого ключа важно для привязывания открытого ключа (public key pinning), следует также генерировать новый закрытый ключ каждый раз при получении нового сертификата.
Убедитесь, что ваши сертификаты охватывают все имена, которые вы хотите использовать с сайтом. Цель, которую вам нужно достичь: предотвращение появления предупреждений о недействительных сертификатах, которые запутывают пользователей и ослабляют их доверие.
Даже если вы собираетесь использовать только одно доменное имя, помните, что вы не можете контролировать то, как ваши пользователи попадают на сайт или как другие ссылаются на него. В большинстве случаев следует убедиться, что сертификат работает как с префиксом www, так и без него (например, работает и с example.com, и с www.example.com). Непреложное правило: безопасный веб-сервер должен иметь сертификат, действительный для каждого DNS-имени, на которое он (согласно конфигурации) должен откликаться.
Можно использовать сертификаты с шаблонами подстановки (wildcard certificates), но избегайте их применения, если при этом связанные с сертификатами закрытые ключи раскрываются большой группе людей, особенно когда это выходит за рамки команды или подразделения. Иными словами, чем меньше людей имеют доступ к закрытым ключам, тем лучше. Также имейте в виду, что совместное использование сертификатов создает привязку, которой можно воспользоваться для передачи уязвимостей с одного веб-сайта или сервера на все сайты и серверы, использующие один и тот же сертификат (даже если закрытые ключи для сертификатов различаются).
Выбирайте надёжный и серьёзный в области сертификации и безопасности удостоверяющий центр (Certification Authority, CA). При выборе вашего УЦ учитывайте следующие критерии:
Все УЦ регулярно проходят проверки, но некоторые из них более серьёзно относятся к безопасности, чем другие. Выяснить, какие из них лучше в этом отношении, нелегко, один из вариантов — проверить их историю обеспечения безопасности и, что более важно, как они реагировали на компрометации и извлекли ли уроки из своих ошибок.
Организации, для которых выполнение функций удостоверяющего центра составляет существенную часть их бизнеса, могут потерять всё, если что-то пойдёт действительно не так. И, скорее всего, они не будут пренебрегать деятельностью по управлению сертификатами, преследуя потенциально более выгодные возможности в других областях.
Как минимум, выбранный вами УЦ должен обеспечивать поддержку обоих методов отзыва сертификатов: Списков отзыва сертификатов (Certificate Revocation List, CRL) и Протокола онлайн-получения статуса сертификата (Online Certificate Status Protocol, OCSP), с надёжной доступностью и производительностью сети. Для многих сайтов достаточно сертификатов валидации домена, но также следует подумать, могут ли вам когда-нибудь потребоваться сертификаты расширенной валидации (Extended Validation, EV). В любом случае вам должны предоставить выбор, какой алгоритм шифрования с открытым ключом использовать. Сегодня большинство веб-сайтов используют RSA, но в будущем более предпочтительным может стать ECDSA из-за его преимуществ в производительности.
Если вам требуется большое количество сертификатов и вы работаете в сложной среде, выбирайте УЦ, который предоставит вам хорошие инструменты для управления сертификатами.
Выберите центр сертификации, который окажет вам хорошую поддержку и сопровождение, если (когда) они вам понадобятся.
Примечание: Для достижения наилучших результатов внедряйте новые сертификаты в рабочем окружении примерно через неделю после того, как вы получите их от своего удостоверяющего центра. Такая практика поможет, во-первых, избежать выдачи предупреждений о сроках действия сертификатов некоторым пользователям, на компьютерах которых неправильно выставлено время, а во-вторых, избежать неудачных проверок отзыва в тех удостоверяющих центрах, которым требуется дополнительное время для распространения новых сертификатов на их ответчики OCSP.
Безопасность сертификата зависит, во-первых, от стойкости секретного ключа, который использовался для подписи сертификата и, во-вторых, стойкости используемой в подписи функции хэширования. До недавнего времени большинство сертификатов полагалось на функцию хэширования SHA1, которая сейчас считается небезопасной. Поэтому в настоящее время идёт процесс перехода на SHA256. По состоянию на январь 2016 года вы не сможете получить сертификат с SHA1 в общедоступном УЦ. Существующие сертификаты с SHA1 будут обрабатываться и впредь (с предупреждениями в некоторых браузерах), но только до конца 2016 года.
При правильной конфигурации сервера TLS вы гарантируете, что ваши учётные данные будут должным образом представлены посетителям сайта, что будут использоваться только безопасные исходные криптографические алгоритмы и что были предприняты меры по устранению всех известных уязвимостей.
В большинстве развёртываний одного сертификата сервера недостаточно; требуется два или более сертификатов для построения полной цепочки доверия. Распространённая проблема конфигурации возникает, когда сервер развёртывается с действительным сертификатом, но без всех необходимых промежуточных сертификатов. Чтобы избежать этой ситуации, просто используйте все сертификаты, предоставленные вам вашим УЦ.
Неверная цепочка сертификатов фактически делает сертификат сервера недействительным, и в результате браузеры выдают предупреждения. На практике эта проблема иногда трудно диагностируема, поскольку некоторые браузеры могут самостоятельно реконструировать неполные цепочки, а некоторые — нет. Все браузеры имеют тенденцию кешировать и повторно использовать промежуточные сертификаты.
В семействе 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 и TLS 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, цель которых — отказаться от всех устаревших и небезопасных функций и внести улучшения, которые обеспечат безопасность обмена данными в последующие десятилетия.
Для безопасного обмена информацией вы должны сначала удостовериться, что вы общаетесь напрямую с нужной стороной (а не через кого-то, кто будет подслушивать) и безопасно обмениваетесь данными. В SSL и TLS наборы шифров определяют, насколько безопасно происходит общение. Они состоят из различных строительных блоков с идеей достижения безопасности за счёт разнообразия. Если один из этих строительных блоков окажется слабым или небезопасным, вы сможете переключиться на другой.
Следует полагаться главным образом на наборы AEAD, которые обеспечивают строгую аутентификацию и обмен ключами, прямую секретность и шифрование с уровнем криптостойкости не менее 128 бит. Некоторые другие более слабые наборы всё ещё могут поддерживаться при условии, что их использование согласовывается только со старыми клиентами, которые не поддерживают ничего лучше.
Есть несколько устаревших криптографических примитивов, которых следует избегать:
Наборы с анонимным обменом по алгоритму Диффи-Хэллмана (Anonymous Diffie-Hellman, ADH) не обеспечивают аутентификацию.
NULL-наборы не обеспечивают шифрование.
Экспортные наборы шифров небезопасны при согласовании в соединении, кроме того, их можно использовать против сервера, который предпочитает более стойкие наборы (атака FREAK).
Наборы со слабыми шифрами (обычно с уровнем криптостойкости 40 и 56 бит) используют шифрование, которое может быть легко взломано.
RC4 небезопасны.
3DES медленны и слабы.
В качестве отправной точки используйте следующую конфигурацию наборов, разработанную для ключей RSA и ECDSA:
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 EDH-RSA-DES-CBC3-SHA
Примечание: В этом примере конфигурации используются нестандартные имена наборов, согласно требованиям OpenSSL. Для развёртываний в других окружениях (например, IIS) нужно использовать стандартные имена наборов TLS17.
В SSL v3 и более новых версиях протокола клиенты предлагают список поддерживаемых ими наборов шифров, а серверы выбирают один набор из списка для использования в устанавливаемом соединении. Однако не все серверы делают это правильно; некоторые выбирают первый поддерживаемый им набор из списка клиента. Активный выбор сервером наилучшего из доступных наборов шифров крайне важен для достижения максимальной безопасности.
Прямая секретность (forward secrecy) (иногда также называемая совершенной прямой секретностью (perfect forward secrecy) — функция протокола, которая позволяет организовать защищённые коммуникации, не зависящие от закрытого ключа сервера. При использовании наборов шифров, не обеспечивающих прямой секретности, злоумышленник, который сможет извлечь закрытый ключ сервера, может расшифровать все ранее сохранённые им зашифрованные переговоры. Вам нужно поддерживать и отдавать предпочтение наборам ECDHE, чтобы обеспечить прямую секретность с современными веб-браузерами. Для поддержки более широкого круга клиентов вам следует также использовать наборы DHE как запасной вариант после ECDHE. Избегайте обмена ключами RSA без крайней необходимости. Предложенная в разделе 2.3 конфигурация по умолчанию содержит только наборы, обеспечивающие прямую секретность.
Для обмена ключами публичные сайты обычно выбирают между классическим эфемерным обменом по алгоритму Диффи-Хеллмана (DHE) и его вариантом на эллиптических кривых ECDHE. Существуют и другие алгоритмы обмена ключами, но они, как правило, так или иначе небезопасны. Обмен ключами RSA до сих пор очень популярен, но он не обеспечивает прямой секретности.
В 2015 году группа исследователей опубликовала описание новой атаки на DHE; эта работа известна как атака Logjam18. Исследователи обнаружили, что обмен DH при использовании сессионных ключей с низкой стойкостью (например, 768 бит) может быть легко взломан, а также то, что некоторые хорошо известные 1024-битные DH-группы могут быть взломаны спецслужбами. Чтобы обеспечить безопасность при развертывании DHE, настройте его как минимум на использование 2048-битных параметров безопасности. Некоторые старые клиенты (например, Java 6) могут не поддерживать такой уровень стойкости. По соображениям производительности большинству серверов следует отдавать предпочтение более стойким и более быстрым алгоритмам обмена ECDHE. Именованная кривая secp256r1 (также известная как P-256) — хороший выбор в этом случае.
В последние годы было несколько серьёзных атак на SSL и TLS, но они, как правило, не должны вас беспокоить, если вы используете современное программное обеспечение и следуете приведённым в этом руководстве советам (если же нет, я рекомендую протестировать ваши системы в SSL Labs и последовать данным там рекомендациям). Однако ничто не является абсолютно безопасным, поэтому хорошей практикой будет следить за тем, что происходит в сфере безопасности. Оперативно применяйте исправления от поставщиков своих операционных систем и программного обеспечения, как только они станут доступны; пока же их нет, изучайте и применяйте обходные пути для нейтрализации угроз.
В этом руководстве мы главным образом сфокусированы на безопасности, но также мы должны обратить внимание на производительность. Защищённый сервис, не удовлетворяющий критериям производительности, несомненно, будет уязвим к атакам типа "отказ от обслуживания". При правильной настройке TLS может быть довольно быстрым. С современными протоколами, такими как HTTP/2, он может быть даже быстрее, чем обмен данными в незашифрованном виде.
Криптографическое рукопожатие, применяемое для установки защищённого соединения, — операция, затраты на которую во многом зависят от размера закрытого ключа. Использовать слишком короткие ключи небезопасно, с другой стороны, использование слишком длинных ключей приведёт к "чрезмерной" безопасности и замедлит работу. Для большинства веб-сайтов применение ключей RSA длиной более 2048 бит и ключей ECDSA длиной более 256 бит — это пустая трата ресурсов процессора. К тому же, у пользователя может создаться впечатление, что сайт "тормозит". Точно так же мало пользы в увеличении длины сессионных ключей при эфемерном обмене выше 2048 бит для DHE и 256 бит для ECDHE. Явных преимуществ от использования шифрования с уровнем криптостойкости выше 128 бит нет.
Возобновление сеанса — это метод оптимизации производительности, позволяющий сохранять результаты высокозатратных криптографических операций и повторно использовать их в течение какого-то периода времени. Отключение или неверная настройка механизма возобновления сеанса могут привести к значительному снижению производительности.
В наши дни издержки TLS связаны не только с затратными для процессора криптографическими операциями, но и с задержкой в сети. Рукопожатие TLS, которое может начаться только после завершения рукопожатия TCP, требует дальнейшего обмена пакетами и тем затратнее, чем дальше вы находитесь от сервера. Лучший способ минимизировать задержку — избегать создания новых соединений, другими словами, сохранять существующие соединения продолжительное время открытыми (keep-alive). Другие методы, обеспечивающие хорошие результаты: поддержка современных протоколов, таких как HTTP/2, и использование оптимизации WAN (обычно с помощью сетей доставки содержимого (Сontent delivery network, CDN)).
При обмене данными по TLS браузеры могут предполагать, что весь трафик конфиденциален и требует защиты. Как правило, они используют память для кеширования определённых ресурсов, но после закрытия браузера весь контент может быть потерян. Чтобы повысить производительность и обеспечить долгосрочное кеширование некоторых ресурсов, пометьте не являющиеся конфиденциальными ресурсы (например, изображения) как общедоступные.
Привязка OCSP (OCSP stapling) — расширение протокола OCSP, позволяющее доставлять информацию об отзыве сертификатов как часть рукопожатия TLS, непосредственно с сервера. В результате клиенту не требуется связываться с серверами OCSP для отдельного выполнения проверки и общее время соединения TLS значительно сокращается. Привязка OCSP — важный метод оптимизации, но следует иметь в виду, что не все веб-серверы обеспечивают её надежную реализацию. А с учётом того, что у некоторых УЦ могут быть медленные или ненадёжные ответчики OCSP, такие веб-серверы могут создавать проблемы с производительностью. Для достижения наилучших результатов смоделируйте условия сбоев, чтобы увидеть, могут ли они повлиять на доступность вашего сайта.
В дополнение к обеспечению наилучшей защищённости, рекомендуемая мною конфигурация наборов шифров также обеспечивает лучшую производительность. Там, где это возможно, используйте процессоры с поддержкой аппаратного ускорения AES. Кроме того, если вам действительно нужен дополнительный прирост производительности (для большинства сайтов это, скорее всего, лишнее), рассмотрите возможность использования ключей ECDSA.
После появления SSL протокол HTTP и окружающие его платформы для доставки веб-приложений продолжали быстро развиваться. В результате этого развития в настоящий момент платформы содержат функции, использование которых может привести к сбоям или даже отключению шифрования. В данном разделе мы перечислим эти функции, а также способы безопасного их использования.
Тот факт, что шифрование не является обязательным, — вероятно, одна из самых больших проблем безопасности сегодняшнего дня. Мы видим следующие проблемные места:
Отсутствие TLS на сайтах, которые нуждаются в этом.
Сайты, которые поддерживают TLS, но не задействуют его.
Сайты, которые смешивают контент TLS и не TLS, иногда даже на одной странице.
Сайты с программными ошибками, приводящими к сбоям или уязвимостям TLS.
Несомненно, можно найти решения для нейтрализации большинства этих проблем, но единственный способ надёжно защитить обмен данными с веб-сайтом — применять шифрование повсеместно, без исключения.
Страницы со смешанным контентом — это страницы, которые передаются по TLS, но содержат ресурсы (например, файлы JavaScript, изображения, файлы CSS), которые не передаются по TLS. Такие страницы небезопасны. Активный злоумышленник, работающий по принципу "человек посередине" (man-in-the-middle, MITM), может, например, воспользоваться одним незащищенным ресурсом JavaScript и захватывать весь пользовательский сеанс. Даже если вы следуете совету из предыдущего раздела и шифруете ваш веб-сайт целиком, вы всё равно можете получать какие-то незашифрованные ресурсы со сторонних веб-сайтов.
Веб-сайты часто используют сторонние сервисы, активированные с помощью JavaScript-кода, загруженного с другого сервера. Отличный пример такого сервиса — Google Analytics, повсеместно используемый в Интернете. Такое включение стороннего кода создаёт неявное доверительное соединение, в результате которого другая сторона получает полный контроль над вашим веб-сайтом. Третья сторона может и не быть злонамеренной, но крупные поставщики таких услуг всё чаще рассматриваются в качестве целей для атак. Причина проста: если крупный поставщик будет взломан, злоумышленник автоматически получит доступ ко всем сайтам, зависящим от его сервисов.
Если вы следуете совету из раздела 4.2, то ваши сторонние ссылки по крайней мере будут зашифрованы и таким образом защищены от атак MITM. Однако вам следует пойти дальше: изучить, какие сервисы вы используете, и либо удалить их или заменить на более безопасные альтернативы, либо принять риск от продолжения их использования. Для уменьшения потенциального воздействия через сторонние ресурсы может быть использована новая технология, называемая целостностью субресурсов (subresource integrity, SRI)19.
Для того, чтобы быть должным образом защищённым, кроме TLS веб-сайту также требуется, чтобы все его cookie при создании явно помечались как безопасные (установкой флага Secure). Небезопасные файлы cookie позволяют активному злоумышленнику MITM с помощью хитрых уловок получить некоторую информацию даже на веб-сайтах, которые на 100% зашифрованы. Для достижения наилучших результатов рассмотрите возможность добавления в ваши cookie криптографической проверки целостности или даже шифрования.
Атака CRIME 2012 года показала, что сжатие TLS не может быть реализовано безопасно. Единственным решением было его полное отключение. В следующем году появились ещё два варианта такой атаки: TIME и BREACH, сфокусированные на секретах в теле ответа HTTP, сжатого с использованием сжатия HTTP. В отличие от сжатия TLS, HTTP-сжатие является необходимым и не может быть отключено. Таким образом, чтобы противостоять этим атакам, нужно вносить изменения в код приложения20.
Атаки TIME и BREACH нелегко осуществить, но если кто-то достаточно мотивирован их использовать, воздействие будет примерно эквивалентно успешному выполнению атаки типа "Межсайтовая подделка запроса" (Cross-Site Request Forgery, CSRF).
Механизм HTTP Strict Transport Security (HSTS) — это подстраховка для TLS. Он был разработан, чтобы гарантировать, что безопасность остается неизменной даже в случае возникновения проблем конфигурации и ошибок реализации. Для активации защиты HSTS нужно добавить новый заголовок ответа на свои веб-сайты. После этого браузеры, поддерживающие HSTS (сейчас это все современные браузеры), начнут его применять.
Цель HSTS проста: после активации он не допускает какой-либо незащищенный обмен данными с использующим его веб-сайтом. Эта цель достигается за счёт автоматического преобразования всех ссылок на незащищённые ресурсы (http) в ссылки на аналогичные защищённые ресурсы (https). В качестве бонуса также блокируется возможность обходить предупреждения о проблемах сертификата. (Предупреждения о проблемах сертификата — индикатор активной атаки MITM. Исследования показали, что большинство пользователей выбирают опцию обхода этих предупреждений для продолжения работы с сайтом, поэтому в ваших же интересах никогда не позволять такого развития событий.)
Добавление поддержки HSTS — это самое важное улучшение, которое вы можете сделать для TLS-защиты своих веб-сайтов. Новые сайты всегда должны разрабатываться с учётом HSTS, а старые должны (если это возможно) быть преобразованы для его поддержки в кратчайшие сроки. Для достижения лучшей защищённости рассмотрите возможность включения сайта в статический список сайтов с HSTS (HSTS preload list)21, который позволяет встроить вашу конфигурацию HSTS в современные браузеры, делая даже первое соединение с вашим сайтом защищённым.
Пример конфигурации, активирующей HSTS для основного доменного имени и всех поддоменов на период один год, а также разрешающей предварительную загрузку из статического списка:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
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, следует изменить свою политику и вернуть их назад.
Весь конфиденциальный контент должен передаваться только тем абонентам, которым он предназначен, и обрабатываться соответствующим образом всеми устройствами. С одной стороны, прокси-серверы не видят зашифрованный трафик и не могут распространять контент среди своих пользователей. С другой стороны, использование облачных платформ доставки приложений расширяется, поэтому вам нужно быть очень осторожным при определении того, что является общедоступным, а что нет.
Протокол TLS предназначен для обеспечения только определённых аспектов безопасности — конфиденциальности и целостности связи между вами и вашими пользователями. Но существует множество других угроз, с которыми вам придётся сталкиваться. В общем случае вам необходимо убедиться в том, что у вашего веб-сайта нет других уязвимостей.
Имея множество доступных для настройки параметров конфигурации, трудно заранее знать, какое влияние окажут те или иные изменения. Кроме того, изменения иногда вносятся непреднамеренно, например, обновления программного обеспечения могут менять значения, принимаемые параметрами по умолчанию, или вносить новые настройки. Поэтому мы рекомендуем изначально использовать комплексные инструменты оценки SSL/TLS для проверки своей конфигурации, чтобы убедиться, что ваш веб-сайт начинает работать в защищенном состоянии, а затем периодически проводить повторные проверки, чтобы гарантировать, что защищённое состояние сайта не нарушено. Для общедоступных сайтов мы рекомендуем бесплатный тест сервера от SSL Labs22.
Перечисленные ниже продвинутые темы в настоящее время выходят за рамки нашего руководства. Они требуют глубокого понимания SSL/TLS и инфраструктуры открытых ключей (Public Key Infrastructure, PKI), и всё ещё находятся в стадии обсуждения экспертным сообществом.
Привязывание открытого ключа (public key pinning) разработано, чтобы дать операторам веб-сайтов средства для ограничения того, какие УЦ могут выдавать сертификаты для их сайтов. Эта функция была развернута и эксплуатируется Google в течение некоторого времени (встроена в их браузер Chrome) и доказала свою полезность для предотвращения атак и информирования общественности о них. В 2014 году Firefox также добавил поддержку встроенного привязывания. В 2015 году принят стандарт под названием Расширение привязывания открытого ключа для HTTP23. Привязывание открытого ключа устраняет самый большой недостаток PKI (тот факт, что любой удостоверяющий центр может выдать сертификат для любого веб-сайта), но это обходится недёшево; развёртывание требует значительных усилий и компетенции, а также создаёт риск потери контроля над вашим сайтом (если в итоге вы получите неверную конфигурацию привязывания). В целом, следует рассматривать возможность привязывания только в том случае, если вы управляете сайтом, который может быть реально атакован посредством мошеннического сертификата.
Расширения безопасности системы доменных имен (Domain Name System Security Extensions, DNSSEC) — набор технологий, добавляющий возможность обеспечения целостности в систему доменных имен. Сегодня активный злоумышленник может легко перехватить любой DNS-запрос и отправить на него поддельные произвольные ответы. С помощью DNSSEC криптографическим путём (с помощью электронных подписей) можно отследить целостность ответов DNS по всей цепочке до корня DNS. Базирующаяся на DNS аутентификация именованных объектов (DNS-based Authentication of Named Entities, DANE) — это отдельный стандарт, работающий совместно с DNSSEC, предназначенный для обеспечения привязки сведений между DNS и TLS. DANE может быть использована для повышения безопасности существующей экосистемы PKI на основе удостоверяющих центров, или для её обхода путём построения альтернативных цепочек доверия.
Хотя не все согласны с тем, что DNSSEC является хорошим направлением развития Интернета, его поддержка продолжает улучшаться. Браузеры пока не поддерживают DNSSEC или DANE (предпочитая аналогичные функции, предоставляемые HSTS и HPKP), но есть некоторые признаки того, что эти технологии начинают использоваться для повышения безопасности доставки электронной почты.
Первый выпуск этого руководства состоялся 24 февраля 2012 года. В этом разделе перечислены изменения документа начиная с версии 1.3.
В этой версии были сделаны следующие изменения:
Рекомендовано немедленно заменить сертификаты с 1024-битными ключами.
Рекомендовано отказаться от поддержки SSL v3.
Удалена рекомендация использовать RC4 для нейтрализации атаки BEAST на стороне сервера.
Рекомендовано отключить RC4.
Рекомендовано в ближайшем будущем отключить 3DES.
Дано предупреждение о вариантах атаки CRIME (TIME и BREACH).
Рекомендована поддержка прямой секретности.
Добавлено обсуждение сертификатов ECDSA.
В этой версии были сделаны следующие изменения:
Обсуждается, что алгоритм SHA1 устарел и рекомендуется переходить на семейство SHA2.
Рекомендовано отключить SSL v3 и упомянута атака POODLE.
Раздел 3.1 дополнен обсуждением оптимальной стойкости алгоритмов обмена ключами DHE и ECDHE.
Привязка OCSP рекомендована как мера повышения производительности, её обсуждению посвящён раздел 3.5.
В этой версии были сделаны следующие изменения:
Обновлён документ в целом с учётом современных тенденций.
Рекомендовано использовать наборы шифров с аутентификацией.
Больше внимания уделено обсуждению стойкости обмена ключами и атаке Logjam.
Удалена рекомендация отключать повторное согласование, инициированное клиентом. Современное программное обеспечение итак делает это, а отключить данный функционал в более старом программном обеспечении порой либо невозможно, либо очень сложно. С другой стороны, вектор производимых таким способом DoS-атак не особенно силён. Так что лучше потратить имеющиеся ресурсы на исправление чего-то другого.
Добавлено предупреждение о нестабильных реализациях привязки OCSP.
Добавлено упоминание о технологии обеспечения целостности субресурсов.
Добавлено упоминание о проверке целостности и шифровании cookie.
Добавлено упоминание о статическом списке сайтов с HSTS.
Рекомендовано использовать CSP для лучшей обработки стороннего смешанного контента.
Упомянуты атаки FREAK, Logjam и DROWN.
Удалён раздел, в котором обсуждались средства предотвращения различных утративших актуальность (особенно если приведённые здесь советы выполнялись) атак на TLS. Обсуждение вариантов атаки CRIME перенесено в новый раздел.
В раздел "Продвинутые темы" добавлено краткое обсуждение DNSSEC и DANE.
Особая благодарность Marsh Ray, Nasko Oskov, Adrian F. Dimcev и Ryan Hurst за их ценные отзывы и помощь в разработке первоначальной версии этого документа. Также спасибо всем тем, кто щедро делится с миром своими знаниями по безопасности и криптографии. Представленные здесь советы и принципы опираются на работу всего сообщества по защите информации.
SSL Labs (www.ssllabs.com) — это исследовательская инициатива от Qualys, направленная на то, чтобы разобраться в SSL/TLS и PKI, а также предоставить инструменты и документацию для помощи в их оценке и настройке. С момента запуска SSL Labs в 2009 году с помощью разработанного ими бесплатного онлайн-инструмента оценки были проведены сотни тысяч проверок защищённости веб-сайтов. SSL Labs запущены и другие проекты, в том числе периодические исследования конфигурации TLS в Интернете, а также SSL Pulse — ежемесячное сканирование около 150 000 самых популярных веб-сайтов с поддержкой TLS в мире.
Qualys, Inc. (NASDAQ: QLYS) является пионером и ведущим поставщиком решений в области облачной безопасности и обеспечения соответствия требованиям защиты информации. У компании свыше 8 800 клиентов в более чем 100 странах мира, включая большинство компаний из списков Forbes Global 100 и Fortune 100. Облачная платформа QualysGuard и интегрированный набор решений помогают организациям упростить операции по обеспечению безопасности и снизить стоимость соответствия требованиям защиты информации, предоставляя по запросу критически важные сведения по безопасности и автоматизируя весь спектр аудита, обеспечения соответствия требованиям, а также защиты для IT-систем и веб-приложений. Основанная в 1999 году, Qualys установила стратегические партнерские отношения с ведущими поставщиками управляемых услуг и консалтинговыми организациями, в том числе Accenture, BT, Cognizant Technology Solutions, Dell SecureWorks, Fujitsu, HCL Comnet, Infosys, Optiv, NTT, Tata Communications, Verizon и Wipro. Также компания является одним из основателей Cloud Security Alliance (CSA).
[17] Параметры Transport Layer Security (TLS) (IANA, проверено 18 марта 2016 г.)
[18] Уязвимость алгоритма Диффи-Хеллмана и атака Logjam (проверено 16 марта 2016 г.)
[19] Целостность субресурсов (Mozilla Developer Network, проверено 16 марта 2016 г.)
[20] Защита от атаки BREACH (Qualys Security Labs; 7 августа 2013 г.)
[21] Статический список сайтов с HSTS (Google developers, проверено 16 марта 2016 г.)
[22] SSL Labs (проверено 16 марта 2016 г.)
[23] RFC 7469: Расширение привязывания открытого ключа для HTTP (Evans и другие, апрель 2015 г.)