Apache 2 с ssl/tls: шаг за шагом, часть 1

Преимущества DHE перед RSA

Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.

Совершенная прямая секретность

Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.

Уязвимость обмена ключами RSA

Существуют уязвимости, которые могут использовать заполнение (padding), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.

Вот почему RSA был удалён в пользу DHE в TLS 1.3.

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного , нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Протокол TLS

Протокол TLS представляет собой криптографический протокол, который применяется для защищенной передачи данных между различными узлами в сети интернет. Данный протокол нашел применение в VoIP-приложениях, веб-браузерах, приложениях для мгновенного обмена сообщениями. TLS реализован на спецификации SSL 3.0. Разработкой и развитием протокола занимается компания IETF.

К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:

  • Применение ключа для проверки кода аутентификации сообщения.
  • Исключена вероятность понижения версии TLS или подмены на менее защищенный сетевой протокол.
  • Сообщение с подтверждением связи содержит хэш всех сообщений, которыми обменивались стороны.
  • Использование нумерации записей приложения с применением MAC.
  • Применение псевдослучайной функции, разбивающей входные сообщения на 2 части, каждая из которых обрабатывается разной хэш-функцией.

Как перенести сайт с HTTP на HTTPS правильно

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил и версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в нужный адрес в директиве Hosts.

Вот, скажем, пример файла для сайта

User-agent: Yandex
Disallow:
Host: https://sheensay.ru

User-agent: *
Disallow:

Sitemap: https://sheensay.ru/sitemap.xml

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола . У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы заменяются на абсолютные или относительные .
Приведу пример:

  • НЕПРАВИЛЬНО:
  • ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
  • ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

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

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

A brief about TLS

TLS means Transport Layer Security, which is a cryptographic protocol successor of SSL 3.0, which was released in 1999.

TLS 1.0 TLS 1.0 which was upgrade of SSL v.3.0 released in January 1999 but it allows connection downgrade to SSL v.3.0.
TLS 1.1 After that, TLS v1.1 was released in April 2006, which was an update of TLS 1.0 version. It added protection against CBC (Cipher Block Chaining) attacks. In March 2020, Google, Apple, Mozilla and Microsoft has announced for deprecation of TLS 1.0 and 1.1 versions.
TLS 1.2 TLS v1.2 was released in 2008 that allows to specification of hash and algorithm used by the client and server. It allows authenticated encryption, which was added more support with extra data modes. TLS 1.2 was able to verify length of data based on cipher suite.
TLS 1.3 TLS v1.3 was released in August 2018 and had major features that differentiate it with its earlier version TLS v1.2 like removal of MD5 and SHA-224 support, require digital signature when earlier configuration used, compulsory use of Perfect forward secrecy in case of public-key based key exchange, handshake messages will now be encrypted after “Server Hello”.

Перестроение и изменение целевой платформы управляемых приложений с использованием последней версии .NET FrameworkRebuild/retarget managed applications using the latest .Net Framework version

В приложениях, использующих версии .NET Framework до версии 4.7, могут наблюдаться ограничения по эффективной поддержке ограничения TLS 1.0 независимо от базовой операционной системы по умолчанию.Applications using .NET framework versions prior to 4.7 may have limitations effectively capping support to TLS 1.0 regardless of the underlying OS defaults. Дополнительные сведения см. на приведенной ниже схеме и https://docs.microsoft.com/dotnet/framework/network-programming/tls.Refer to the below diagram and https://docs.microsoft.com/dotnet/framework/network-programming/tls for more information.

SystemDefaultTLSVersion имеет приоритет над нацеливанием версий TLS на уровне приложений.SystemDefaultTLSVersion takes precedence over app-level targeting of TLS versions. Рекомендуется всегда отдавать предпочтение стандартной версии TLS для ОС.The recommended best practice is to always defer to the OS default TLS version. Это также единственное решение для гибкого шифрования, позволяющее вашим приложениям пользоваться преимуществами будущей поддержки TLS 1.3.It is also the only crypto-agile solution that lets your apps take advantage of future TLS 1.3 support.

Если как целевые заданы более старые версии .NET Framework, например 4.5.2 или 3.5, то по умолчанию приложение будет использовать более старые нерекомендуемые протоколы, такие как SSL 3.0 или TLS 1.0.If you are targeting older versions of .NET Framework such as 4.5.2 or 3.5, then by default your application will use the older and not recommended protocols such as SSL 3.0 or TLS 1.0. Настоятельно рекомендуется обновить .NET Framework до более новой версии, например .NET Framework 4.6, или задать соответствующие разделы реестра для UseStrongCrypto.It is strongly recommended that you upgrade to newer versions of .NET Framework such as .NET Framework 4.6 or set the appropriate registry keys for ‘UseStrongCrypto’.

Версии протокола

  • TLS 1.2 — на данный момент эта версия протокола TLS встречается чаще прочих. К сожалению, имеет уязвимости: чтобы поддерживать старые компьютеры, TLS 1.2 разрешает использование устаревших техник шифрования, которые малонадежны. Протокол сильно уязвим к активному вмешательству в соединение, когда взломщик перехватывает данные посреди сессии, а отправляет их уже после прочтения или подмены. Большинство уязвимостей обнаружены за последние 2 года, что и послужило толчком для создания обновленной версии.
  • Статистика протокола TLS 1.3. В этой версии не поддерживаются устаревшие системы шифрования, благодаря чему протокол справляется с большинством уязвимостей. TLS 1.3 совместим с более старыми версиями: если одна из сторон не имеет возможности пользоваться новой системой шифрования, соединение откатится до версии 1.2. Если же во время атаки активного вмешательства взломщик попытается принудительным образом откатить версию протокола посреди сессии – такое действие будет замечено и сессия прервется.

Сравнение с аналогами

Одной из областей применения TLS-соединения является соединение узлов в виртуальной частной сети. Кроме TLS, также могут использоваться набор протоколов IPSec и SSH-соединение. Каждый из этих подходов к реализации виртуальной частной сети имеет свои преимущества и недостатки.

  1. TLS/SSL
    • Преимущества:
      • Невидим для протоколов более высокого уровня;
      • Популярность использования в Интернет-соединениях и приложениях электронной коммерции;
      • Отсутствие постоянного соединения между сервером и клиентом;
      • Позволяет создать туннель для приложений, использующих TCP, таких как электронная почта, инструменты программирования и т. д.
    • Недостатки:
      • Невозможность использования с протоколами UDP и ICMP;
      • Необходимость отслеживания состояния соединения;
      • Наличие дополнительных требований к программному обеспечению о поддержке TLS.
  2. IPsec
    • Преимущества:
      • Безопасность и надёжность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;
      • Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.
    • Недостатки:
      • Сложность реализации;
      • Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.);
      • Существует много различных реализаций, не всегда корректно взаимодействующих друг с другом.
  3. SSH
    • Преимущества:
      • Позволяет создать туннель для приложений, использующих TCP/IP, таких как электронная почта, инструменты программирования и т. д.;
      • Слой безопасности невидим для пользователя.
    • Недостатки:
      • Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры;
      • Большая нагрузка на внутрисетевой трафик;
      • Невозможность использования с протоколами UDP и ICMP.
      • Не имеет PKI (PKI, основанная на DNSSEC, малораспространена).

Атака на SSL/TLS – THC-SSL-DOS

Достаточно предсказуемая атака, в основе которой лежит идея, что крайне малыми силами со стороны клиента (по сути, просто запросив) можно заставить сервер выполнить математически относительно сложную задачу по перегенерации ключевой информации. В своей практике я сталкивался с таким в 2004 году, в случае с ipsec; один талантливый админ поставил настройки смены ключей так, что они менялись через каждые 100 килобайт (он хотел мегабайты, просто ошибся). В результате сеть работала, но медленно – ipsec в основном занимался IKE/ISAKMP задачами, а не трафиком.

Атака серьёзна – при полутысяче запросов в секунду (выполнимо с домашней машины при наличии обычного широкополосного доступа на 4-8 мегабита) полностью “ложится” процессор уровня Intel Xeon E5645. 100%го способа защиты от атаки сейчас нет. Поэтому надо максимально уменьшить её вероятность.

Для борьбы можно использовать следующие методы:

  1. Разгрузку SSL-задач при помощи аппаратных ускорителей
  2. Отключение пересогласования TLS
  3. Ограничение количества TLS-сессий – как вообще в сумме, так и с одного source ip
  4. Упрощение схемы генерации ключей

Защита от THC-SSL-DOS путём покупки SSL-ускорителя

Метод не оптимален, но всё же в ряде случаев изменит ситуацию. Суть в том, чтобы SSL/TLS сессии терминировались не на целевом сервере, а на выделенном устройстве, которое ощутимо быстрее выполняет SSL/TLS – задачи. Проблема в том, что все такие ускорители обычно ускоряют саму работу SSL/TLS – то есть симметричное шифрование трафика и проверку его целостности, а операции вида “генерация и смена ключей”, в силу их относительно малого процента в доле нагрузки при нормальной сессии делаются на таких appliance программно. Специализированного appliance, которое умеет очень быстро именно генерить новые сеансовы ключи для TLS, а не шифровать трафик, видимо, не существует в природе. Увы.

