Лучшая практика развертывания SSL/TLS, часть 1. Теория

https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
  • Перевод
  • Tutorial
Часть 2

Делимся переводом полезной статьи о том, как правильно развернуть SSL/TLS на вашем сайте. Сегодня — теория, вторая (практическая) часть будет после запуска.

Введение


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

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

1. Приватный ключ и сертификат

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

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

Используйте 2048-битный RSA или 256-битные ECDSA закрытые ключи для всех ваших серверов. Ключи такой крепости безопасны и будут оставаться безопасными в течение значительного периода времени. Если у вас есть 1024-битные RSA ключи, то следует заменить их более сильными ключами как можно скорее.

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

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

• Генерируйте закрытые ключи и запросы на сертификат (CSRs) на доверенном компьютере. Некоторые CA предлагают генерацию ключей и CSRs для вас, но это нецелесообразно.

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

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

• Обновляйте сертификаты каждый год и всегда с новыми закрытыми ключами.

1.3 Обеспечьте охват всех используемых доменных имен

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

Даже тогда, когда на сервере настроено только одно доменное имя, нужно иметь в виду, что вы не можете контролировать, как пользователи приходят к вам на сайт или какие ссылки на него указывают. В большинстве случаев, вы должны убедиться, что сертификат работает с и без WWW (например, как для example.com и www.example.com). Безопасный веб-сервер должен иметь сертификат, действительный для каждого настроенного доменного имени. Сертификаты на весь домен (Wildcard) имеют свое преимущество, но следует избегать их, если их использование означает предоставление закрытого ключа большой группе людей, например, системным администраторам разных организации. Кроме того, имейте в виду, что Wildcard сертификаты могут быть использованы злоумышленниками для передачи уязвимости от одного веб-сайта на все другие сайты, которые используют один и тот же сертификат.

1.4. Приобретайте сертификаты у надежного удостоверяющего центра

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

Отношение к безопасности

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

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

Предлагаемые услуги

Как минимум, выбранный CA должен обеспечивать поддержку списка отозванных сертификатов (CRL) и протокола OCSP.

Инструменты управления сертификатами

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

Поддержка

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

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

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

Вам нужно немедленно заменить все ваши сертификаты, использующие алгоритм SHA1, если они истекают после 2015 года.
Usedesk
26,00
Cервис для поддержки и общения с клиентами
Поделиться публикацией

Похожие публикации

Комментарии 12

    +3
    Допишите, что SSL небезопасен (poodle attack) и должен быть отключен на серверах как можно скорее.
      0
      Практическая часть и детали конфигураций будут во второй части статьи и все уязвимости и пути их устранения будут там рассмотрены)
        0
        Вы через строчку пишете про развертывание SSL/TLS через слеш. А SSL свертывать надо как можно скорее.
          0
          В названий статьи имеется в виду технология в целом. TLS-протокол основан на спецификации протокола SSL версии 3.0.
          Про уязвимости ssl мы расскажем, как и говорили, уже во второй части.
      0
      Это вечная проблема — как хранить ключи на серверах. Особенно, если это чужие сертификаты (например, TLS для раздачи статики на CDN).
        +1
          +1
          Спасибо за ссылку. Не знал. Однако, получившаяся конструкция требует постоянно живого key-server'а у кастомера, что совсем не счастье с точки зрения стабильности. Для раздачи статики и вовсе не подходит.

          Вот что я бы хотел видеть, если про улучшения говорить, так это temporal delegation, когда владелец сертификата может выписывать on behave сертификаты с не очень большим сроком (а если честно — на своё усмотрение), на указанный (и подписанный тем же CA) сертификат у которого есть право быть таковым.

          Сервер предъявляет клиенту цепочку сертификатов до клиента, предъявляет свой сертификат, доказывает владение своим секретом. Клиент сравнивает сертификат сайта, сертификат прокси, соглашается, делает сессию.

          От «отдать приватный ключ» это отличается тем, что ключ общий для всех обслуживаемых ssl-сертификатов проксёй, при его компрометации:

          1) отзывается один сертификат, а не стопятьсот у разных клиентов.
          2) У on behave сертификата ограниченный короткий срок жизни.

          Общий CA гарантирует, что не будет «mitm'а с on-behave от китайско-турецких CA», плюс нужна подпись оригинального владельца сертификата.

          Но CA'шный бизнес строго против дешёвых сертификатов, которые могут удостоверять другие сертификаты. Печалька…

          ЗЫ А вообще, очень хорошая идея: один wildcard, который может удостоверять сертификат на конкретные поддомены.
        +1
        Хотелось бы советов как поступать с *.domain.tld сертификатами. Вернее что делать с приватным ключом — его приходится давать слишком многим… Есть какие-то варианты?!
          +1
          Странные советы. Ни слова по делу: выбор шифров, протоколов, настроек PFS, TLS Tickets, false start и прочее…
            0
            это статья об огранизационных, а не технических моментах.

            BP — организационная часть
            RB — техническая часть
            0
            Друзья, вышла часть 2
              0
              del

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое