SSL /TLS Лучшие практики на 2023 год

В 2023 году защита вашего сайта с помощью SSL /TLS сертификат больше не является обязательным, даже для предприятий, которые не имеют дела непосредственно с конфиденциальной информацией о клиентах в Интернете. Поисковые системы, такие как Google, используют безопасность сайта в качестве сигнала ранжирования SEO, а популярные веб-браузеры, такие как Chrome, предупреждают пользователей о веб-сайтах, которые не используют HTTPS:

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

Выберите надежный центр сертификации (CA)

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

• Делает большую часть своей деятельности в сфере общественного доверия PKI. Эти предприятия могут больше всего потерять, если обнаружатся плохие методы обеспечения безопасности, и все, что нужно, чтобы идти в ногу с развивающимися отраслевыми стандартами.
• Эффективно и действенно реагирует на обнаружение уязвимостей, влияющих на безопасность и конфиденциальность пользователейтакие как общеотраслевой серийный номер энтропии выпуск в начале 2019 года. Поиск отраслевых форумов, таких как mozilla.dev.security.policy может дать вам хорошее представление о том, как конкретный ЦС реагирует на неприятности.
• Предлагает полезные товары и услуги, например сертификаты с расширенной проверкой (EV), массовая / автоматическая выдача сертификатов через интуитивно понятный API или Протокол ACME, простые службы управления жизненным циклом сертификатов и мониторинга, а также поддержка для интеграции с обширным списком сторонних решений.
• Имеет репутацию отличного обслуживания клиентов и технической поддержки. Обеспечение безопасности веб-сайта вашей компании на 100% очень важно, и вам нужно иметь возможность связаться с настоящим экспертом по телефону, когда что-то пойдет не так.

Авторизация центра сертификации (CAA)

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

Генерация и защита ваших личных ключей

Ассоциация SSL /TLS протокол использует пара ключей аутентифицировать личности и шифровать информацию, отправляемую через Интернет. Один из них ( Открытый ключ) предназначен для широкого распространения, а другой закрытый ключ) следует хранить как можно надежнее. Эти ключи создаются вместе, когда вы генерируете запрос на подпись сертификата (CSR), Вот несколько указаний, которые следует учитывать в отношении ваших личных ключей:

• Используйте сильные личные ключи: Большие ключи труднее взломать, но они требуют больше вычислительных ресурсов. В настоящее время рекомендуется использовать как минимум 2048-битный ключ RSA или 256-битный ключ ECDSA, и большинство веб-сайтов могут обеспечить хорошую безопасность, оптимизируя производительность и удобство работы с этими значениями.
  
  Примечание: обзор этих двух алгоритмов см. в статье SSL.com, Сравнение ECDSA и RSA.
• Защитите свои личные ключи:
  • Создайте свои собственные личные ключи в безопасной и надежной среде (предпочтительно на сервере, на котором они будут развернуты, или на устройстве, совместимом с FIPS или Common Criteria). Никогда разрешить CA (или кому-либо еще) создавать закрытые ключи от вашего имени. Авторитетный общедоступный центр сертификации, такой как SSL.com, никогда не предложит сгенерировать или обработать ваши закрытые ключи, если они не созданы в защищенном аппаратном токене или HSM и не подлежат экспорту.
  • Предоставляйте доступ к закрытым ключам только по мере необходимости. Генерация новых ключей и отзывать все сертификаты для старых ключей, когда сотрудники с доступом к закрытому ключу покидают компанию.
  • Обновляйте сертификаты как можно чаще (рекомендуется не реже одного раза в год), желательно каждый раз используя только что сгенерированный закрытый ключ. Инструменты автоматизации, такие как Протокол ACME полезны для планирования частого обновления сертификатов.
  • Если закрытый ключ был (или мог быть) скомпрометирован, отзывать все сертификаты для этого ключа, сгенерируйте новую пару ключей и выпустите новый сертификат для новой пары ключей.

Настройте свой сервер

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

• Убедитесь, что все имена хостов включены: Ваш сертификат покрывает доменное имя вашего сайта как с, так и без www префикс? Есть ли Альтернативное имя субъекта (SAN) для каждого доменного имени сертификат предназначен для защиты?
• Установите полные цепочки сертификатов: Конечный объект SSL /TLS сертификаты обычно подписываются промежуточными сертификатами, а не корневым ключом ЦС. Убедитесь, что на вашем веб-сервере установлены все промежуточные сертификаты, чтобы обеспечить браузерам полную путь сертификации и избегайте предупреждений и ошибок доверия для конечных пользователей. Ваш CA сможет предоставить вам любых необходимых посредников; Клиенты SSL.com могут использовать наши Промежуточный сертификат Скачать страница для получения промежуточных пакетов для многих серверных платформ.
• Использовать текущий SSL /TLS Протоколы (TLS 1.2 или 1.3): В конце 2018 года все основные производители браузеров объявили о планах отказаться от TLS 1.0 и 1.1 к первой половине 2020 года. Google устарела TLS v1.0 и v1.1 в Chrome 72 (выпущено 30 января 2919 г.). В версиях Chrome 84 (выпущенных 14 июля 2020 г.) и более поздних версиях отображается промежуточное предупреждение для этих протоколов, и поддержка должна была быть прекращена. полностью удален в мае 2021 года. Широкая поддержка браузерами более ранних версий SSL /TLS версий, таких как SSL v3, давно нет. В то время как TLS 1.2 в настоящее время является наиболее широко используемой версией SSL /TLS протокол, TLS 1.3 (последняя версия) уже поддерживается в текущих версиях большинства основных веб-браузеров.
• Используйте краткий список безопасных наборов шифров: Выбирайте только наборы шифров, которые предлагают как минимум 128-битное шифрование или более сильный, когда это возможно. Национальный институт стандартов и технологий (NIST) также рекомендует, чтобы все TLS реализации отходят от наборов шифров, содержащих шифр DES (или его варианты), к тем, которые используют AES. Наконец, использование лишь небольшого подмножества потенциально приемлемых комплектов шифров минимизирует поверхность атаки для еще не обнаруженных уязвимостей. Приложение SSL.com's Руководство по TLS Соответствие стандартам предоставляет примеры конфигураций для наиболее популярных платформ веб-серверов, используя TLS 1.2.
  
  Примечание: Использование небезопасных устаревших шифров (таких как RC4) может привести к ошибкам безопасности браузера, таким как ERR_SSL_VERSION_OR_CIPHER_MISMATCH в Google Chrome.
• Используйте Forward Secrecy (FS): Также известный под названием совершенная прямая секретность (PFS)FS гарантирует, что скомпрометированный закрытый ключ также не скомпрометирует прошлые сеансовые ключи. Чтобы включить FS:
  • Настроить TLS 1.2 использовать алгоритм обмена ключами Диффи-Хеллмана по эллиптической кривой (EDCHE) (с DHE в качестве запасного варианта) и по возможности полностью избегайте обмена ключами RSA.
  • Используйте TLS 1.3. TLS 1.3 обеспечивает прямую секретность для всех TLS сеансы через Эфемерный Диффи-Хеллман (EDH или DHE) протокол обмена ключами.
• Включите TLS Возобновление сеанса: Аналогично использованию keepalive для поддержки постоянных TCP-соединений, TLS возобновление сеанса позволяет вашему веб-серверу отслеживать недавно согласованные SSL /TLS сеансов и возобновить их, минуя вычислительные издержки согласования ключа сеанса.
• Рассмотрим сшивание OCSP: Сшивание OCSP позволяет веб-серверам доставлять кэшированную информацию об отзыве напрямую клиенту, что означает, что браузеру не нужно будет связываться с сервером OCSP, чтобы проверить, не был ли отозван сертификат веб-сайта. Устраняя этот запрос, сшивание OCSP предлагает реальный прирост производительности. Для получения дополнительной информации прочтите нашу статью, Оптимизация загрузки страницы: сшивание OCSP.

Используйте лучшие практики для дизайна веб-приложений

При разработке веб-приложений с учетом требований безопасности так же важно, как и правильно настроить сервер. Это наиболее важные моменты, позволяющие убедиться, что ваши пользователи не подвергаются Человек в середине атаки, и что ваше приложение получает преимущества SEO, связанные с хорошими методами обеспечения безопасности:

• Устранить смешанный контент: Файлы JavaScript, изображения и файлы CSS должны Найти доступ через SSL /TLS. Как указано в статье SSL.com, HTTPS Everywhere, служа смешанный контент больше не является приемлемым способом повышения производительности сайта и может привести к предупреждению безопасности браузера и проблемам с SEO.
• Используйте безопасные файлы cookie: Настройка Secure Флаг в cookie-файлах обеспечит передачу по защищенным каналам (например, HTTPS). Вы также можете запретить клиентскому JavaScript доступ к файлам cookie через HttpOnly помечать и ограничивать межсайтовое использование файлов cookie с помощью SameSite флаг.
• Оцените сторонний код: Убедитесь, что вы понимаете потенциальные риски использования сторонних библиотек на вашем веб-сайте, такие как возможность непреднамеренного внедрения уязвимостей или вредоносного кода. Всегда проверяйте надежность сторонних поставщиков в меру своих возможностей и связывайтесь со всем сторонним кодом с помощью HTTPS. Наконец, убедитесь, что ваша выгода от любых сторонних элементов на вашем веб-сайте стоит риска.

Проверьте свою работу с помощью диагностических инструментов

После настройки SSL /TLS на вашем сервере и веб-сайте или при внесении каких-либо изменений в конфигурацию, важно убедиться, что все настроено правильно и ваша система находится в безопасности. Доступны многочисленные диагностические инструменты для проверки SSL /TLS. Например, SSL Shopper's Проверка SSL сообщит вам, правильно ли установлен ваш сертификат, когда он истечет, и отобразит сертификат сертификата цепь доверия.

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

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

Внедрение строгой транспортной безопасности HTTP (HSTS)

HTTP Strict Transport Security (HSTS) — это механизм политики безопасности, который помогает защитить веб-сайты от атак с понижением версии протокола и перехвата файлов cookie. Это позволяет веб-серверам объявлять, что веб-браузеры (или другие соответствующие пользовательские агенты) должны взаимодействовать с ним только с использованием безопасных соединений HTTPS и никогда через небезопасный протокол HTTP. Эта политика передается сервером пользовательскому агенту через поле заголовка ответа HTTP с именем «Strict-Transport-Security».

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

Вот пошаговое руководство:

1. Убедитесь, что ваш сайт поддерживает HTTPS: перед включением HSTS ваш сайт должен иметь действующую SSL сертификат и иметь возможность обслуживать контент через HTTPS. Если ваш сайт еще не настроен для HTTPS, вам необходимо получить SSL-сертификат и настройте свой сервер для его использования.

Заголовок всегда устанавливает Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Эта строка указывает браузеру всегда использовать HTTPS для вашего сайта в течение следующего года (31,536,000 XNUMX XNUMX секунд), включая все субдомены.}

2. Проверьте свою конфигурацию: После добавления заголовка HSTS вы должны протестировать свой сайт, чтобы убедиться, что он работает правильно. Вы можете сделать это, посетив свой сайт и используя инструменты разработчика вашего браузера для проверки заголовков ответа. Вы должны увидеть заголовок Strict-Transport-Security со значением, которое вы установили.
3. Попробуйте добавить свой сайт в список предварительной загрузки HSTS.: список предварительной загрузки HSTS — это список сайтов, которые жестко запрограммированы в браузерах как поддерживающие HSTS. Это обеспечивает дополнительный уровень защиты, поскольку гарантирует, что первое подключение к вашему сайту будет безопасным, даже до получения заголовка HSTS. Вы можете отправить свой сайт в список предварительной загрузки HSTS на сайте hstspreload.org.

Кейсы: Новостной веб-сайт хочет, чтобы его пользователи всегда безопасно подключались к нему, даже если они случайно набрали «http» вместо «https» в URL-адресе. Веб-сайт использует HSTS, добавляя заголовок Strict-Transport-Security в конфигурацию своего сервера, устанавливая длинный максимальный возраст и включая все субдомены. Это говорит пользовательским агентам всегда подключаться к нему с помощью HTTPS, защищая пользователей от атак, которые пытаются понизить соединение до HTTP и украсть их файлы cookie. Веб-сайт также отправляет себя в список предварительной загрузки HSTS для дополнительной защиты.

Реализовать привязку открытого ключа HTTP (HPKP)

Закрепление открытого ключа HTTP (HPKP) — это функция безопасности, позволяющая веб-серверу связывать определенный криптографический открытый ключ с самим собой, чтобы предотвратить атаки "человек посередине" (MITM) с поддельными сертификатами.

Вот краткий обзор того, как он использовался:

1. Создание информации о закреплении: Первым шагом в реализации HPKP было создание информации о закреплении. Это включало создание криптографического хэша открытого ключа сертификата или открытого ключа промежуточного или корневого сертификата.
2. Настройка веб-сервера: Следующим шагом была настройка веб-сервера для включения HTTP-пины с открытым ключом заголовок в ответах. Этот заголовок включал хэши открытых ключей («булавки»), время жизни (как долго браузер должен помнить информацию) и, возможно, URI отчета (куда браузер будет отправлять отчеты об ошибках проверки булавки).
3. Обработка ошибок проверки PIN-кода: если браузер, поддерживающий HPKP, получил цепочку сертификатов, которая не включала хотя бы один из закрепленных открытых ключей, он считал соединение ненадежным. Если был указан URI отчета, браузер также отправил бы отчет о сбое на этот URI.

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

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

Используйте TLS Резервный SCSV для предотвращения атак с понижением версии протокола

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

Вот как вы можете реализовать TLS Резервный SCSV:

1. Обновите SSL вашего сервера/TLS Библиотека: первый шаг — убедиться, что SSL/TLS библиотека поддерживает TLS Резервный SCSV. Эта функция была представлена ​​в OpenSSL 1.0.1j, 1.0.0o и 0.9.8zc. Если вы используете другой SSL/TLS библиотеку, проверьте ее документацию или свяжитесь с ее разработчиками.
2. Настройте свой сервер: Как только ваш сервер SSL/TLS библиотека поддерживает TLS Резервный SCSV, вам может потребоваться настроить сервер для его использования. Точные шаги будут зависеть от вашего серверного программного обеспечения. Например, в Apache вам может понадобиться добавить или изменить строку в файле конфигурации следующим образом:

Протокол SSL Все -SSLv2 -SSLv3

Эта строка указывает серверу использовать все версии протокола, кроме SSLv2 и SSLv3. Если и клиент, и сервер поддерживают TLS 1.2, но клиент пытается использовать TLS 1.1 (возможно, из-за вмешательства злоумышленника), сервер распознает это как попытку отката и отклонит соединение.

3. Протестируйте свой сервер: После настройки вашего сервера вы должны протестировать его, чтобы убедиться, что он правильно реализует TLS Резервный SCSV. В этом вам могут помочь различные онлайн-инструменты, такие как SSL Labs Server Test.

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

Избегайте проблем со смешанным содержимым

Смешанный контент — это угроза безопасности, возникающая, когда веб-страница, загружаемая через безопасное соединение HTTPS, включает ресурсы, такие как изображения, видео, таблицы стилей или сценарии, которые загружаются через небезопасное соединение HTTP. Браузеры могут блокировать этот смешанный контент или отображать предупреждение для пользователя, что может нанести ущерб восприятию пользователем безопасности сайта.

Вот как можно избежать проблем со смешанным содержимым:

1. Используйте HTTPS для всех ресурсов: Самый простой способ избежать смешанного контента — убедиться, что все ресурсы на вашем сайте загружаются через HTTPS. Сюда входят изображения, сценарии, таблицы стилей, iframe, запросы AJAX и любые другие ресурсы, которые использует ваш сайт.
2. Обновите код вашего сайта: если код вашего сайта содержит жестко заданные URL-адреса HTTP для ресурсов, вам необходимо обновить их, чтобы вместо этого использовать HTTPS. Если ресурс размещен на сервере, который не поддерживает HTTPS, вам может потребоваться разместить ресурс на собственном сервере или найти альтернативный ресурс, который можно загрузить через HTTPS.
3. Настройте свой сервер для отправки заголовка Content-Security-Policy: HTTP-заголовок Content-Security-Policy (CSP) позволяет вам контролировать, какие ресурсы разрешено загружать вашему сайту. Установив заголовок CSP, разрешающий только ресурсы HTTPS, вы можете гарантировать, что ваш сайт не будет случайно содержать смешанный контент.

Кейсы: онлайн-журнал гарантирует, что весь контент, включая изображения и сценарии, загружается через HTTPS. Это не позволяет злоумышленникам вмешиваться в эти ресурсы и потенциально внедрять вредоносный контент. Веб-разработчики журнала регулярно проверяют код сайта, чтобы убедиться, что все ресурсы загружаются через HTTPS, и настраивают свой сервер для отправки строгого заголовка Content-Security-Policy. Они также используют онлайн-инструменты для сканирования своего сайта на наличие проблем со смешанным содержимым и исправления найденных.

Используйте указание имени сервера (SNI) для размещения нескольких сайтов

Индикация имени сервера (SNI) является продолжением TLS протокол, который позволяет серверу предоставлять несколько сертификатов на один и тот же IP-адрес и номер порта. Это особенно полезно для провайдеров веб-хостинга, которым необходимо разместить несколько защищенных веб-сайтов, каждый со своим собственным сертификатом SSL, на одном сервере.

Вот как вы можете использовать SNI:

1. Убедитесь, что ваше серверное программное обеспечение поддерживает SNI: Первый шаг — убедиться, что программное обеспечение вашего сервера поддерживает SNI. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают SNI.
2. Настройте свой сервер: Следующим шагом будет настройка вашего сервера на использование SNI. Обычно это включает в себя добавление отдельного блока конфигурации для каждого сайта, который вы хотите разместить на сервере, и указание SSL сертификат использовать для каждого сайта. Точные шаги будут зависеть от вашего серверного программного обеспечения.
3. Проверьте свою конфигурацию: После настройки вашего сервера вы должны протестировать его, чтобы убедиться, что он правильно использует SNI. Вы можете сделать это, посетив каждый сайт, который вы размещаете на сервере, и проверив, используется ли правильный сертификат SSL.

Кейсы: Хостинг-провайдер использует SNI для обслуживания нескольких веб-сайтов с одного и того же IP-адреса. Это позволяет им эффективно использовать пространство IP-адресов и упростить настройку сети. Они настраивают свой сервер на использование разных SSL-сертификатов для каждого сайта и регулярно проверяют свою конфигурацию, чтобы убедиться, что для каждого сайта используется правильный сертификат. Это гарантирует, что каждый сайт имеет безопасное и надежное соединение, даже если все они обслуживаются с одного и того же IP-адреса.

Оптимизация производительности с возобновлением сеанса

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

 Вот как вы можете использовать возобновление сеанса:

1. Убедитесь, что ваше серверное программное обеспечение поддерживает возобновление сеанса: первый шаг — убедиться, что ваше серверное программное обеспечение поддерживает возобновление сеанса. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
2. Настройте свой сервер: Следующим шагом является настройка вашего сервера для использования возобновления сеанса. Обычно это включает в себя включение кэша сеанса и установку значения времени ожидания для кэша. Точные шаги будут зависеть от вашего серверного программного обеспечения.
3. Проверьте свою конфигурацию: После настройки вашего сервера вы должны протестировать его, чтобы убедиться, что он правильно использует возобновление сеанса. Вы можете сделать это, установив TLS подключение к вашему серверу, отсоединение, а затем повторное подключение. Если возобновление сеанса работает правильно, второе соединение должно устанавливаться быстрее, чем первое.

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