Защита от THC-SSL-DOS путём отключения пересогласования TLS

Это то, что Вы реально можете сделать. Учтите, это может повлиять на совместимость с клиентским ПО, которое в обязательном порядке хочет время от времени менять ключи сессии. Я проверял и не нашёл такого ПО среди обычно используемого в сетях на базе продуктов Microsoft (тестировались Exchange 2010 SP1, Sharepoint 2010 SP1, трафик DC/GC поверх SSL, TMG 2010 SP1). Мной не было найдено аномалий поведения, разрывов TLS-сессий по причине rekeying и прочего. Поэтому Вы можете промотать эту статью чуть выше (до предыдущего пункта) и выставить в единицу параметр .

Примечание: В принципе, можно использовать любое значение не равное нулю, поэтому единица предлагается для примера

Обновление служб Windows Server Update Services (WSUS)Update Windows Server Update Services (WSUS)

Для поддержки TLS 1.2 в более ранних версиях WSUS установите следующее обновление на сервере WSUS:To support TLS 1.2 in earlier versions of WSUS, install the following update on the WSUS server:

  • На сервере WSUS с Windows Server 2012 установите обновление 4022721 или более позднее.For WSUS server that’s running Windows Server 2012, install update 4022721 or a later rollup update.
  • На сервере WSUS с Windows Server 2012 R2 установите обновление 4022720 или более позднее.For WSUS server that’s running Windows Server 2012 R2, install update 4022720 or a later rollup update.

Начиная с Windows Server 2016 протокол TLS 1.2 поддерживается по умолчанию для служб WSUS.Starting in Windows Server 2016, TLS 1.2 is supported by default for WSUS. Обновления TLS 1.2 необходимы только на серверах WSUS Windows Server 2012 и Windows Server 2012 R2.TLS 1.2 updates are only needed on Windows Server 2012 and Windows Server 2012 R2 WSUS servers.

Возобновление сеанса TLSTLS session resumption

Представленный в Windows Server 2012 R2, поставщик общих служб SChannel реализовал серверную часть возобновления сеанса TLS.Introduced in Windows Server 2012 R2 , the Schannel SSP implemented the server-side portion of TLS session resumption. Реализация RFC 5077 на стороне клиента была добавлена в Windows 8.The client-side implementation of RFC 5077 was added in Windows 8.

Устройства, подключающие TLS к серверам, часто требуют переподключения.Devices that connect TLS to servers frequently need to reconnect. Возобновление сеанса TLS снижает затраты на установку TLS-подключений, так как возобновление включает в себя сокращенное подтверждение TLS.TLS session resumption reduces the cost of establishing TLS connections because resumption involves an abbreviated TLS handshake. Это упрощает несколько попыток возобновления работы, позволяя группе TLS-серверов возобновить сеансы TLS друг друга.This facilitates more resumption attempts by allowing a group of TLS servers to resume each other’s TLS sessions. Это изменение обеспечивает следующие возможности для любого клиента TLS, поддерживающего RFC 5077, включая Windows Phone и устройства Windows RT:This modification provides the following savings for any TLS client that supports RFC 5077, including Windows Phone and Windows RT devices:

  • Уменьшение использования ресурсов на сервереReduced resource usage on the server

  • Сниженная пропускная способность, повышающая эффективность клиентских подключенийReduced bandwidth, which improves the efficiency of client connections

  • Сокращение времени, затраченного на подтверждение TLS из-за возобновления соединенияReduced time spent for the TLS handshake due to resumptions of the connection

Сведения о возобновлении сеанса TLS без отслеживания состояния см. в документе IETF RFC 5077.For information about stateless TLS session resumption, see the IETF document RFC 5077.

Why do you need an SSL/TLS certificate?

Cyber security has become a serious threat that is spreading across all sections of the internet. From schools to enterprises and individuals, it puts user data of all types and sizes at risk. The risk is especially higher when there is exchange of information through client and server systems.

There is a need for secure system that encrypt data flow from either side. An SSL/TLS certificate helps with that. It acts as an endpoint encryption system that encrypt data preventing unauthorized access by hackers.

In the present day, SSL has also gained importance as a serious ranking signal due to Google’s announcement. Websites with SSL certificates gain better search ranking traction, have better user experience and do not pose any security concerns — even during eCommerce transactions.

