Информация для разработчиков сайтов о SSL сертификатах

• Recommendations for the Processing of EV SSL Certificates.v.2.0
• Mozilla’s List of Included Root CAs https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&single=true&gid=1&output=html
• W3C’s Web Security Context: User Interface Guidelines
• FIPS 186-4, the Digital Signature Standard
• NIST Special Publications on Computer Security, especially:
• NIST Special Publication 800-21: Guideline for Implementing Cryptography In the Federal Government
• NIST Special Publication 800-52: Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations
• NIST Special Publication 800-131A: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NSA Suite B Cryptography

Private Key

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

1. Используйте 2048-bit private keys Используйте 2048-битные частные ключи для всех ваших серверов. Ключи этой длины являются безопасными и будут оставаться в безопасности в течение значительного времени.
2. Защищайте private keys Относитесь к своим секретным ключам как к важному активу, ограничивая доступ к минимально возможной группе сотрудников, сохраняя при этом все практические меры. Рекомендуемые политики включают следующее:
   • Защищать паролем ключи шифрования для предотвращения компрометации при их хранении в системах резервного копирования.
   • Если есть подозрение на утечку приватного ключа - отменить старые сертификаты и сгенерируйте новые ключи для использования с новыми сертификатами.
   • Обновлять сертификаты каждый год - всегда с помощью новых закрытых ключей..

Убедитесь что все используемые домены вашего сайта защищены сертификатом SSL

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

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

Обычно рекомендуется избегать сертификатов wildcard. Хотя они не менее безопасны с строго технической точки зрения, но они обычно используются несколькими администраторами. что на практике делает их менее безопасными.

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

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

• Уровень безопасности Все ЦС проходят регулярные аудиты (иначе они не смогут работать как ЦС), но некоторые более серьезно относятся к безопасности, чем другие. Выяснить, какие из них лучше в этом отношении, непросто, но один из вариантов - изучить их историю безопасности и, что более важно, как ЦС отреагировал на ситуацию и анализ своих ошибок.
• Доля рынка ЦС, который узнаваем в Украине и имеет незапятнаную репутацию
• Бизнес-фокус CA, чья деятельность составляет значительную часть своего бизнеса, имеет все, чтобы исправить ситуацию, если что-то пойдет не так, и они, вероятно, не будут пренебрегать своим подразделением сертификатов, преследуя потенциально более прибыльные возможности в других местах.
• Предлагаемый сервис Как минимум, выбранный вами ЦС должен обеспечивать поддержку отзыва CRL и OCSP, а также предоставлять сервис OCSP с хорошей производительностью. Они должны предлагать сертификаты с подтверждением домена (DV) и Extended Validation (EV), в идеале с вашим выбором алгоритма с открытым ключом. Большинство веб-сайтов сегодня используют RSA, но EC и DSA могут стать важным в будущем из-за их преимуществ в производительности.
• Управление сертификатами Если вам нужно большое количество сертификатов, выберите бизнес, который даст вам хорошие инструменты для их управления.
• Поддержка Выберите бизнес, который даст вам хорошую поддержку в любое время.

Убедитесь, что цепочка сертификатов действительна

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

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

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

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

В семействе SSL / TLS существует пять протоколов: SSL v2, SSL v3, TLS v1.0, TLS v1.1 и TLS v1.2. Из этих:
• SSL v2 небезопасен и не должен использоваться.
• SSL v3 and TLS v1.0 в значительной степени сохраняются; мы не знаем о серьезных недостатках безопасности, когда они используются для протоколов, отличных от HTTP. При использовании с HTTP они могут быть практически безопасными с тщательной настройкой.
• TLS v1.1 and v1.2 не имеют известных проблем безопасности. К сожалению, многие серверные и клиентские платформы не поддерживают эти новые версии протокола.

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

Для поддержки старых клиентов вам необходимо будет поддерживать TLS v1.0 и TLS v1.1. С некоторыми обходными решениями эти протоколы по-прежнему можно считать безопасными для большинства веб-сайтов. Как правило, вы всегда должны использовать самые последние версии протокола для безопасности и самые старые версии при условии, что они все еще защищены для взаимодействия с вашей базой пользователей.

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

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

• Anonymous Diffie-Hellman (ADH) suites не обеспечивают аутентификацию.

• NULL cipher suites нет шифрования.

• Export key exchange suites use authentication - Экспортные пакеты обмена ключами используют аутентификацию, которая может быть легко нарушена

• Suites со слабыми ciphers ( 40 и 56 bits) используют шифрование, которое можно легко сломать.

Выбор группы поддерживаемых шифров cipher suite

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

Отключите переподключение client-initiated renegotiation для клиентов

В SSL / TLS повторное переподключение позволяет сторонам прекратить обмен данными на мгновение и пересмотреть вопрос о том, как обеспечивается связь. Есть некоторые случаи, когда перезапуск должен быть инициирован сервером, но нет никакой для этого необходимости у клиентов. Кроме того, инициированное клиентом переподключение может сделать ваши серверы более легкими для атаки с использованием атак типа «отказ в обслуживании» (DoS).

Смягчение известных проблем

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

1. Отключить небезопасный пересмотр В 2009 году выяснилось что функция перерегистрации оказалась небезопасной, и протоколы необходимо было обновить. Большинство поставщиков уже выпустили исправления или, по крайней мере, предоставили обходные пути для решения этой проблемы.
2. Приоритет RC4 для смягчения атаки BEAST В 2011 произошла практическая атака, основанная на проблеме протокола, первоначально обнаруженная в 2004 году. Несмотря на то, что в 2006 году была рассмотрена в TLS v1.1, проблема по-прежнему актуальна, поскольку большинство клиентов и серверов не поддерживают новых версий протокола. Практическое смягчение требует, чтобы ваши серверы говорили только с RC4 при использовании TLS v1.0 или SSL v3.4. В начале 2013 года RC4 оказался более слабым, чем считалось ранее, заставляя всех выбирать между адресацией BEAST или отключением RC4. Оба могут быть адресованы с TLS 1.1 и выше, но несколько браузеров поддерживают эти новые протоколы. На самом деле риски от слабых сторон BEAST и RC4 малы, но при выборе одного из двух мы предпочитаем смягчать атаку BEAST ,
3. Отключение сжатия в TLS В 2012 году атака CRIME5 показала, как злоумышленники могут использовать утечку информации, вызванную сжатием TLS, чтобы выявить части конфиденциальных данных (например, cookie сеансов). Очень немногие клиенты поддерживали TLS-сжатие, что означает, что вряд ли вы столкнетесь с какой-либо проблемой производительности, отключив компрессии TLS на своих серверах.

Представление

• Не используйте слишком длинные секретные ключи Криптографическое рукопожатие, которое используется для установления защищенных соединений, - это операция, стоимость которой сильно зависит от размера частного ключа. Использование слишком короткого ключа небезопасно, но использование слишком длинного ключа приведет к «слишком большой» безопасности и медленной работе. Для большинства веб-сайтов использование ключей, более сильных, чем 2048 бит, является потерей мощности процессора и может ухудшить работу пользователя.
• Убедитесь, что возобновление сеанса работает Возобновление сеанса - это метод оптимизации производительности, который позволяет сохранить результаты дорогостоящих криптографических операций и повторно использовать их в течение определенного периода времени. Неисправный или нефункциональный механизм возобновления сеанса может привести к значительному снижению производительности.
• Использование постоянных соединений (HTTP) В наши дни большая часть накладных расходов на SSL возникает не из криптографических операций с процессором, а из задержек в сети. После того, как рукопожатие TCP завершено, квитирование SSL выполняется. он требует дальнейшего обмена пакетами. Чтобы свести к минимуму затраты на задержку, вы включаете HTTP-сохранение (keep-alives), позволяя пользователям отправлять много HTTP-запросов по одному TCP-соединению.
• Включить кеширование публичных ресурсов (HTTP) При обмене данными через SSL браузеры считают, что весь трафик не изменен. Обычно они используют память для кэширования определенных ресурсов, но как только вы закроете браузер, все содержимое может быть потеряно. Чтобы повысить производительность и обеспечить долгосрочное кэширование некоторых ресурсов, отметьте общедоступные ресурсы (например, изображения) общедоступными, добавив к ним заголовок ответа Cache-Control: public.

Разработка приложений (HTTP)

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

• Зашифруйте 100% трафика вашего сайта То, что шифрование является дополнительным фактором, вероятно, является одной из самых больших проблем безопасности сегодня. Есть следующие проблемы:
  • Отсутствие SSL сертификата на сайтах которые в этом нуждаются
  • Сайты, имеющие SSL, но не применяющие его • Сайты, которые смешивают контент SSL и не SSL, иногда даже на одной странице • Сайты с ошибками программирования, которые подрывают авторитет SSL

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

• Убедитесь, что файлы cookie защищены Чтобы обеспечить надлежащую защиту, веб-сайт требует SSL, но также, что все его файлы cookie отмечены как безопасные. Несоблюдение безопасности файлов cookie позволяет активному злоумышленнику (MITM) дразнить какую-то информацию с помощью умных трюков даже на веб-сайтах, которые на 100% зашифрованы.
• Убедитесь, что смешанный контент не используется Страницы смешанного контента - это те, которые передаются через SSL, но включают в себя ресурсы (например, файлы JavaScript, изображения, файлы CSS), которые не передаются через SSL. Такие страницы не защищены. Например, активный злоумышленник MITM может копировать на одном незащищенном ресурсе JavaScript, например, и захватывать весь сеанс пользователя.
• Включить HTTP Strict Transport Security HTTP Strict Transport Security (HSTS) - это безопасная сеть для SSL: она была разработана для обеспечения безопасности системы даже в случае проблем с конфигурацией и ошибок реализации. Чтобы активировать защиту HSTS, вы устанавливаете один заголовок ответа на своих веб-сайтах. После этого браузеры, поддерживающие HSTS (в это время Chrome, Firefox и Opera), будут применять его. Цель HSTS проста: после активации она не позволяет использовать какую-либо небезопасную связь с веб-сайтом, который ее использует. Он достигает этой цели, автоматически преобразуя все текстовые ссылки в безопасные. В качестве бонуса он также отключает предупреждения сертификатов SSL через клики. (Предупреждения SSL-сертификата являются индикатором активной атаки MITM. Исследования показали, что большинство пользователей щелкают этими предупреждениями, поэтому в ваших интересах никогда не допускать их.) Добавление поддержки HSTS - это самое важное усовершенствование, которое вы можете сделать для обеспечения безопасности SSL на своих веб-сайтах. Новые сайты всегда должны быть спроектированы с учетом HSTS, а старые сайты конвертированы для поддержки, где это возможно.
• Отключить кеширование конфиденциального контента Обеспечение того чтобы конфиденциальный контент передавался только заинтересованным сторонам и считался недоступным третьим лицам. Хотя прокси-серверы не видят зашифрованный трафик и не могут делиться контентом среди пользователей, использование облачных платформ доставки приложений растет, поэтому вам нужно быть очень осторожными при указании того, что является общедоступным, а что нет.
• Убедитесь, что других уязвимостей нет Использование SSL сертификата не означает безопасноть. SSL предназначен для решения только одного аспекта безопасности - конфиденциальности и целостности связи между вами и вашими пользователями, - но есть много других угроз, с которыми вам нужно иметь дело. В большинстве случаев это означает, что ваш веб-сайт не имеет других недостатков.
• Понять и признать опасности третьей стороны Веб-сайты часто используют сторонние службы, активированные с помощью кода JavaScript, загруженного с другого сервера. Хорошим примером такой услуги является Google Analytics, которая используется на больших частях Интернета. Такое включение стороннего кода создает неявное доверительное соединение, которое эффективно дает другой стороне полный контроль над вашим веб-сайтом. Третья сторона не может быть злонамеренной, но крупные поставщики таких услуг все чаще рассматриваются в качестве целей. Простые рассуждения: если крупный поставщик взломан, злоумышленник автоматически получает доступ ко всем сайтам, которые зависят от службы.

Проверка

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

Темы для экспертов

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

• Сертификаты расширенной валидации Сертификаты расширенной валидации (EV) являются сертификатами с высокой степенью достоверности, выпущенными только после тщательных проверок в автономном режиме. Их цель - обеспечить прочную связь между организацией и их идентификацией в Интернете. Сертификаты EV сложнее подделать, обеспечить немного лучшую безопасность и улучшить обработку, когда браузеры представляют их конечным пользователям. Большинство компаний выиграют от использования сертификатов EV на своих веб-сайтах.
• Фиксирование открытого ключа. Привязка открытого ключа предназначена для предоставления операторам веб-сайтов средств для ограничения того, какие центры сертификации могут выдавать сертификаты для своих веб-сайтов. Эта функция была развернута Google в течение некоторого времени (жестко закодирована в их браузере, Chrome) и оказалась очень полезной для предотвращения атак и информирования общественности о них. В настоящее время разрабатываются два предложения: расширение открытого ключа для HTTP, рабочей группой Web Security и доверенные сертификаты для ключей сертификатов, Marlinspike и Perrin.
• Прямая секретность. Первичная секретность - это функция протокола, которая обеспечивает безопасные разговоры, не зависящие от закрытого ключа сервера. С наборами шифров, которые не поддерживают прямую секретность, кто-то, кто может восстановить закрытый ключ сервера, может дешифровать все ранее записанные зашифрованные разговоры.
• OCSP Stapling OCSP Stapling - это модификация протокола OCSP, которая позволяет связать информацию об отзыве с самим сертификатом и, таким образом, напрямую обслуживать сервер от браузера. В результате браузеру не нужно связываться с серверами OCSP для внеполосной проверки, что приводит к лучшей производительности.