Обеспечение действительности сертификата с помощью сшивания OCSP

Сшивание протокола статуса онлайн-сертификата (OCSP) — это метод повышения производительности SSL/TLS при сохранении безопасности соединения. Это позволяет серверу получать текущий статус своих собственных сертификатов от Центра сертификации (ЦС), а затем доставлять этот статус клиентам во время TLS рукопожатие.

Вот как вы можете реализовать сшивание OCSP:

1. Убедитесь, что ваше серверное программное обеспечение поддерживает сшивание OCSP: первый шаг — убедиться, что программное обеспечение вашего сервера поддерживает сшивание OCSP. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
2. Настройте свой сервер: Следующим шагом будет настройка сервера для использования сшивания OCSP. Обычно это включает в себя включение этой функции в SSL/TLS конфигурация и указание расположения сервера для хранения ответов OCSP. Точные шаги будут зависеть от вашего серверного программного обеспечения.
3. Проверьте свою конфигурацию: После настройки сервера необходимо протестировать его, чтобы убедиться, что он правильно использует сшивание OCSP. Вы можете сделать это, установив TLS подключение к вашему серверу и проверка того, что сервер включает ответ OCSP в TLS рукопожатие.

Кейсы: Интернет-магазин использует сшивание OCSP для быстрой проверки статуса своего SSL-сертификата. Это гарантирует, что клиенты всегда имеют безопасное соединение и могут быть уверены в безопасности своих данных. ИТ-команда розничного продавца настраивает свой сервер для использования сшивания OCSP и регулярно тестирует эту функцию, чтобы убедиться, что она работает правильно. Это помогает поддерживать доверие своих клиентов и защищать их конфиденциальные данные.

Отключить TLS Сжатие для смягчения криминальной атаки

TLS сжатие — это функция, которая может повысить производительность SSL/TLS за счет уменьшения объема данных, которые необходимо отправить по сети. Однако это также может сделать соединение уязвимым для атаки CRIME (Compression Ratio Info-leak Made Easy), которая может позволить злоумышленнику сделать вывод о содержимом зашифрованного трафика.

Вот как вы можете отключить TLS сжатие: 

1. Убедитесь, что ваше серверное программное обеспечение поддерживает отключение TLS компрессия: первый шаг — убедиться, что программное обеспечение вашего сервера поддерживает отключение TLS сжатие. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
2. Настройте свой сервер: Следующим шагом является настройка вашего сервера для отключения TLS сжатие. Точные шаги будут зависеть от вашего серверного программного обеспечения. Например, в Apache вы можете добавить в файл конфигурации такую ​​строку:

SSLCompression выключен

Эта строка указывает серверу не использовать сжатие для SSL/TLS соединений.

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

Кейсы: Финансовое учреждение отключает TLS сжатия на своих серверах для защиты от атаки CRIME. Это помогает обеспечить конфиденциальность конфиденциальных финансовых данных, таких как номера счетов и сведения о транзакциях. ИТ-команда учреждения настраивает свои серверы для отключения TLS сжатие, и они регулярно тестируют серверы, чтобы убедиться, что они правильно реализуют эту меру безопасности. Это помогает защитить клиентов заведения и сохранить их доверие.

Осуществлять TLS Сессионные билеты правильно

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

Вот как можно правильно реализовать TLS билеты на сеанс:

1. Убедитесь, что ваше серверное программное обеспечение поддерживает TLS Билеты на сеанс: первый шаг — убедиться, что ваше серверное программное обеспечение поддерживает TLS билеты на сеанс. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
2. Настройте свой сервер: Следующим шагом будет настройка вашего сервера для использования TLS билеты на сеанс. Обычно это включает в себя включение этой функции в SSL/TLS конфигурация. Точные шаги будут зависеть от вашего серверного программного обеспечения.
3. Используйте уникальные ключи сеансовых билетов: чтобы предотвратить потенциальные проблемы с безопасностью, каждый сервер должен использовать уникальный ключ билета сеанса. Если вы используете балансировщик нагрузки, вы должны настроить его для распределения клиентов на основе их билета сеанса, а не разрешать клиентам использовать билет сеанса, выданный одним сервером, для установления сеанса с другим сервером.
4. Регулярно меняйте ключи сеансовых билетов: для дальнейшего повышения безопасности вам следует регулярно менять ключи сеансовых билетов. Часто это можно автоматизировать с помощью серверного программного обеспечения или отдельной системы управления ключами.

Кейсы: крупная технологическая компания с несколькими серверами гарантирует, что каждый сервер использует уникальный ключ билета сеанса. Это не позволяет злоумышленнику использовать билет сеанса с одного сервера для олицетворения пользователя на другом сервере. ИТ-команда компании настраивает свои серверы для использования TLS сеансовые билеты, и они установили систему для регулярной ротации ключей сеансовых билетов. Они также настраивают свой балансировщик нагрузки для распределения клиентов на основе их билета сеанса, что еще больше повышает безопасность их системы.

Включить безопасное повторное согласование

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

Вот как вы можете включить безопасное повторное согласование:

2. Убедитесь, что ваше серверное программное обеспечение поддерживает безопасное повторное согласование: первый шаг — убедиться, что ваше серверное программное обеспечение поддерживает безопасное повторное согласование. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
3. Настройте свой сервер: Следующим шагом является настройка вашего сервера для использования безопасного повторного согласования. Обычно это включает в себя включение этой функции в SSL/TLS конфигурация. Точные шаги будут зависеть от вашего серверного программного обеспечения.
4. Проверьте свою конфигурацию: После настройки вашего сервера вы должны протестировать его, чтобы убедиться, что он правильно использует безопасное повторное согласование. Вы можете сделать это, установив TLS подключение к вашему серверу, а затем попытка повторного согласования подключения.

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

Отключить инициированное клиентом повторное согласование для предотвращения DoS-атак

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

Вот как можно отключить повторное согласование, инициированное клиентом:

1. Убедитесь, что ваше серверное программное обеспечение поддерживает отключение повторного согласования, инициированного клиентом: первый шаг — убедиться, что ваше серверное программное обеспечение поддерживает отключение повторного согласования, инициируемого клиентом. Большинство современных веб-серверов, включая Apache, Nginx и IIS, поддерживают эту функцию.
2. Настройте свой сервер: Следующим шагом является настройка сервера на отключение повторного согласования, инициируемого клиентом. Обычно это включает в себя добавление директивы в SSL/TLS конфигурация. Точные шаги будут зависеть от вашего серверного программного обеспечения.
3. Проверьте свою конфигурацию: После настройки вашего сервера вы должны протестировать его, чтобы убедиться, что он правильно отключает повторное согласование, инициированное клиентом. Вы можете сделать это, установив TLS подключение к вашему серверу, а затем попытка повторного согласования подключения. Если сервер правильно отклоняет запрос на повторное согласование, значит, он правильно настроен.

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

Будьте в курсе новых уязвимостей

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

Но что насчет…?

Если вы хотите узнать больше о любой из тем, затронутых в этом руководстве, и узнать о новых проблемах и технологиях по мере их возникновения, вы можете начать с просмотра и поиска SSL.com База знаний, который мы обновляем еженедельно с новыми разработками в области SSL /TLS и PKI, Вы также можете в любое время связаться с нашей службой поддержки по электронной почте на Support@SSL.com, по телефону 1-877-SSL-Secure, или нажав ссылку чата в правом нижнем углу этой страницы.

Получите экспертную консультацию по SSL-сертификатам.
Заполните форму для консультации.