Поддержка браузера TLS 1.3

Chrome выпускает черновую версию TLS 1.3 начиная с Chrome 65. В Chrome 70 (выпущенной в октябре 2018 года) окончательная версия TLS 1.3 была включена для исходящих соединений.

Черновая версия TLS 1.3 была включена в Firefox 52 и выше (включая Quantum). Они сохраняли небезопасный откат к TLS 1.2, пока не узнали больше о терпимости сервера и рукопожатии 1.3. Firefox 63 (выпущен в октябре 2018 года) поставляется с финальной версией TLS 1.3.

Microsoft Edge начал поддерживать TLS 1.3 с версией 76, и он включен по умолчанию в Safari 12.1 на macOS 10.14.4.

При этом некоторые службы тестирования SSL в Интернете пока не поддерживают TLS 1.3, а также другие браузеры, такие как IE или Opera mobile.

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

Однако по состоянию на 11 сентября 2018 года TLS 1.3 превзошла TLS 1.0 как вторую по популярности версию на Cloudflare.

Поддержка TLS 1.3 серверами

Если вам интересно, поддерживает ли ваш сервер или хост TLS 1.3, вы можете использовать инструмент тестирования сервера SSL. Просто просканируйте свой домен и прокрутите вниз до раздела «Функции протокола». Он скажет либо да, либо нет.

Резюме

Как и в случае HTTP/2, TLS 1.3 — это еще одно интересное обновление протокола, которое мы можем ожидать в течение многих лет. Не только зашифрованные (HTTPS) соединения станут быстрее, но и более безопасными. Вот для продвижения в Интернете!

Прокачиваем Nginx: TLS 1.3 + brotliПрокачиваем Nginx: TLS 1.3 + brotli

Закручиваем гайки: настройки криптоалгоритмов на хосте

Цель – отключить слабые алгоритмы шифрования. Чтобы они просто не участвовали в процессе согласования. Потому что на данный момент, допустим, наличие в списке поддерживаемых алгоритмов RC2 40bit – это очень плохо, и это необходимо убирать незамедлительно.

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

Как через групповую политику изменить список поддерживаемых SSL/TLS криптоалгоритмов

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

  1. Скопируйте в Блокнот все cipher suites, которые там есть.
  2. Удалите те, которые включают в себя согласование нестойких алгоритмов и методов (например, RC2, RC4, DES, MD5 и прочее. всякие ужасы вида TLS_RSA_WITH_NULL_MD5 Вам же не нужны, правда?).
  3. Превратите список в одну большую строку, которая состоит из cipher suites, разделённых запятыми, и не содержит больше ничего. Пробелов тоже.
  4. Вставьте эту строку в окно данной настройки групповой политики.

Учтите, что не всё, что поддерживается системой, присутствует в этом списке. И наоборот – данный список не прикажет системе начать поддерживать неизвестные ей криптоалгоритмы. Например, если у Вас есть системы на Windows XP / Windows Server 2003, убедитесь, что на них установлено обновление KB 948963, которое добавляет поддержку AES-128 и AES-256, необходимых для TLS.

А вот как можно изменить этот список через реестр.

Как через реестр изменить список поддерживаемых SSL/TLS криптоалгоритмов

Откройте редактор реестра. Ваша задача – ключи вида:

где идентификатор алгоритма – это, например, RC4, а размерность ключа – например, 128. Понятное дело, что данных комбинаций фиксированное число, поэтому для отключения всех из них в явном виде надо забежать в MSDN и найти эти комбинации. Например, для старых симметричных алгоритмов семейства RCx это будут:

  • RC4 128/128
  • RC2 128/128
  • RC4 64/128
  • RC4 56/128
  • RC2 56/128
  • RC4 40/128
  • RC2 40/128

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

Интересным моментом является отключение возможности установить “пустой” SSL – без криптоалгоритма. Ну, типа как в PPP можно вообще без фазы авторизации, так и тут – есть такая тонкость. Чтобы эту тонкость тоже убрать, надо зайти в ключ:

и опять же создать там со значением 0x0.

Отключаем использование хэш-функции MD5 в SSL/TLS

И даже это можно. Через групповую политику нет (только вручную удалив из полного списка все suites с упоминанием MD5), а через реестр – пожалуйста.

Учтите только, что данная настройка – лидер по количеству приключений после её применения. Классика – умирающий SharePoint 2010; он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.

Заходим:

и отключаем аналогично – в 0x0. Заодно и MD4 можно, он в принципе может встретиться в IPSec, но если не используется в реальности – имеет смысл его отключить аналогичным способом.

Примечание: Если захотите что-нибудь из этого явно включить обратно, не стирая ключ, есть нюанс: Enabled надо будет ставить не в единицу, а в 0xFFFFFFFF.

Управление порядком TLS ECCManaging TLS ECC order

Начиная с Windows 10 и Windows Server 2016, можно использовать параметры групповой политики порядка кривых ECC, чтобы настроить порядок кривой ECC по умолчанию для TLS.Beginning with Windows 10 and Windows Server 2016, ECC Curve Order group policy settings can be used configure the default TLS ECC Curve Order.
Используя универсальный код коррекции ошибок и этот параметр, организации могут добавить собственные доверенные именованные кривые (которые утверждены для использования с TLS) в операционную систему, а затем добавить эти именованные кривые к приоритету кривой групповая политика параметр, чтобы обеспечить их использование в будущих подтверждениях TLS.Using Generic ECC and this setting, organizations can add their own trusted named curves (that are approved for use with TLS) to the operating system and then add those named curves to the curve priority Group Policy setting to ensure they are used in future TLS handshakes.
Новые списки приоритетов кривых становятся активными при следующей перезагрузке после получения параметров политики.New curve priority lists become active on the next reboot after receiving the policy settings.

Какие типы сертификатов бывают и как выбрать нужный?

Domain Validation (DV)

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

Organization Validation (OV)

Такой сертификат подтверждает организацию, владеющую сайтом. Выпускается такой сертификат в течение недели, +/- 3 дня

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

Кому подойдут такие сертификаты — сказать сложно. Дело в том, что для конечного пользователя (посетителя сайта) разницы между OV и DV нет. Неплохо иметь такой тип сертификата в случае, если с сайта осуществляются платежи, а бюджета на EV нет. Но в подобной ситуации обычно используются интегрируемые решения (например, https://www.robokassa.ru), которые переводят посетителя на сайт сервиса (там обычно EV). Сертификаты OV, например, используются Яндексом и Google.

Extended Validation (EV)

Красиво, дорого, мощно! EV-сертификаты отличаются внешним видом для посетителя. В адресной строке такого сертификата будут отображаться данные о компании.

Если вы делаете что-то глобальное, вам нужен такой сертификат: например, если вы банк, если вы платежная система, если у вас собственный сервис приема платежей (данные карты вводятся на вашем сайте) и так далее. Такие сертификаты дороги. Даже у Сбербанка этот сертификат стоит только для https://online.sberbank.ru/, а для https://www.sberbank.ru/ используется простой OV.

Как происходит подтверждение сайта с помощью сертификатов

При соединении браузер проверяет, соответствуют ли данные в сертификате тому узлу, куда отправляются данные.

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

И замочек и информацию о компании для сертификата, где она указана:

Если же что-то пошло не так, то вы увидите такое предупреждение:

​​

При проверке:

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

Как проверить сертификаты SSL/TLS

Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.  

SeoLik

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

Проверяем наличие HTTPS соединения:

  1. Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ». 
  2. В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков. 

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

SSL Shopper

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

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

Wormly Web Server Tester

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

  1. Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
  2. Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires». 

Данный сервис позволяет просматривать шифры сертификатов, что может быть полезно для веб-разработчиков. 

Immuni Web

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

При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report». 

SSL Checker

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

На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте

Спасибо за внимание!

Про установку SSL-сертификатов вы можете почитать тут и тут.

TLS 1.3

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

Как видеть все сертификаты, которые отправляет HTTPS сервер

В предыдущем выводе вы могли обратить внимание, что он содержит сертификат сайта. На самом деле, сервер обычно отправляет цепочку сертификатов — сертификат сайта и все сертификаты промежуточных Центров Сертификации

Чтобы увидеть все сертификаты, которые отправил сервер, используйте опцию -showcerts:

openssl s_client -showcerts -connect yandex.ru:443

Для yandex.ru будет выведено 3 сертификата: 1 сертификат сайта и 2 промежуточных.

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

openssl s_client -showcerts -connect yandex.ru:443 </dev/null

Чтобы сохранить сертификат сайта в файл используйте следующую команду (дважды замените w-e-b.site на интересующий вас домен):

echo | openssl s_client -connect w-e-b.site:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > w-e-b.site.crt

Если вы хотите сохранить всю присылаемую цепочку сертификатов, то сделайте так (дважды замените w-e-b.site на интересующий вас домен):

echo | openssl s_client -showcerts -connect w-e-b.site:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > w-e-b.site.ca-bundle

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий