Tsl протокол: КриптоПро | КриптоПро TLS c ГОСТ

КриптоПро | КриптоПро TLS c ГОСТ

Протокол TLS: Краткая справка

Протокол TLS (Transport Layer Security) является одним из наиболее популярных протоколов, предназначенных для установления защищенного канала связи в сети Интернет. Он основан на спецификации протокола SSL (Secure Sockets Layer) версии 3.0, но за время своего существования претерпел довольно много изменений. Самой актуальной версией протокола на текущий момент является недавно вышедшая версия TLS 1.3, однако версия TLS 1.2 все еще остается наиболее распространенной.

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

Что такое TLS с ГОСТ?

В процессе работы над задачей разработки протокола TLS с поддержкой российских криптонаборов при активном участии специалистов КриптоПро было создано два ключевых документа, регламентирующих порядок работы протоколов TLS 1.2 и TLS 1.3 с ГОСТ Р 34.12-2015 (с использованием алгоритмов Магма и Кузнечик) – рекомендации по стандартизации Р 1323565.1.020-2018 для TLS 1.2 и рекомендации по стандартизации Р 1323565.1.030-2020 для TLS 1.3. Документы определяют криптонаборы с российскими алгоритмами хэширования, шифрования и электронной подписи с учетом наиболее современных и безопасных практик использования криптоалгоритмов. Для регламентации работы протокола с использованием криптонаборов на базе ГОСТ 28147-89 ранее были разработаны методические рекомендации МР 26.2.001-2013. Отметим, что сами российские алгоритмы стандартизируются в международных организациях ISO и IETF, проходя экспертизу ведущих мировых специалистов.

Подробнее о TLS c ГОСТ и поддерживаемых КриптоПро CSP криптонаборах 

Процесс стандартизации TLS с российскими криптонаборами также активно идет и в рамках международных организаций IETF и IANA. Так, организация IANA, управляющая идентификаторами и параметрами протоколов сети Интернет, в том числе благодаря усилиям специалистов нашей компании, впервые зарегистрировала в своем реестре российские криптонаборы и другие сопутствующие параметры для протокола TLS 1.2, а затем и TLS 1.3. Это крайне важное событие, которое имеет непосредственное отношение к стабильности работы протокола TLS с ГОСТ, ведь без наличия международно признаваемых идентификаторов все предыдущие годы существовала опасность блокировки TLS с ГОСТ из-за захвата номеров сторонними криптонаборами, а внесение поддержки российских криптонаборов в свободное ПО было затруднено.

КриптоПро CSP и TLS с ГОСТ

Ниже приведен список поддерживаемых различными версиями нашего криптопровайдера КриптоПро CSP криптонаборов и соответствующих регламентирующих документов. Отдельно отметим, что с версии 5.0 R3 планируется реализация поддержки криптонаборов в соответствии с рекомендациями Р 1323565.1.030-2020 для обеспечения поддержки протокола TLS версии 1.3 с использованием отечественной криптографии.

Криптонаборы с номерами (0xC1, 0x00) – (0xC1, 0x06) являются наборами, зарегистрированными в реестре организации IANA.

Внедрить TLS c ГОСТ? Легко!

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

Также на данной странице представлена информацию об услугах нашего удостоверяющего центра CryptoPro TLS-CA по выдаче сертификатов TLS →

Клиент-серверные решения

TLS-сервер с ГОСТ

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

1. Если вам необходимо настроить работу для конкретного серверного ПО (IIS, Apache, nginx), вы можете на компьютере с указанным серверным ПО установить КриптоПро CSP и, следуя соответствующим инструкциям по настройке, получить TLS-сервер, дополнительно поддерживающий алгоритмы ГОСТ.
2. Вы также можете воспользоваться решением КриптоПро NGate, представляющим собой самостоятельный TLS-шлюз (отдельная аппаратная или виртуальная платформа). Решение имеет большое количество преимуществ, одним из которых является удобство обеспечения классов защиты KC2-KC3: в отличие от предыдущего подхода, не требуется выполнение отдельных настроек, приобретение и конфигурирование электронных замков и прочих дополнительных мер защиты, все необходимое уже включено в аппаратные компоненты решения.

Ниже представлена сравнительная таблица характеристик каждого предлагаемого решения. В колонке “Cертификация” приведена информация о статусе сертификации решения: как самостоятельное СКЗИ или как решение, исследование которого было проведено в рамках сертификации КриптоПро CSP. Во втором случае указана соответствующая версия криптопровайдера.

TLS-клиент с ГОСТ

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

Решения для стационарных устройств 

Одним из популярных клиентских сценариев является взаимодействие клиента с сайтом, требующим защиту соединения с помощью отечественных алгоритмов (например, сайты банков). В этом случае необходимо, чтобы клиент со своей стороны, так же как и сервер, поддерживал работу по TLS с ГОСТ. Наиболее удобным решением является использование на стороне клиента криптопровайдера КриптоПро CSP совместно с одним из поддерживаемых браузеров.

Кратко о решении:

• На стороне клиента устанавливается КриптоПро CSP и один из поддерживаемых браузеров
• Решение не требует никакой дополнительной разработки
• Такое использование бесплатно для клиента (если с его стороны нет аутентификации по ключу и сертификату).

Ниже представлена сравнительная таблица характеристик поддерживаемых браузеров. Прочерк в колонке «Cертификация» означает необходимость проведения тематических исследований.

Решения для мобильных устройств

КриптоПро предоставляет возможность встраивания поддержки отечественных криптоалгоритмов в ваше мобильное приложение при помощи КриптоПро CSP для операционных систем iOS и Android.

Кратко о решении:

• CSP встраивается в мобильное приложение, пользователю не требуется устанавливать дополнительное ПО
• Приложение может использовать как российские, так и иностранные криптонаборы

Ниже представлен список поддерживаемых операционных систем и соответствующих классов защиты:

В случае использования КриптоПро CSP версии 5.0 R2 встраивание не требует проведения тематических исследований. Для CSP 5.0 и более ранних версий требуются тематические исследования.

Другие решения

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

Приложение stunnel, входящее в дистрибутив КриптоПро CSP, позволяет устанавливать защищенный с помощью отечественных криптонаборов канал между любыми двумя незащищенными приложениями без дополнительной разработки.

Ниже представлен список наиболее популярных поддерживаемых операционных систем и соответствующих классов защиты:

Как настроить доверие к сертификату?

Не секрет, что почти все механизмы аутентификации сторон в протоколе TLS построены на основе инфраструктуры открытых ключей (PKI), одной из основных компонент которой является сертификат открытого ключа сервера или клиента. С помощью сертификата происходит доверенное связывание идентифицирующей сторону информации (например, имени домена сервера) с открытым ключом, для этого используется указанная в сертификате информация о том, кому принадлежит открытый ключ. Данный ключ и соответствующий ему закрытый ключ используются для аутентификации стороны при выполнении протокола TLS, при этом сертификат пересылается по каналу в процессе взаимодействия.

Подробнее о том, что такое сертификат в TLS

Для того, чтобы механизм аутентификации функционировал корректно, необходимо, чтобы аутентифицирующая сторона могла убедиться, что информация, содержащаяся в переданном сертификате, является корректной и не была сформирована злоумышленником. Фактически, нам необходимо решить проблему доверия к открытым ключам. Это делается за счет наличия третьей стороны, которой доверяют все стороны информационного обмена – Удостоверяющего Центра (УЦ), выдающего сертификаты.

Строго говоря, когда мы говорим о передаче сертификата, мы имеем в виду передачу целой цепочки сертификатов («цепочку доверия»), где каждый сертификат подписывается закрытым ключом, соответствующим тому сертификату, который находятся выше в иерархии.

Если мы хотим проверить полученный сертификат, нам необходимо проверить подписи всех сертификатов в цепочке, опираясь на ключ проверки подписи из следующего по рангу сертификата. Следуя такому принципу, рано или поздно мы встретим сертификат, на котором цепочка заканчивается (т.е. сертификат, для которого нет сертификата с открытым ключом, который можно было бы использовать для проверки подписи). Такие сертификаты называются корневыми (root certificate). Корневые сертификаты устанавливаются доверенным образом, и в них указана информация, ассоциированная с доверенным УЦ.

В протоколе TLS предусмотрена возможность аутентификации и сервера, и клиента (двухсторонняя аутентификация), однако обязательной является только аутентификация сервера. Наиболее распространенным сценарием использования протокола является взаимодействие браузера с сайтом, в рамках которого обычно необходима только односторонняя аутентификация. Поэтому далее мы поговорим о том, как правильно и безопасно настроить доверие к сертификату сервера в рамках работы TLS c ГОСТ.

При работе по протоколу TLS с ГОСТ клиент может доверять сертификату, если его корневым сертификатом является либо сертификат головного удостоверяющего центра Минцифры России (сертификат ГУЦ), либо сертификат любого доверенного удостоверяющего центра (сертификат TLS-CA). Сертификаты, имеющие в качестве корневого сертификат ГУЦ, выдаются только аккредитованными удостоверяющими центрами по 63—ФЗ «Об электронной подписи». Отметим, что сертификат, использующийся для аутентификации сервера по протоколу TLS, не обязан быть полученным в аккредитованном удостоверяющем центре, достаточно, чтобы сертификат был выдан доверенным в рамках системы удостоверяющим центром.

Сертификат, корневым сертификатом которого будет TLS-CA, можно получить в нашем удостоверяющем центре CryptoPro TLS-CA. Отдельно отметим, что сертификат можно получить полностью удаленно, не посещая офис компании, воспользовавшись распределенной схемой обслуживания. Подробно о процедуре получения сертификата можно узнать на странице нашего удостоверяющего центра.

Настроить в браузере доверие к сертификату сервера можно одним из следующих способов:

• вручную:
  1. браузер клиента предупреждает пользователя о том, что сертификат не входит в список доверенных, клиент может «согласиться» доверять этому сертификату и продолжить устанавливать TLS соединение. Однако, очевидно, что возлагать ответственность за принятие такого решения на пользователя является не самым безопасным решением.
  2. администратор безопасности системы заносит сертификат сервера в доверенные в ручном режиме, что является достаточно безопасным, но не самым удобным решением.
• автоматически без участия человека:

При установке КриптоПро CSP версии 4.0 R3 и выше для работы браузера по ГОСТ сертификат ГУЦ и сертификат удостоверяющего центра CryptoPro TLS-CA добавятся в список доверенных автоматически. Таким образом, доверие распространится на любой сертификат, выданный аккредитованным УЦ или CryptoPro TLS-CA, причем после прохождения полноценной проверки, не требующей принятия решений от человека.

Тестирование двустороннего ГОСТ TLS

КриптоПро TLS входит в состав КриптоПро CSP на всех ОС и не требует отдельной установки.

Для использования протокола TLS предварительно получите сертификат по шаблону «Сертификат пользователя УЦ». Это можно сделать на тестовом Удостоверяющем центре КриптоПро.

Тестовая страница для установления защищенного соединения с сервером с двусторонней аутентификацией. Для работы тестовой страницы необходимо разрешить порт 4444 для исходящих соединений.

Дополнительные стенды для тестирования TLS.

Документация

Онлайн-версия руководства программиста доступна на нашем сайте.

Обзор включения TLS 1.2 — Configuration Manager

• 
  05/04/2021
• Чтение занимает 4 мин

В этой статье

Область применения: Configuration Manager (Current Branch)

Протокол TLS, например, SSL, является протоколом шифрования, предназначенным для обеспечения безопасности данных при передаче по сети. В этих статьях описывается, как обеспечить безопасный обмен данными по протоколу TLS 1.2 в Configuration Manager. Кроме того, в них приводятся требования к обновлению для часто используемых компонентов и рекомендации по устранению распространенных проблем.

Включение TLS 1.2

Configuration Manager обеспечивает безопасность связи с помощью множества различных компонентов. Протокол, который используется для конкретного подключения, зависит от возможностей всех соответствующих компонентов на стороне клиента и сервера. Если один из компонентов устарел или настроен неправильно, при обмене данными может использоваться старая, менее безопасная версия протокола. Чтобы корректно включить поддержку TLS 1.2 для всех безопасных подключений в Configuration Manager, вам нужно сделать это для всех необходимых компонентов. Необходимые компоненты зависят от вашей среды и используемых функций Configuration Manager.

Важно!

Начните с клиентов, особенно если используются предыдущие версии Windows. Прежде чем включить TLS 1.2 и отключить старые протоколы на серверах Configuration Manager, убедитесь, что все клиенты поддерживают этот протокол. В противном случае клиенты не смогут обмениваться данными с серверами и могут быть потеряны.

Задачи для клиентов Configuration Manager, серверов сайта и удаленных систем сайта

Чтобы включить TLS 1.2 для компонентов, от которых зависит Configuration Manager для защищенного обмена данными, необходимо выполнить несколько задач на стороне клиентов и серверов сайта.

Включение TLS 1.2 для клиентов Configuration Manager

Включите TLS 1.2 для серверов сайта Configuration Manager и удаленных систем сайта

Компоненты и зависимости сценариев

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

Часто задаваемые вопросы

Зачем использовать TLS 1.2 с Configuration Manager?

TLS 1.2 более безопасен, чем предыдущие криптографические протоколы, такие как SSL 2.0, SSL 3.0, TLS 1.0 и TLS 1.1. По сути, TLS 1.2 обеспечивает безопасность передачи данных по сети.

Где Configuration Manager использует протоколы шифрования, например TLS 1.2?

Существует пять основных задач, для которых Configuration Manager использует протоколы шифрования, такие как TLS 1.2:

• Взаимодействие клиента с ролями сервера сайта на основе IIS, если роль настроена для использования протокола HTTPS. Примерами таких ролей являются точки распространения, точки обновления программного обеспечения и точки управления.
• Обмен данными между точкой управления, службой SMS Executive и поставщиком SMS с помощью SQL. Configuration Manager всегда шифрует обмен данными с SQL Server.
• Обмен данными между сервером сайта и службами WSUS, если служба WSUS настроена для использования протокола HTTPS.
• Консоль Configuration Manager для служб SQL Server Reporting Services (SSRS), если службы SSRS настроены для использования протокола HTTPS.
• Любые подключения к интернет-службам. Например, шлюз управления облачными службами (CMG), синхронизация точки подключения службы и синхронизация метаданных обновления из Центра обновления Майкрософт.

Как определить, какой протокол шифрования использовать?

Протокол HTTPS всегда будет требовать наивысшую версию протокола, поддерживаемую как клиентом, так и сервером, в зашифрованном обмене данных. При установлении соединения клиент отправляет на сервер сообщение с наивысшим доступным протоколом. Если сервер поддерживает ту же версию, он отправляет сообщение, используя эту версию. Эта согласованная версия и используется для соединения. Если сервер не поддерживает версию, представленную клиентом, то в сообщении сервера будет указана самая высокая версия, которую он может использовать. Дополнительные сведения о протоколе подтверждения TLS см. в разделе Установка защищенного сеанса с помощью TLS.

Что определяет версию протокола, которую может использовать клиент и сервер?

Как правило, следующие элементы могут определить используемую версию протокола:

• Приложение может определять, какие версии протоколов следует согласовать.
  • Рекомендуется избегать использования строго установленных версий протоколов на уровне приложения и соблюдать конфигурацию, определенную на уровне протокола компонента и операционной системы.
  • Configuration Manager следует этим рекомендациям.
• Для приложений, написанных с использованием .NET Framework, версии протокола по умолчанию зависят от версии платформы, на которой они были скомпилированы.
  • Версии .NET до 4.6.3 не включали TLS 1.1 и 1.2 в списке протоколов для согласования по умолчанию.
• Приложения, использующие WinHTTP для соединений по протоколу HTTPS, например клиент Configuration Manager, зависят от версии операционной системы, уровня обновления и конфигурации для поддержки версии протокола.

Дополнительные ресурсы

Дальнейшие шаги

Безопасность TLS — Служба поддержки Apple

iOS, iPadOS и macOS поддерживают протокол Transport Layer Security (TLS 1.0, TLS 1.1, TLS 1.2 и TLS 1.3) и Datagram Transport Layer Security (DTLS). Протокол TLS поддерживает AES-128 и AES-256, предпочитая наборы шифров с прямой секретностью. Интернет-приложения, например Safari, Календарь и Почта, автоматически используют этот протокол для установления зашифрованного канала связи между устройством и сетевыми службами. Высокоуровневые API (такие как CFNetwork) упрощают внедрение TLS в приложениях сторонних разработчиков, а низкоуровневые API (такие как Network.framework) предоставляют детальный контроль. CFNetwork не разрешает использовать SSL 3, а приложениям, использующим WebKit (например, Safari), запрещается устанавливать подключения с использованием SSL 3.

В iOS 11 или новее и macOS 10.13 или новее сертификаты SHA-1 нельзя использовать для TLS-соединений, если им не доверяет пользователь. Также не разрешены сертификаты с ключами RSA короче 2048 бит. Набор симметричных шифров RC4 в iOS 10 и macOS 10.12 считается устаревшим. По умолчанию клиенты и серверы TLS, реализованные с использованием API SecureTransport, не имеют наборов шифров RC4 (их поддержка отключена) и не могут установить соединение, если единственным доступным набором шифров является RC4. Для повышения безопасности необходимо обновить службы и приложения, требующие использования RC4, чтобы в них использовались безопасные наборы шифров. В iOS 12.1 сертификаты, выпущенные после 15 октября 2018 г. от имеющего доверие в системе корневого сертификата, для установления TLS-соединений должны быть внесены в доверенный журнал прозрачности сертификатов. В iOS 12.2 стандарт TLS 1.3 по умолчанию включен для Network.framework и API NSURLSession. Клиенты TLS, использующие API SecureTransport, не могут использовать TLS 1.3.

App Transport Security

Протокол App Transport Security предоставляет используемые по умолчанию требования к подключению, чтобы приложения работали с защищенными подключениями при использовании API NSURLConnection, CFURL и NSURLSession. По умолчанию протокол App Transport Security ограничивает возможность выбора шифра только теми наборами, которые обеспечивают прямую секретность, в частности следующие:

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

Серверы должны поддерживать TLS 1.2 и прямую секретность, а сертификаты должны быть действительны и подписаны с использованием шифрования SHA256 (или более надежного) с ключом уровня не ниже, чем 2048-битный ключ RSA или 256-битный ключ на основе эллиптических кривых.

Сетевые подключения, не отвечающие этим требованиям, будут прерваны, если только в приложении не предусмотрен обход протокола App Transport Security. Использование недействительных сертификатов всегда приводит к постоянному отказу и отсутствию подключения. Протокол App Transport Security автоматически применяется для приложений, скомпилированных для iOS 9 или новее и macOS 10.11 или новее.

Проверка действительности сертификата

Оценка доверенного статуса сертификата TLS выполняется в соответствии с отраслевыми стандартами, установленными в RFC 5280, и новыми стандартами, такими как RFC 6962 (прозрачность сертификатов). В iOS 11 или новее и macOS 10.13 или новее устройства Apple периодически получают актуальный список отозванных и ограниченных сертификатов. Список обобщает списки отзыва сертификатов (CRL), публикуемые всеми встроенными корневыми центрами сертификации, которым доверяет Apple, а также их подчиненными центрами сертификации. Список также может включать в себя и другие ограничения по усмотрению Apple. Эта информация используется каждый раз, когда для установления безопасного соединения используется функция сетевого API. Если было отозвано слишком много сертификатов центра сертификации, чтобы перечислять их по отдельности, вместо сертификата для оценки доверия может использоваться ответ по протоколу состояния сетевого сертификата (OCSP). Если ответ не получен, тест на оценку доверия не будет пройден.

Дата публикации: 18 февраля 2021 г.

Включение SSL/TLS

Первая страница > Руководство по безопасности > Расширенная сетевая безопасность > Настройка параметров протокола SSL/TLS > Включение SSL/TLS

После установки сертификата устройства на аппарате включите параметр SSL/TLS.

Эта процедура используется для самозаверенного сертификата или для сертификата, выпущенного центром сертификации.

Войдите в систему в качестве сетевого администратора из приложения Web Image Monitor.

Наведите курсор на [Управление устройством] и нажмите [Конфигурация].

Нажмите [SSL/TLS] в разделе «Безопасность».

Для IPv4 и IPv6 выберите «Активн.», чтобы активировать SSL/TLS.

Выберите режим шифрования связи для параметра «Разрешить соединение SSL/TLS».

Для деактивации протокола выберите вариант [Неактивн.] напротив «TLS1.2», «TLS1.1», «TLS1.0» или «SSL3.0».

Необходимо активировать хотя бы один из этих протоколов.

В разделе «Настройка сложности шифрования» укажите сложность шифрования для применения к протоколу «AES», «3DES» и (или) «RC4». Необходимо выбрать по крайней мере один из предложенных вариантов.

Обратите внимание: доступность вариантов сложности шифрования может варьироваться в зависимости от данных, указанных вами для протоколов «TLS1.2», «TLS1.1», «TLS1.0» или «SSL3.0».

Нажмите [OK].

Появится сообщение “Обновление…”. Подождите 1 — 2 минуты, а затем нажмите [OK].

Если после нажатия кнопки [OK] предыдущий экран не отображается, подождите некоторое время, после чего нажмите кнопку обновления страницы в веб-браузере.

Выйдите из системы.

• Если для параметра «Разрешить соединение SSL/TLS» задать значение [Только шифротекст], соединение будет невозможно в случае выбора протокола, который не поддерживает веб-браузер, или настройки только параметра сложности шифрования. Если такое произошло, то включить соединение можно с помощью переключения настройки [Разрешить соединение SSL/TLS] на [Шиф./Незашифр.тек.], используя панель управления аппарата, а затем указать правильный протокол и сложность шифрования.

• Версию SSL/TLS и настройки сложности шифрования можно изменить даже в режиме [Сетевая безопасность].

• Возможность соединения с внешним сервером LDAP зависит от указанных состояний для «TLS1.2», «TLS1.1», «TLS1.0» и «SSL3.0».

• Если включены только TLS1.2 и TLS1.1, то аутентификацию сервера интерграции осуществить невозможно.

• Следующие типы связи и данных всегда шифруются протоколом SSL3.0: связь через @Remote, аутентификация сервера интеграции, файлы, отправленные через сервер доставки, и журналы, переданные в Remote Communication Gate S.

Безопасный протокол TLS

Так как значительная часть трафика изначально передавалась по сети в незашифрованном виде, то злоумышленники при некоторых усилиях в состоянии как читать трафик, так и модифицировать его. Особенно актуальной защита передаваемой информации стала после того, как банковские карты стали активно использоваться для online-торговли. В результате в 1996 году был разработан и внедрён протокол SSL (Secure Socket Layer). Сейчас он признан ненадёжным, но на его базе был разработан современный протокол TLS (Transport Level Security, безопасность уровня транспорта), применяемый для защиты трафика. Актуальной версией на начало 2018 года является 1.2, но ожидается, что версия 1.3 будет стандартизирована в течение 2018 года.

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

Для аутентификации сервера в процессе установления TLS-соединения сервер предъявляет сертификат, а клиент его проверяет. Ключи, которые будут использованы в процессе дальнейшего обмена данными, не могут быть корректно вычислены, если на сервере нет правильного секретного ключа, так что достаточно установить подлинность сертификата. Для этого строится цепочка доверия – проверяется, что сертификат, предъявленный сервером, подписан одним из доверенных удостоверяющих центров (УЦ, CA). Сертификаты доверенных УЦ поставляются вместе с операционной системой. Одна из фундаментальных проблем безопасности протокола TLS состоит в том, что любой УЦ технически может выпустить сертификат для любого домена. Для противодействия этому используется система Certificate Transparency и ряд других решений.

После публикаций в 2013 году данных о PRISM – глобальной программе АНБ США по сбору трафика – усилилась агитация за увеличение доли шифрованного трафика. В конце 2017 года, по данным Google и Firefox, в Web-трафике доля защищённого протокола HTTPS превысила 60%. Этому способствовало появление УЦ Let’s Encrypt, бесплатно выпускающего сертификаты для доменов. Вместе с тем, если до массового выпуска бесплатных TLS-сертификатов злонамеренные (прежде всего фишинговые) сайты можно было отличить по работе по HTTPS (как правило, отображается замком в адресной строке браузера), то сейчас этот критерий не действует, и ориентироваться пользователю стоит прежде всего на доменное имя.

В протоколе TLS и его реализациях периодически обнаруживаются уязвимости. Так, в 2014 году была найдена уязвимость в OpenSSL, получившая название Heartbleed. Воспользовавшись ей, злоумышленники могли получить доступ к секретным ключам веб-сайтов. Атака SWEET32 требует для анализа 750 Гб трафика и позволяет выяснить HTTP Cookies, используемые для авторизации на ряде сайтов. В среднем обнаруживается 1-2 сравнительно серьёзных уязвимости в год.

Некоторые разновидности уязвимостей позволяют выполнить так называемую атаку Man-in-the-Middle (атака «человек посередине», MITM). При осуществлении этой атаки посредник вклинивается в канал связи между клиентом и сервером. При успешном осуществлении атаки клиент и сервер не подозревают о существовании посредника, которому становится доступен для чтения весь трафик.

параметры безопасности, шифрование и история версий TLS протокола

В середине 90-х компания Netscape выпустила протокол, который повышал безопасность электронных платежей. Протокол получил название SSL и являлся предшественником протокола TLS. Версия 1.0 так и не пошла «в народ», будучи отбракованной на этапе тестирования. Версия 2.0 вышла в свет, но имела дыры в защите.

В 1996 году недостатки v. 2.0 были устранены, и мир увидел уже вполне рабочую версию программы — SSL 3.0. Реализация протокола происходила на уровне application, над TCP. Это позволило протоколам высокого уровня, вроде http, функционировать в штатном режиме.

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

• В 1999 выходит последующая версия, которая стандартизируется инженерным советом сети Интернет (IETF). Протокол получает новое название — TLS 1.0.
• Спустя 7 лет, весной 2006 года выходит следующая версия протокола — TLS 1.1. В ней значительно расширены функции и устранены актуальные уязвимости.
• В 2008 году выходит TLS 1.2, в которой качественно изменились методы шифрования. Введены новые режимы блочного шифрования, а устаревшие методы криптографического хэширования запрещены.
• Самая свежая версия протокола на сегодняшний день — TLS 1.3, выпущенная в 2018 году. Из нее убраны устаревшие хеши, шифры без аутентификации и открытые методы получения ключей к сессиям. Неактуальные опции, вроде вспомогательных сообщений и сжатия данных, также убраны. Введен режим обязательной цифровой подписи, разделены процессы согласования и аутентификации. Чтобы повысить параметры безопасности протокола TLS, версия 1.3 не имеет обратной совместимости с RC4 или SSL.

Параметры безопасности

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

• Конфиденциальность. Пользуясь симметричными алгоритмами, протокол TLS шифрует данные, которые передаются. Если данные окажутся перехваченными, прочесть их будет невозможно.
• Аутентификация. Гарантия, что обмен данными идет между теми узлами, для которых изначально создавался канал связи.
• Контроль целостности. Односторонним хэшированием проверяется входящая информация, исключая возможность подмены или искажения.

При использовании протокола веб-браузером поддерживаются параметры, способные обеспечить высшую степень безопасности. Статистика протокола TLS дает следующие данные:

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

TLS-рукопожатие

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

TLS False Start

Если клиент и сервер ранее устанавливали связь, функция позволит пропустить процедуру генерации ключей. Для установления безопасного канала связи будут использованы ключи, которые были вычислены ранее. Однако сессии имеют ограниченное время жизни, и если период сессии истек – придется повторно проводить процедуру TLS-рукопожатия.

TLS Chain of trust

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

Читайте также

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

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

Сертификат и конверсия

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

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

Уже купили виртуальный хостинг для сайта? Не забудьте о домене и сертификате TLS. Если только еще подумываете покупать сертификат – обращайте внимание на стандарты шифрования, которыми пользуется компания, предоставляющая защищенный канал связи.

Преимущества и недостатки протокола TLS

Еще в 1999 году, когда в SSL обнаружили уязвимости, было очевидно, что необходим обновленный протокол защиты данных. Это обстоятельство задало курс и тенденцию протоколу TLS. В 2014 POODLE успешно атаковал SSL 3.0, не оставив протоколу малейшего шанса. Что уж говорить о ранних версиях SSL.

Осенью 2014 Бодо Мёллер и его коллеги из Google Security Team обнаружили уязвимость в архитектуре протокола SSL 3.0. Атака POODLE подменяет пользовательские данные, и байт за байтом расшифровывает содержимое защищенного канала. Не существует способа обойти кодовую уязвимость, единственное логичное решение — блокировка использования протокола SSL 3.0 на всех рабочих системах.

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

Протокол TLS имеет ряд концептуальных отличий от SSL-протокола:

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

Начинающие веб-разработчики сталкиваются с непростым вопросом: какой протокол выбрать? Для специалиста со стажем выбор очевиден – настройка протокола TLS идентична SSL, при этом безопасность шифрования на несколько порядков выше. Более того, специалисты по безопасности Google настоятельно рекомендуют не использовать SSL-протокол, отдавая предпочтение TLS.

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

Знайте: когда вам предлагают «SSL-шифрование» — подразумевают TLS.

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

Microsoft передумала «убивать» небезопасные протоколы TLS. Apple от них радикально избавилась

01 Апреля 2020 09:4501 Апр 2020 09:45

|

Поделиться

Microsoft перенесла дату отключения поддержки старых протоколов шифрования TLS 1.0 и 1.1 на вторую половину 2020 г., чтобы веб-мастеры успели перевести сайты на более свежие версии TLS. Apple пошла другим путем и удалила поддержку этих протоколов в мартовских iOS 13.4 и macOS 10.15.4.

Отсрочка для TLS

Microsoft сообщила о переносе на вторую половину 2020 г. отключения протоколов шифрования TLS 1.0 и 1.1, одному из которых исполнился 21 год, а второму – 14 лет, во всех своих браузерах. Решение принято в связи с тем, что многие веб-сайты, в том числе и правительственные, до сих пор используют оба эти протокола, несмотря на то, что по состоянию на апрель 2020 г. они окончательно устарели.

Впервые свое желание отключить поддержку устаревших версий TLS в своих браузерах Microsoft изъявила в октябре 2018 г., сообщив, что сделает это в марте или апреле 2020 г.

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

В Edge сохранится поддержка устаревших протоколов шифрования

Еще одна причина временного продления «жизни» старым протоколам в браузерах Microsoft – это пандемия коронавируса. На ее фоне многие веб-сайты не обновляются и не могут получить поддержку более современных протоколов шифрования, и в итоге, если отключить TLS 1.0 и 1.1 в браузерах, установленных в Windows по умолчанию, у пользователей могут возникнуть трудности с доступом к этим ресурсам.

Дата отключения

Новая дата отключения устаревших протоколов в Edge на движке Chromium уже назначена – это июль 2020 г., когда состоится релиз Edge 84. Напомним, что Microsoft перевела Edge на этот движок весной 2019 г.

В распоряжении Microsoft, помимо Edge на Chrome, есть еще два браузера – классический Internet Explorer, от которого она активно призывает отказываться, и Edge Legacy – оригинальный Edge на собственном движке EdgeHTML. В них поддержка TLS 1.0 и 1.1 будет отключена с 8 сентября 2020 г.

Стоит отметить, что Microsoft не планирует полностью вычеркивать поддержку TLS 1.0 и 1.1 из своих браузеров – при необходимости ее можно будет активировать вручную в настройках, чтобы беспрепятственно подключаться к сайтам, использующим их.

Что сегодня понимают под TestOps

Интеграция

Добавим также, что Microsoft избавится от TLS 1.0 и 1.1 в веб-сервисе Office 365. Дата отключения известна – июнь 2020 г.

Действительно устаревшие протоколы

Протокол TLS 1.0 существует с 1999 г. и представляет собой эволюцию более старого протокола шифрования – SSL (Secure Sockets Layer) разработанного компанией Netscape и доросшего до версии 1.0 в 1993 г. SSL 2.0 дебютировал в 1995 г., а SSL 3.0, ставший в итоге основой TLS 1.0 – в 1996 г.

SSL 1.0 из-за большого числа недоработок так и не вошел в обиход, а SSL 2.0 использовался вплоть до 2011 г., пока не был признан устаревшим. Аналогичная участь в 2015 г. постигла и SSL 3.0. В 2006 г., спустя семь лет после релиза TLS 1.0, вышел протокол TLS 1.1. В настоящее время также существуют более современный TLS 1.2, появившийся в августе 2008 г., и самый актуальный TLS 1.3, увидевший свет в августе 2018 г. Согласно статистике SSL Labs, поддержка TLS 1.2 в настоящее время есть у 94% всех существующих сайтов. TLS 1.3 ввиду своего сравнительно недавнего появления пока не получил столь же широкого распространения.

Кто еще отказался от старых TLS

По данным ресурса Ars Technica, отказаться от TLS 1.0 и 1.1 в I квартале 2020 г. вместе с Microsoft планировали Google, Apple и Mozilla.

Apple отключила поддержку TLS 1.0 и 1.1 штатном интернет-ПО в iOS 13.4 и macOS 10.15.4 (обе вышли 24 марта 2020 г., а 11 марта 2020 г. Mozilla выпустила браузер Firefox 74, тоже с отключенной по умолчанию поддержкой этих протоколов. В конце марта 2020 г. она снова включила ее, мотивировав это тем, что правительственные сайты с информацией о коронавирусе, доступ к которым может потребоваться пользователям во время пандемии, могут не поддерживать TLS 1.2 и 1.3.

Что такое шифрование TLS и как оно работает?

Transport Layer Security (TLS) — один из наиболее важных и широко используемых протоколов безопасности. Он защищает значительную часть данных, передаваемых в Интернете. Наиболее часто он используется для защиты данных, передаваемых между веб-браузером и веб-сайтом через HTTPS , но его также можно использовать для защиты электронной почты и множества других протоколов.

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

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

Что делает TLS?

При отправке информации в Интернете мы сталкиваемся с тремя основными проблемами безопасности:

• Как мы можем узнать, действительно ли человек, с которым мы общаемся, является тем, кем они себя называют?
• Как мы можем узнать, что данные не подвергались подделке с момента их отправки?
• Как мы можем запретить другим людям видеть и получать доступ к данным?

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

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

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

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

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

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

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

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

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

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

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

TLS в сравнении с SSL

Читая о TLS, вы часто встретите упоминание SSL или даже TLS / SSL. Secure Sockets Layer (SSL) — это старая версия TLS, но многие в отрасли по-прежнему ссылаются на TLS под старым названием. В этой статье будет использоваться термин TLS, но важно отметить, что имена часто используются как синонимы. Вы можете узнать больше о SSL в нашем руководстве.

История TLS

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

SSL 1.0 так и не был выпущен, поскольку содержал серьезные уязвимости. Версия 2.0 вышла вместе с Netscape Navigator 1.1 в 1995 г. , однако она все еще содержала ряд серьезных недостатков. SSL 3.0 был сильно переработанной версией и вышел в 1996 году, при этом многие проблемы безопасности были решены.

В 1996 году IETF выпустила черновик SSL 3.0 в RFC 6101 . IETF сформировал рабочую группу по стандартизации SSL, опубликовав результаты в 1999 году как TLS 1.0. Он был задокументирован в RFC 2246, и стандартизация включала некоторые изменения в исходный протокол, а также изменение имени. Эти изменения явились результатом переговоров между Netscape, Microsoft и рабочей группой IETF.

В 2006 году IETF выпустила RFC 4346, который документирует TLS 1.1. Эта версия содержала новые положения о безопасности и ряд других обновлений.Версия 1.2 была выпущена всего двумя годами позже, в 2008 году. Она включала поддержку шифров с аутентификацией, ряд изменений в использовании хэш-функций и множество других улучшений.

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

По данным опроса Qualys, по состоянию на февраль 2021 года TLS 1.3 поддерживается почти 43 процентами ведущих веб-сайтов Alexa.Тот же источник показал, что более 99 процентов веб-сайтов поддерживают TLS 1.2. Основные браузеры, такие как Safari, Chrome и Edge, уже перестали поддерживать TLS 1.0 и 1.1 по умолчанию. Microsoft Edge и Mozilla Firefox сделают то же самое на каком-то этапе в ближайшем будущем.

TLS: Технические детали

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

Схема, показывающая стек TLS. Стек протоколов TLS от Jeffreytedjosukmono. Лицензия CC0.

Протокол записи содержит пять отдельных подпротоколов, каждый из которых отформатирован как записей :

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

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

Протокол рукопожатия TLS 1.2

Здесь устанавливается безопасное соединение.Это может показаться сложным, если вы новичок в некоторых концепциях, но каждая из них будет рассмотрена позже в статье, если вам нужно к ним обратиться.

Существует три основных типа рукопожатия TLS: базовое рукопожатие TLS , рукопожатие TLS с аутентификацией клиента и сокращенное рукопожатие .

Базовое рукопожатие TLS 1.2

Схема, показывающая процесс установления связи TLS. Полное рукопожатие TLS 1.2 от FleshGrinder.Лицензия CC0.

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

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

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

Если используется эфемерный обмен ключами Диффи-Хеллмана или анонимный обмен ключами Диффи-Хеллмана, то за ним следует сообщение Server Key Exchange . Другие методы обмена ключами пропускают эту часть. Когда сервер завершает согласование на своей стороне, он отправляет сообщение Server Hello Done .

Теперь снова очередь клиента. В зависимости от выбранного набора шифров он отправит сообщение Client Key Exchange . Он может содержать открытый ключ или главный секрет, который зашифрован открытым ключом сервера.

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

Затем клиент отправляет сообщение Change Cipher Spec .Это сообщает серверу, что следующие сообщения теперь будут аутентифицированы и зашифрованы (хотя иногда шифрование может не использоваться).

Затем клиент следует за этим сообщением Finished , которое зашифровано и также содержит код аутентификации сообщения (MAC) для аутентификации. Сервер расшифровывает это сообщение и проверяет MAC. Если какой-либо из этих процессов завершится неудачно, соединение должно быть отклонено.

Теперь очередь сервера отправить сообщение Change Cipher Spec , а также сообщение Finished с тем же содержанием, что и выше.Затем клиент также пытается расшифровать и проверить содержимое. Если все это выполнено успешно, рукопожатие завершено. На этом этапе протокол приложения установлен. После этого можно безопасно обмениваться данными так же, как и сообщением Finished , приведенным выше, с аутентификацией и дополнительным шифрованием.

Подтверждение TLS с аутентификацией клиента

Это рукопожатие очень похоже на базовое рукопожатие TLS, но клиент также аутентифицируется.Основное отличие состоит в том, что после того, как сервер отправляет свое сообщение Certificate , он также отправляет сообщение Certificate Request , запрашивая сертификат клиента. После завершения работы сервера клиент отправляет свой сертификат в сообщении Certificate .

Затем клиент отправляет сообщение Client Key Exchange , как и в базовом рукопожатии TLS. За ним следует сообщение Certificate Verify , которое включает в себя цифровую подпись клиента.Поскольку он рассчитывается на основе закрытого ключа клиента, сервер может проверить подпись, используя открытый ключ, который был отправлен как часть цифрового сертификата клиента. Остальная часть подтверждения TLS с аутентификацией клиента, выполняется в том же порядке, что и базовое рукопожатие TLS.

Сокращенное рукопожатие TLS

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

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

Процесс начинается с сообщения Client Hello . Оно очень похоже на предыдущее сообщение Client Hello, но также содержит идентификатор сеанса из более раннего соединения.Если серверу известен идентификатор сеанса, он включает его в свое сообщение Server Hello . Если он не распознает идентификатор сеанса, он вернет другой номер, и вместо этого потребуется полное рукопожатие TLS.

Если сервер действительно распознает идентификатор сеанса, то шаги Certificate и Key Exchange можно пропустить. Сообщения Change Cipher Spec и Finished отправляются таким же образом, как и базовое рукопожатие TLS, показанное выше.После того, как клиент расшифровал сообщение и проверил MAC, данные могут быть отправлены через безопасное соединение TLS.

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

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

Распаковка рукопожатия TLS 1.2

Три самых важных шага рукопожатия включают в себя:

• параметры выбраны,
• он проводит аутентификацию, а
• ключи установлены.

Давайте рассмотрим их более подробно, чтобы вы могли понять, что происходит на самом деле.

Параметры

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

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

Аутентификация: цифровые сертификаты

Аутентификация — ключевая часть защиты канала связи, потому что она позволяет обеим сторонам знать, что они на самом деле разговаривают с тем, кем они себя считают, а не с самозванцами.В TLS и многих других механизмах безопасности это достигается с помощью так называемых цифровых сертификатов.

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

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

Примечание об открытых ключах

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

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

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

Установление главного секрета

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

Подтверждение связи TLS может использовать несколько различных механизмов для безопасного обмена этим секретом. К ним относятся RSA, несколько различных типов обмена ключами Диффи-Хеллмана, PSK, Kerberos и другие. У каждого есть свои преимущества и недостатки, такие как обеспечение прямой секретности, но эти различия выходят за рамки этой статьи.

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

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

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

• MAC-ключ записи клиента — этот ключ используется сервером для проверки целостности данных, отправленных клиентом.
• MAC-ключ записи сервера — MAC-ключ записи сервера используется клиентом для проверки целостности данных, отправленных сервером.
• Ключ шифрования записи клиента — Сервер использует этот ключ для шифрования данных, отправленных клиентом.
• Ключ шифрования записи сервера — Клиент использует этот ключ для шифрования данных, отправленных сервером.
• Ключ IV записи клиента — Ключ IV записи клиента используется сервером в шифрах AEAD, но не при использовании других алгоритмов обмена ключами.
• Ключ IV записи сервера — Аналогично, этот ключ используется клиентом в шифрах AEAD, но не при использовании других алгоритмов обмена ключами.

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

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

Протокол приложения

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

Алгоритмы аутентификации

Целостность сообщений можно проверить с помощью множества различных алгоритмов. К ним относятся:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

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

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

Если они совпадают, это означает, что данные не были изменены с момента их подписания отправителем.Если они разные, вероятно, данные были подделаны или произошла какая-то другая ошибка.

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

Алгоритмы шифрования

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

TLS может использовать множество различных алгоритмов, таких как Camellia или ARIA, хотя наиболее популярным является AES.

Сжатие

Сжатие — это процесс кодирования данных, чтобы они занимали меньше места. TLS поддерживает сжатие, если обе стороны соединения решат его использовать.Несмотря на эту возможность, обычно рекомендуется избегать использования TLS для сжатия данных, особенно после того, как было обнаружено, что атака CRIME (см. Раздел «Проблемы безопасности TLS » ниже) может использовать сжатые данные для захвата сеанса.

Прокладка

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

Протокол оповещения

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

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

Протокол рукопожатия TLS 1.3

Почти каждый веб-сайт поддерживает TLS 1.2, но почти половина из них также поддерживает TLS 1.3 (по состоянию на февраль 2021 г.), и их число быстро растет. По мере того, как мы приближаемся к доминированию TLS 1.3, также важно понимать, как работает новая версия.

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

Меньше шагов

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

В TLS 1.3, сообщение Client Hello предполагает, что сервер согласится с его предпочтительными параметрами обмена ключами и отправляет ему соответствующие данные . Когда сервер поддерживает эти параметры, он использует их как часть своего сообщения Server Hello.

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

Хотя эти запросы Retry Hello добавляют дополнительные шаги, когда они необходимы, механизм TLS 1.3 в конечном итоге оказывается быстрее для большинства соединений .

Меньше наборов шифров

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

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Хотя указанные выше точки выглядят как техническая тарабарщина, на самом деле это просто коды для шифров.Например, в первом маркере используется режим шифрования AEAD AES-128 GCM с SHA-256 в качестве HKDF. AEAD — это тип шифра с симметричным ключом, а HKDF — это функции деривации ключей (KDF), основанные на кодах аутентификации сообщений на основе хэшей (HMAC).

TLS и модель OSI

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

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

Как видите, TLS просто не соответствует модели OSI.Это не означает, что TLS сломан или неправильный, во всяком случае, это просто показывает, что модель OSI ошибочна и не может учитывать все наши протоколы связи.

Связанное сообщение: Модель OSI

Использование TLS

TLS используется для защиты значительной части наших онлайн-коммуникаций. Обычно он реализуется по таким протоколам, как Протокол управления передачей (TCP) , но также может использоваться в Протоколе управления перегрузкой дейтаграмм (DCCP) и Протоколе дейтаграмм пользователя (UDP).

Он может защищать такие протоколы, как HTTP, SMTP, FTP, XMPP и NNTP , а также другие. Наиболее распространенным приложением является протокол HTTPS, защищающий соединение между веб-браузером и веб-сайтом. Вы можете узнать, когда HTTPS используется для защиты вашего онлайн-соединения, потому что маленький зеленый значок замка появится слева от URL-адреса в верхней части браузера.

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

Еще одно его использование — защищенная электронная почта через STARTTLS . Когда TLS реализован, он не позволяет злоумышленникам получить доступ к сообщениям при их перемещении между почтовыми серверами.

Проблемы безопасности TLS

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

Предыдущие версии, такие как SSL 2.0 и 3.0 (и TLS 1.0, который по сути совпадает с SSL 3.0), имеют многочисленные недостатки безопасности, но, поскольку это старые и устаревшие протоколы, мы не будем вдаваться в подробности.Вместо этого вы должны использовать TLS 1.2 и 1.3 для защиты своих соединений.

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

Атаки повторного согласования

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

Эта атака не позволяет злоумышленнику увидеть ответ, но все же может нанести ущерб. Расширение, которое предотвратит эти атаки, в настоящее время является предлагаемым стандартом.

ЗВЕРЬ

Атака браузерного эксплойта против SSL / TLS (BEAST) была впервые обнаружена исследователями в 2011 году. Она использует уязвимость цепочки шифровальных блоков в TLS, которая может использоваться для расшифровки сообщений.Эта атака затрагивает только TLS 1.0, который является старой и более слабой версией протокола. Хотя он не будет устаревшим до 2020 года, пользователи должны использовать вместо него версии 1.2 и 1.3.

Время атаки

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

ПРЕСТУПНОСТЬ И НАРУШЕНИЕ

Атака CRIME работает против ряда протоколов. Когда данные были сжаты, они могут извлекать контент из файлов cookie аутентификации. Эта информация может быть использована для перехвата сеанса. Хотя она затрагивает ряд протоколов, атака вызывает особое беспокойство, когда используется HTTP-сжатие, потому что нет эффективных стратегий предотвращения.

В 2013 году было обнаружено, что эксплойт «Разведка и эксфильтрация браузера через адаптивное сжатие гипертекста» (BREACH) аналогичным образом влияет на сжатие HTTP. Эта версия атаки может восстанавливать адреса электронной почты и другие ценные данные, зашифрованные с помощью TLS. Атаку BREACH можно смягчить, отключив сжатие HTTP или используя такие методы, как защита от подделки межсайтовых запросов (CSRF).

Атаки на понижение версии

Это атаки, которые заставляют серверы использовать более ранние и менее безопасные версии TLS.Злоумышленники могут использовать эти методы для согласования использования менее безопасных обменов ключами и шифров. Атака Logjam является хорошим примером, поскольку она может заставить уязвимые серверы использовать 512-битный алгоритм Диффи-Хеллмана, что является слабым местом. Затем злоумышленники могут взломать этот механизм обмена ключами и извлечь ключи, предоставив им полный доступ к сеансу.

Кровоточащее сердце

Heartbleed — это брешь в системе безопасности, которая была случайно внесена в библиотеку криптографии OpenSSL в 2012 году , но не была опубликована до 2014 года.Поскольку это такая широко используемая реализация TLS, она нанесла значительный глобальный ущерб.

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

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

УЗИ

Расшифровка RSA с устаревшей и ослабленной атакой eNcryption (DROWN) была объявлена ​​в 2016 году и использует преимущества серверной поддержки SSL 2.0. Он использует атаку с выбранным зашифрованным текстом против серверов, которые все еще поддерживают SSL 2.0, а также тех, которые используют один и тот же сертификат открытого ключа с другим сервером, поддерживающим SSL 2.0.

Когда было объявлено об атаке, она могла быть запущена с начальными затратами на установку около 18 000 долларов США и около 400 долларов США на каждую отдельную атаку.Когда атака DROWN успешна, она получает ключи сеанса.

Атаку можно предотвратить, если не предоставлять сертификаты сервера . Группа OpenSSL также выпустила исправления, которые удаляют поддержку старых протоколов и шифров, но они работают только в том случае, если сертификат сервера не используется совместно с другими серверами, поддерживающими SSL 2.0.

Нечестивый PAC

Эта атака была обнаружена в 2016 году. Она использует слабые места, обнаруженные в протоколе автообнаружения веб-прокси (WPAD).Когда пользователь пытается посетить веб-сайт через зашифрованное соединение TLS, уязвимость может сделать URL видимым. Поскольку URL-адреса иногда отправляются пользователям в качестве формы аутентификации, атака Unholy PAC позволяет злоумышленнику захватить учетную запись пользователя.

Безопасен ли TLS?

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

Технологии кибербезопасности для бизнеса от TheDigitalArtist по лицензии CC0

Что такое безопасность транспортного уровня (TLS)?

Несмотря на цель сохранения конфиденциальности веб-коммуникаций, недостатки в разработке и реализации Transport Layer Security привели к нарушениям.Но последняя версия — TLS 1.3 — представляет собой капитальный ремонт, который усиливает и оптимизирует криптопротокол.

Что такое TLS?

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

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

Предшественник TLS, Secure Socket Layer (SSL), был разработан Netscape в 1995 году. SSL версии 1.0 и 2.0 содержали множество недостатков безопасности, которые потребовали полной переработки протокола. В 1996 году Netscape выпустила версию SSL 3.0, которая была основой TLS1.0. В 1999 году Совет PCI предложил в конечном итоге отказаться от SSL как TLS 1.0 был значительным обновлением до SSL 3.0.

TLS против SSL

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

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

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

Недостатки и нарушения TLS

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

• BEAST (2011 г.): эксплойт браузера против SSL / TLS — это эксплойт браузера, который использовал слабое место в цепочке блокировки шифров (CBC) для извлечения незашифрованного открытого текста в зашифрованный сеанс.
• CRIME и BREACH (2012 и 2013 гг.): Создатели BEAST разработали уязвимость безопасности Compression Ratio Info-link Made Easy, которая позволяет хакеру извлекать содержимое веб-файлов cookie даже при использовании сжатия и TLS.Одним из гнусных вариантов использования этого является восстановление файлов cookie аутентификации, чтобы злоумышленники могли перехватить аутентифицированные веб-сеансы. Браузерная разведка и эксфильтрация с помощью адаптивного сжатия гипертекста, или BREACH, построена на CRIME и извлекает токены входа, адреса электронной почты и другую информацию.
• Heartbleed (2014): Heartbleed позволяет хакерам красть закрытые ключи с серверов, которые должны быть безопасными. Зараженные серверы оставались широко открытыми, чтобы любой человек в Интернете мог читать память в системах, защищенных уязвимой версией OpenSSL.Взлом позволил злоумышленникам украсть данные с серверов или подслушивать разговоры или даже подделать службы и других пользователей.

TLS 1.3 повышает безопасность, производительность и конфиденциальность

TLS 1.3 был первым серьезным переписыванием, которое инженерная рабочая группа Интернета (IETF) решила модернизировать протокол. Подумайте о предыдущих версиях как о ленточных средствах, добавляющих некорректный код. Это могло продлиться какое-то время, но в конце концов плохие парни выяснили, как это обойти. Работа над TLS1.3 началась в апреле 2014 года, и потребовалось четыре года и 28 проектов, прежде чем он был одобрен в марте 2018 года.

Помимо внесения значительного изменения, IETF намеревалась внести то, что она назвала «значительными улучшениями в области безопасности, производительности и конфиденциальности». Самым большим изменением является то, что TLS 1.3 значительно усложняет злоумышленникам расшифровку HTTPS-зашифрованного трафика и, следовательно, лучшую защиту конфиденциальности.

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

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

В начале цикла разработки возникло несколько проблем, наиболее заметные из которых обнаружились в школьной системе в Мэриленде, где около 20 000 Chromebook заблокировались при обновлении до TLS 1.3. Кроме того, организации, оказывающие финансовые услуги, были категорически против, потому что шифрование сделало их слепыми к тому, что происходило в их собственных сетях. IETF внесла несколько улучшений, позволяющих протоколу работать с инструментами мониторинга, если он реализован правильно.

Помимо улучшений безопасности, TLS 1.3 устранил ряд старых алгоритмов, которые не делали ничего, кроме создания уязвимостей. К ним относятся:

• RC4 Steam cipher
• DES
• 3DES
• RSA Транспортный ключ
• Хеширование SHA-1
• Шифры режима CBC
• MD5
• Группы Диффи-Хеллмана
• Шифры ЭКСПОРТА

Кроме того, в обновленный протокол добавлена ​​функция под названием «Возобновление 0-RTT», которая позволяет клиенту и серверу запоминать, общались ли они ранее.Если предыдущая связь существует, предыдущие ключи могут быть использованы, проверки безопасности пропущены, и клиент и сервер могут немедленно начать обмен данными. Считается, что некоторые из крупных технологических компаний настаивали на 0-RTT, потому что они извлекают выгоду из более быстрых соединений, но есть некоторые опасения со стороны профессионалов в области безопасности.

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

Присоединяйтесь к сообществам Network World на Facebook и LinkedIn, чтобы комментировать самые важные темы.

Copyright © 2018 IDG Communications, Inc.

Стандарт только для HTTPS — Технические рекомендации

На этой странице описаны некоторые важные технические концепции, относящиеся к мощности и качеству конфигурации HTTPS сервера.

SSL и TLS

HTTPS сегодня использует Transport Layer Security или TLS . TLS — это сетевой протокол, который устанавливает зашифрованное соединение с аутентифицированным одноранговым узлом по ненадежной сети.

Ранее менее безопасные версии этого протокола назывались Secure Sockets Layer или SSL) .

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

В настоящее время используются следующие основные версии SSL / TLS:

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

Злоумышленник может вмешаться в процесс согласования и попытаться «понизить» соединения до самой старой взаимно поддерживаемой версии.

Атаку перехода на более раннюю версию можно предотвратить с помощью TLS Fallback SCSV , расширения TLS, предложенного в 2014 году и включенного по умолчанию в новых версиях OpenSSL.

Для получения более подробной информации о рекомендациях NIST прочтите специальную публикацию NIST 800-52.

Прямая секретность

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

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

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

В TLS прямая секретность обеспечивается выбором наборов шифров, которые включают обмены ключами DHE и ECDHE.

Примечание. Текущие проекты TLS 1.3, следующей версии TLS, требуют новых подключений для использования прямой секретности путем удаления поддержки статического обмена ключами RSA и DH.

Алгоритмы подписи

Модель безопасности HTTPS / TLS использует «сертификаты» для гарантии подлинности. Эти сертификаты криптографически «подписаны» доверенным центром сертификации.

Доверенный корневой сертификат центра сертификации (который входит в состав вашей ОС или браузера) используется для подписания промежуточного сертификата, который используется для подписи сертификата вашего веб-сайта. В цепочке может быть более одного сертификата-посредника. Часть процесса подписи — вычисление «хэша» данных, включенных в сертификат.Это можно сделать с помощью стандартного алгоритма хеширования, такого как SHA-1 или SHA-2.

Было показано, что

SHA-1 имеет серьезные недостатки, поэтому поставщики браузеров и ОС, такие как Google, Microsoft и Mozilla, объявили о сроках отказа от SHA-1 в пользу алгоритмов семейства SHA-2.

NIST запретил SHA-1 для генерации цифровой подписи после 2013 года.

С января 2016 года коммерческим центрам сертификации запрещено большинством корневых программ выдавать сертификат SHA-1.Таким образом, получение публично доверенного сертификата SHA-1 больше невозможно. Кроме того, владельцы сайтов с существующим сертификатом SHA-1 должны знать, что многие браузеры и операционные системы отключат поддержку SHA-1 в начале 2017 года.

Строгие шифровальные наборы

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

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

Федеральные агентства не контролируют примитивы, поддерживаемые основными общедоступными клиентами (такими как веб-браузеры, cURL и другие распространенные HTTP-клиенты). Однако агентства могут контролировать шифры и алгоритмы, которые поддерживаются их серверами (которые также могут включать прокси, балансировщики нагрузки или сети доставки контента).

При настройке серверов:

Полная цепочка сертификатов

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

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

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

Всего:

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

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

SSL, TLS и STARTTLS шифрование электронной почты объяснение

SSL, TLS и STARTTLS относятся к стандартным протоколам, используемым для защиты передачи электронной почты.

SSL (Secure Sockets Layer) и его преемник, Transport Layer Security (TLS), обеспечивают способ шифрования канала связи между двумя компьютерами через Интернет. В большинстве случаев термины SSL и TLS могут использоваться как синонимы, если вы не имеете в виду конкретную версию протокола.

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

STARTTLS — это команда протокола электронной почты, которая сообщает почтовому серверу, что почтовый клиент, включая почтовый клиент, работающий в веб-браузере, хочет превратить существующее небезопасное соединение в безопасное. (Кстати, использование «TLS» в имени команды STARTTLS не означает, что она работает только с протоколом безопасности TLS. Она также работает с SSL.)

Как работает SSL?

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

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

Зачем вам нужны SSL или TLS?

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

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

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

Также неплохо сочетать шифрование электронной почты на основе TLS с аутентификацией электронной почты для обеспечения целостности сообщений электронной почты.

Как SparkPost использует SSL, TLS и STARTTLS?

Входящие вызовы API

SparkPost используют HTTPS (безопасная версия HTTP) и зашифрованы SSL / TLS. Если вы решите включить шифрование: STARTTLS, то TLS будет использоваться с входящим SMTP. SparkPost также использует гибкую TLS для исходящих сообщений, что означает, что он использует TLS для их шифрования, если получающий SMTP-сервер поддерживает TLS.

Что такое безопасность транспортного уровня (TLS)? Объяснение сильных и слабых сторон

Каждый сетевой «новициат» начинается с упражнения по безопасности.К настоящему времени вы, должно быть, наткнулись на чужеродные концепции, такие как «SSL», «TLS», «протокол рукопожатия», «AES» или «MD5-SHA-1». Назвать их недоумением было бы большим преуменьшением — если, конечно, вы не специализируетесь на компьютерных науках или криптографии. Видя, как многие системные администраторы или даже простые пользователи увязли в тонкостях протоколов безопасности, в сегодняшней статье мы рассмотрим один из золотых стандартов безопасного взаимодействия: безопасность транспортного уровня или TLS.

1.0. Что такое безопасность транспортного уровня?

Согласно техническому документу RFC 5246, опубликованному на веб-сайте IETF (Internet Engineering Task Force), TLS — это криптографический протокол, предназначенный для защиты связи между клиентом и сервером. Практически все, что мы знаем об Интернете, вращается вокруг концепции безопасной связи, независимо от того, идет ли речь о веб-серфинге, отправке мгновенного сообщения через выделенную платформу (например, WhatsApp), отправке электронной почты своему менеджеру или общению через приложение VoIP.

TLS получил свое название из-за довольно своеобразного отличия от одноуровневой модели, приписываемой моделям OSI (Operation System Interconnection) [1] и TCP / IP. Учитывая тот факт, что TSL — это протокол безопасности, а не транспортный протокол, он разработан для работы поверх какого-либо транспортного протокола; TCP — такой же хороший пример, как и любой другой. Однако на практике есть некоторые типы приложений, которые «переопределяют» функции безопасности TLS, используя его в качестве транспортной среды.

Протокол Transport Layer Security имеет длинную историю, но все согласны (чтобы не согласиться!), Что это было «необходимое зло» в том смысле, что его создатели хотели найти способ преодолеть недостатки SSL (Secure Sockets Layers), предшественник TLS.Чтобы полностью понять, почему переход на TSL был необходим, давайте подробнее рассмотрим хронологию.

1.1. Сдвиг SSL в TSL — Особенности

Вот события, которые привели к принятию TSL и прекращению поддержки SSL.

1986 — Запуск системы защиты данных проекта (SDNS). Участвуют несколько государственных и негосударственных агентств. Среди них — АНБ, Национальное бюро стандартов и Агентство оборонных коммуникаций .Целью Project SDNS было обновление существующего подхода к защите компьютерной связи по сети.

1987 — Основные моменты и инновации проекта SNDS представлены на 10 ^-й Национальной конференции по безопасности компьютерных наук. И TLS, и SSL продвигаются как стандарты безопасного сетевого взаимодействия.

1993 — Начало исследования варианта безопасности транспортного уровня. Создан API SNP (безопасное сетевое программирование).Ученые считают, что API-интерфейсы могут облегчить усилия по защите существующих сетевых приложений.

1994 — Тахер Эльгамал, главный научный сотрудник Netscape, предлагает версию 1.0 протокола Secure Socket Layer. Первая версия не будет обнародована из-за различных недостатков безопасности.

1995 — Выпущен SSL версии 2.0. Готовность умереть в упряжке, поскольку первые результаты показали, что SSL 2.0 так же несовершенен, как и его предшественник.

1996 — SSL версии 3.0 выпущен. Проходит полное дооснащение. В том же году SSL 3.0 провозгласил следующий золотой стандарт криптологии. В конечном итоге будет опубликован на веб-сайте IETF под названием RFC 6176.

1999 — Диркс и Аллен из Consensus Development публикуют свой совместный документ о TLS версии 1 (RFC 2246).

2006 — TLS версии 1.0 получает первое обновление. TLS 1.1, чтобы получить исторический документ (RFC 4346).

2008 — Капитальный ремонт ТЛС 1.1. Версия 1.2 будет опубликована в IETF в соответствии с RFC 5246.

2011 — SSL 2.0 устарел.

2015 — SSL 3.0 устарел.

2018 — Выпущен TSL 3.0.

2020 — Основные игроки рынка программного обеспечения, включая Mozilla, Microsoft, Apple и Google, объявили, что TLS 1.0 и TLS 1.1 будут прекращены до конца года.

1.2. Краткий обзор временной шкалы SSL в TSL

Поскольку TSL является протоколом безопасности и криптографии, его основной функцией остается защита целостности и конфиденциальности данных.Чтобы гарантировать выполнение обоих условий, любая пересылка TLS должна соответствовать нескольким экзистенциальным критериям. Прежде всего, это проблема конфиденциальности — данные, передаваемые на сервер и от сервера к клиенту, должны быть защищены.

Это достигается с помощью метода, называемого симметричным шифрованием [2]. Но даже этот метод требует криптографических ключей, которые генерируются в начале каждого соединения. Генерация симметричного ключа шифрования осуществляется с помощью так называемого общего секрета [3] . Эта форма согласования начинается в начале каждого сеанса защищенной связи. Весь процесс согласования между клиентом и сервером также носит название рукопожатия TSL. Я расскажу вам о подтверждении связи TSL в разделе, посвященном TLS в сетевой безопасности.

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

Наконец, еще предстоит установить надежность соединения. Чтобы проверить мощность сигнала, обе стороны обмениваются кодом аутентификации сообщения (MAC).

Протокол TLS можно разделить на два более мелких протокола: подтверждение связи TLS и запись TLS. Давайте подробнее рассмотрим их обоих.

1.2.1 Как работает рукопожатие TLS

Как я уже объяснил, рукопожатие TLS (как следует из названия) — это то, как клиент и сервер «разговаривают по-турецки».Во время этого шага, который происходит в мгновение ока, происходит несколько вещей: два объекта запускают его, обмениваясь сообщениями. Я вернусь к этому позже. Этот шаг необходим для подтверждения того, что обе стороны говорят, что они такие, какие они есть.

Затем следует этап проверки, за которым следует небольшой «разговор» о том, какой тип алгоритмов шифрования будет использовать этот тип защищенной связи. Чат завершается, когда обе стороны согласовывают ключи сеанса. С первого взгляда это будет рукопожатие TSL.Однако за кулисами происходит гораздо больше вещей. Давайте взглянем и посмотрим, что мы можем узнать.

a) «Привет, сервер!»

Клиент (то есть веб-браузер пользователя) инициирует рукопожатие TLS с помощью очень удобного приветствия, отправляемого на сервер. Тип информации, передаваемой во время «приветствия» клиента: версия TLS, поддерживаемая клиентом, список шифров, которые поддерживают клиенты, и так называемый «случайный клиент» [4].

б) «Здравствуйте, клиент!»

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

c) Аутентификация

На этом этапе, после получения сертификата SSL от сервера, клиент выполняет перекрестные ссылки с официальным списком, выданным центром сертификации, в попытке установить его подлинность.

г) Передача главного секрета

Для дальнейшего усиления конфиденциальности клиент отправляет «главный секрет».В криптографии главный секрет относится к уникальной и случайной строке байтов, передаваемой на сервер для дешифрования . Эта строка зашифрована открытым ключом, полученным из сертификата SSL, который был ранее передан сервером (см. Этап «привет, клиент!»).

e) Расшифровка закрытого ключа

После того, как клиент передаст главный секретный ключ, сервер начнет его расшифровывать.

f) Создание ключей для сеанса

На этом этапе добавляется еще один уровень конфиденциальности.Это достигается за счет создания ключей для конкретных сеансов. Имейте в виду, что эти ключи генерируются как клиентом, так и сервером. Этот процесс включает в себя «смесь» криптографических элементов: сервер + случайный клиент и, конечно же, , главный секрет . Что касается метода передачи, то ключи для сеанса отправляются и принимаются одновременно (клиент-сервер, сервер-клиент).

г) «Спасибо, сервер!»

Как только все вышеперечисленные условия выполнены, клиент направляет серверу сообщение «готово / спасибо».Само сообщение зашифровано сеансовым ключом.

з) «Спасибо, клиент!»

В зеркале мрачно, как говорится — сервер отправляет клиенту сообщение «готово / спасибо», которое тоже зашифровано сеансовым ключом.

i) Установлена ​​безопасная связь.

После завершения подтверждения TLS клиент и сервер могут продолжить обмен данными по защищенному каналу.

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

К сожалению, дальнейшие исследования показали, что c omms, зашифрованные с помощью алгоритма RSA, очень уязвимы для атак Man-in-the-Middle.

Именно по этой причине асимметричный метод шифрования гораздо более эффективен по сравнению с симметричным. В асимметрично-зашифрованной связи TLS RSA дополняется так называемым эфемерным обменом ключами Диффи-Хеллмана.

Вот как выглядит рукопожатие TSL в рамках модели D-H .

а) «Привет, сервер!»

Клиент «машет» серверу. На этом этапе клиент отправляет список поддерживаемых шифров, случайный клиент и, конечно же, версию протокола.

б) «Здравствуйте, клиент!»

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

c) Установление личности сервера

После получения цифровой подписи от сервера клиент начинает ее расшифровывать, чтобы подтвердить личность сервера. В свою очередь, клиент передает на сервер свои параметры D-H.

г) Вычисление главного секрета

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

e) Создание сеансовых ключей

После того, как клиент и сервер договорились о главном секрете, они генерируют и обмениваются сеансовыми ключами.

Примечание: следующие шаги идентичны описанным в модели RSA.

1.2.2. Что такое запись TLS?

Второй подпротокол

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

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

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

Чтобы увидеть, как работает безопасность транспортного уровня, посмотрите видео ниже.

TLS в сетевой безопасности. Сильные и слабые стороны.

Протокол Transport Layer Security имеет широкий спектр приложений: от программного обеспечения, требующего шифрования данных, до веб-браузеров, с упором на последнее. Как я уже отмечал ранее в статье, протокол TLS обычно «совмещен» с TCP (протоколом управления передачей).

Для дальнейшего облегчения реализации TLS и, следовательно, повышения конфиденциальности защищенной связи, протоколы TLS обычно взаимодействуют с UDP (протоколами дейтаграмм пользователя) и DCCP (протоколами контроля перегрузки дейтаграмм). Более того, протоколы TLS обычно используются для защиты данных в наиболее часто используемых протоколах «по воздуху», таких как FTP, HTTP, NNTP и XMPP.

Что касается реализации TLS, хотя TLS версии 1.3 на сегодняшний день считается самым безопасным протоколом шифрования, внедрение веб-сайтов сильно отстает.

Согласно оценке SSL Pulse, по состоянию на январь 2020 года только 22% опрошенных веб-сайтов (около 30 000) поддерживают TLS 1.3 .

С другой стороны, TLS 1.2 реализовано на 96,6% веб-сайтов (около 135 000). Одним из возможных объяснений может быть то, что версия 1.3 относительно нова по сравнению с версиями 1.2 и 1.1, и ее несколько сложнее интегрировать в существующую сетевую архитектуру. Однако, учитывая решение отказаться от всего, что ниже TLS версии 1.0.

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

На практике лучшим шифрованием с симметричным ключом, без сомнения, является AES-256 и RSA-4096 для шифрования с открытым ключом. Доступны и другие алгоритмы, но реализовать их довольно сложно.

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

Преимущества TLS :

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

MAC-аутентификация

• в TLS намного безопаснее по сравнению с SSL, поскольку последний использует HMAC (Key-Mashing Authentication Code) — криптографический метод, который предотвращает вмешательство потенциального злоумышленника в запись TLS во время передачи.
• Детальный контроль над тем, что происходит во время сеанса . Система предупреждений TLS намного более продвинутая и реагирующая по сравнению с системой SSL.Если что-то случится во время транспортировки, пользователь будет немедленно предупрежден.

Недостатки TLS :

• Более высокая задержка по сравнению с другими протоколами безопасного шифрования. Исследование StackPath показало, что соединения, зашифрованные с помощью TSL, имеют задержку 5 мс по сравнению с соединениями, которые не были зашифрованы. Кроме того, машины, на которых проводились «стресс-тесты», показали скачок ЦП на 2% при обработке сообщений с шифрованием TLS.
• Старые версии TSL все еще уязвимы для атак MiM.TLS версий с 1.0 по 1.2 по-прежнему подвержен атакам типа «человек посередине», а также другим формам кибер-агрессии: POODLE, DROWN и SLOTH.
• Несколько платформ поддерживают TLS 1.3. Есть несколько платформ, которые поддерживают последнюю версию TLS: Chrome (версия 67+), Firefox (версия 61+) и Apple Mac OS 10.3 (iOS 11). Microsoft все еще борется с процессом реализации.

Заключительные мысли о сетевой безопасности

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

№1. Найдите подходящий инструмент для автоматизации процесса развертывания сертификата

Исследование CISCO показало, что, хотя все компании стремятся внедрить лучший и более безопасный протокол, колоссальные 80% из них по-прежнему полагаются на ручной ввод.Автоматизация процесса развертывания сертификата может сэкономить много ресурсов, освобождая отдел для других задач. Было бы лучше начать внедрение TLS как можно скорее, поскольку DoH начал завоевывать еще больше позиций в области конфиденциальности.

№2. Обязательно учтите все векторы атаки

Быстро внедрив TLS версии 1.3, вы значительно снизите риск, связанный с атаками с перехватом. Однако в этом случае также требуется решение для фильтрации DNS, чтобы охватить все предполагаемые векторы атак.Heimdal ™ Threat Prevention, отмеченное наградами решение Heimdal Security для фильтрации трафика, активно сканирует всю сеть на предмет любых признаков, связанных с проникновением вредоносного ПО из вредоносной инфраструктуры.

Антивируса уже недостаточно для обеспечения безопасности систем организации.

Heimdal ™ Предотвращение угроз
— Конечная точка

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

• Сканирование всего входящего онлайн-трафика на основе машинного обучения;
• Останавливает утечку данных до того, как конфиденциальная информация может быть раскрыта извне;
• Расширенная фильтрация DNS, HTTP и HTTPS для всех ваших конечных точек;
• Защита от утечки данных, APT, программ-вымогателей и эксплойтов;

Заключение

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

[1] Обзор телекоммуникационной иерархии. OSI имеет два типа уровней: медиа (физический, канал передачи данных, сеть) и хост (транспортный, сеансовый, презентационный и прикладной).

[2] Практика использования одного и того же ключа шифрования как для открытого текста, так и для шифротекста.

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

[4] Случайная строка байтов использовала «привет клиенту» для установления личности клиента.

Networking 101: Безопасность транспортного уровня (TLS)
Сеть через браузер (O’Reilly)

Введение

Протокол SSL был первоначально разработан в Netscape для обеспечения
безопасность транзакций электронной торговли в Интернете, которая требует шифрования для
защищать личные данные клиентов, а также аутентификацию и целостность
гарантии для обеспечения безопасной транзакции.Для этого SSL
протокол был реализован на уровне приложений, непосредственно поверх TCP
(Рисунок 4-1), что позволяет
протоколы над ним (HTTP, электронная почта, обмен мгновенными сообщениями и многие другие) для
работать без изменений, обеспечивая безопасность связи, когда
общение по сети.

При правильном использовании SSL сторонний наблюдатель может только сделать вывод
конечные точки подключения, тип шифрования, а также частоту и
приблизительный объем отправленных данных, но не может читать или изменять какие-либо
фактические данные.Рисунок 4-1. Безопасность транспортного уровня (TLS)

Когда протокол SSL был стандартизирован IETF, он был переименован.
к безопасности транспортного уровня (TLS). Многие используют имена TLS и SSL
взаимозаменяемы, но технически они разные, поскольку каждый
описывает другую версию протокола.

SSL 2.0 был первой публично выпущенной версией протокола, но
он был быстро заменен на SSL 3.0 из-за ряда обнаруженных средств защиты
недостатки.Поскольку протокол SSL был проприетарным для Netscape, IETF
предприняли попытку стандартизировать протокол, в результате чего появился RFC 2246,
который был опубликован в январе 1999 года и стал известен как TLS 1.0. С
затем IETF продолжил итерацию протокола для решения
недостатки безопасности, а также расширение ее возможностей: TLS 1.1 (RFC 4346)
был опубликован в апреле 2006 г., TLS 1.2 (RFC 5246) в августе 2008 г. и работает
сейчас ведется определение TLS 1.3.

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

TLS был разработан для работы поверх надежного транспортного протокола.
типа TCP. Однако он также был адаптирован для работы с дейтаграммами.
протоколы, такие как UDP. Безопасность на транспортном уровне дейтаграмм (DTLS)
протокол, определенный в RFC 6347, основан на протоколе TLS и может
предоставить аналогичные гарантии безопасности при сохранении дейтаграммы
модель доставки.

§Шифрование, аутентификация и целостность

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

Шифрование

Механизм скрытия того, что отправляется с одного хоста на другой.

Аутентификация

Механизм проверки действительности предоставленной идентификации
материал.

Целостность

Механизм обнаружения фальсификации и подделки сообщений.

Чтобы установить криптографически безопасный канал данных,
одноранговые узлы должны договориться о том, какие наборы шифров будут использоваться, и
ключи, используемые для шифрования данных.Протокол TLS определяет четко определенный
последовательность рукопожатия для выполнения этого обмена, которую мы рассмотрим в
подробно в TLS Handshake.
Гениальная часть этого рукопожатия и причина, по которой TLS работает в
На практике это связано с использованием криптографии с открытым ключом (также известной как
криптография с асимметричным ключом), что позволяет одноранговым узлам согласовывать
общий секретный ключ без необходимости устанавливать какие-либо предварительные знания о каждом
другое, и сделать это по незашифрованному каналу.

В рамках рукопожатия TLS протокол также позволяет обоим одноранговым узлам
подтвердить свою личность. При использовании в браузере это
механизм аутентификации позволяет клиенту проверить, что сервер
кем он себя называет (например, ваш банк), а не просто притворяется
быть местом назначения, подделав его имя или IP-адрес. Этот
проверка основана на установленной цепочке доверия — см.
Цепочка доверия и
Центры сертификации.Кроме того, сервер также может опционально
проверить личность клиента — например, прокси-сервер компании может
аутентифицировать всех сотрудников, каждый из которых может иметь свой уникальный
сертификат, подписанный компанией.

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

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

§Прокси, посредники, TLS и новые протоколы на
Интернет

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

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

Другими словами, на практике отклонение от четко определенного
семантика HTTP / 1.x на порту 80 часто приводит к ненадежным развертываниям:
у некоторых клиентов нет проблем, у других же возникают непредсказуемые и непредсказуемые
трудно воспроизводимое поведение — e.g., один и тот же клиент может видеть разные
поведения при перемещении между разными сетями.

Из-за такого поведения появились новые протоколы и расширения HTTP, такие как
поскольку WebSocket, HTTP / 2 и другие должны полагаться на установку HTTPS
туннель для обхода промежуточных прокси и обеспечения надежного
модель развертывания: зашифрованный туннель скрывает данные от всех
посредники. Если вы когда-нибудь задумывались, почему большинство руководств по WebSocket
скажет вам использовать HTTPS для доставки данных мобильным клиентам, это
Почему.

§HTTPS Везде

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

HTTPS защищает целостность веб-сайта

Шифрование предотвращает несанкционированное вмешательство злоумышленников в обмен
данные — например, переписывание контента, внедрение нежелательных и вредоносных
контент и так далее.

HTTPS защищает конфиденциальность и безопасность пользователя

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

HTTPS обеспечивает широкие возможности в Интернете

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

Чтобы продолжить, как Internet Engineering Task Force (IETF)
Совет по архитектуре Интернета (IAB) выпустил руководство для
разработчиков и разработчиков протоколов, которые настоятельно рекомендуют внедрение
HTTPS:

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

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

§Давайте
Зашифровать

Распространенное возражение и препятствие на пути к широкому распространению
HTTPS был требованием для покупки сертификатов у одного из
доверенные органы — см. Цепь доверия и
Центры сертификации.Проект Let’s Encrypt запущен в 2015 году.
решает эту конкретную проблему:

«Let’s Encrypt — бесплатный, автоматизированный и открытый сертификат.
авторитет, предоставленный вам Исследовательской группой по интернет-безопасности
(ISRG). Цель Let’s Encrypt и протокола ACME —
позволяют настроить HTTPS-сервер и получить его автоматически
получить сертификат, доверенный браузеру, без участия человека
вмешательство.»

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

§TLS
Рукопожатие

Прежде, чем клиент и сервер смогут начать обмен данными приложения
через TLS необходимо согласовать зашифрованный туннель: клиент и
сервер должен согласовать версию протокола TLS, выберите
ciphersuite и при необходимости проверьте сертификаты.К сожалению, каждый из
для этих шагов требуются новые пакеты (рис. 4-2) между клиентом и
server, что увеличивает задержку запуска для всех TLS-подключений.

Рисунок 4-2. Протокол рукопожатия TLS

Рисунок 4-2 предполагает то же
(оптимистично) Задержка одностороннего «света в волокне» 28 миллисекунд между Новым
Йорк и Лондон, как использовалось в предыдущем установлении TCP-соединения
Примеры; см. Таблицу 1-1.

0 мс

TLS работает через надежный транспорт (TCP), что означает, что мы должны
сначала завершите трехстороннее рукопожатие TCP, которое занимает одно полное
поездка в оба конца.

56 мс

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

84 мс

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

112 мс

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

140 мс

Сервер обрабатывает параметры обмена ключами, отправленные
клиент, проверяет целостность сообщения, проверяя MAC, и возвращает
encrypted Завершено сообщение клиенту.

168 мс

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

Как видно из приведенного выше обмена, для новых подключений TLS требуется два
обходы для «полного рукопожатия» — это плохие новости. Однако в
практика, оптимизированные развертывания могут работать намного лучше и обеспечивать
согласованное рукопожатие 1-RTT TLS:

• False Start — это расширение протокола TLS, которое позволяет клиенту и
  сервер, чтобы начать передачу зашифрованных данных приложения, когда
  рукопожатие завершено только частично — i.э., однажды
  ChangeCipherSpec и Finished Сообщения
  отправлено, но не дожидаясь, пока другая сторона сделает то же самое. Этот
  оптимизация снижает накладные расходы на рукопожатие для новых подключений TLS к
  одна поездка туда и обратно; см. Включение ложного запуска TLS.

• Если клиент ранее связывался с сервером,
  может использоваться «сокращенное рукопожатие», которое требует одного обхода и
  также позволяет клиенту и серверу снизить накладные расходы ЦП на
  повторное использование ранее согласованных параметров для безопасного сеанса;
  см. сеанс TLS
  Возобновление.

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

Одна из целей разработки TLS
1.3 заключается в уменьшении накладных расходов на задержку при настройке безопасного
соединение: 1-RTT для новых и 0-RTT для возобновленных сеансов!

§RSA,
Диффи-Хеллман и прямая секретность

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

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

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

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

Лучше всего то, что обмен ключами Диффи-Хеллмана может использоваться для уменьшения
риск компрометации прошлых сеансов связи: мы можем создать
новый «эфемерный» симметричный ключ как часть каждого обмена ключами
и отбросьте предыдущие ключи. В результате, поскольку эфемерные ключи
никогда не сообщаются и активно пересматриваются для каждого нового
сеанс, в худшем случае злоумышленник может скомпрометировать
клиент или сервер и получить доступ к ключам сеанса текущего и
будущие сессии.Однако зная закрытый ключ или текущий
эфемерный ключ, не помогает злоумышленнику расшифровать любой из предыдущих
сеансы!

Комбинированный, использование обмена ключами Диффи-Хеллмана и эфемерный
ключи сеансов обеспечивают «совершенную прямую секретность» (PFS): компромисс
долгосрочных ключей (например, закрытого ключа сервера) не ставит под угрозу прошлые
ключи сеанса и не позволяет злоумышленнику расшифровать ранее
записанные сеансы. Очень желанная недвижимость, мягко говоря!

В результате, и это не должно вызывать удивления, RSA
рукопожатие сейчас активно отменяется: все популярные браузеры
предпочитают шифры, которые обеспечивают прямую секретность (т.е., положитесь на
Обмен ключами Диффи-Хеллмана), и в качестве дополнительного стимула может
включать определенные оптимизации протокола только тогда, когда прямая секретность
доступно — например, Рукопожатие 1-RTT через TLS False Start.

То есть обратитесь к документации по серверу, чтобы узнать, как включить
и разверните прямую секретность! Еще раз, хорошая безопасность и производительность
идут рука об руку.

§Производительность открытого и симметричного ключа
Криптография

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

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

• $> скорость openssl ecdh

• $> скорость openssl aes

Обратите внимание, что единицы между двумя тестами не являются напрямую
сравнимо: тест Диффи-Хеллмана на эллиптических кривых (ECDH) дает
сводная таблица операций в секунду для разных размеров ключей, а
Производительность AES измеряется в байтах в секунду.Тем не менее, это
должно быть легко увидеть, что операции ECDH намного больше
вычислительно дорого.

Точные значения производительности значительно различаются в зависимости от используемого
оборудование, количество ядер, версия TLS, конфигурация сервера и
другие факторы. Не поддавайтесь устаревшим тестам! Всегда запускайте
тесты производительности на вашем собственном оборудовании и обратитесь к разделу «Уменьшение вычислительных ресурсов».
Затраты на дополнительный контекст.

§ Согласование протокола уровня приложений (ALPN)

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

В результате, чтобы обеспечить простое развертывание пользовательских протоколов, мы должны
повторно использовать порты 80 или 443 и использовать дополнительный механизм для согласования
протокол приложения.Порт 80 зарезервирован для HTTP, а HTTP
Спецификация предоставляет специальный поток Upgrade для этого
очень цель. Однако использование Обновление может добавить дополнительные
сетевой обход задержки, и на практике часто ненадежен в
наличие множества посредников; см. Прокси,
Посредники, TLS и новые протоколы в Интернете.

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

Application Layer Protocol Negotiation (ALPN), как следует из названия,
— это расширение TLS, которое удовлетворяет эту потребность. Расширяет TLS
рукопожатие (рисунок 4-2) и позволяет партнерам
согласовывать протоколы без дополнительных обходов.В частности,
процесс выглядит следующим образом:

• Клиент добавляет новое поле ProtocolNameList ,
  содержащий список поддерживаемых протоколов приложений, в
  ClientHello сообщение.

• Сервер проверяет поле ProtocolNameList и
  возвращает поле ProtocolName , указывающее выбранный
  протокол как часть сообщения ServerHello .

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

§История и взаимосвязь NPN и ALPN

Next Protocol Negotiation (NPN) — это расширение TLS, которое
разработан в рамках программы SPDY в Google, чтобы обеспечить эффективную
согласование протокола приложения во время рукопожатия TLS. Звук
привычный? Конечный результат функционально эквивалентен ALPN.

ALPN — это пересмотренная и одобренная IETF версия расширения NPN.
В NPN сервер объявлял, какие протоколы он поддерживает, а
затем клиент выбрал и подтвердил протокол.В ALPN этот обмен
было отменено: теперь клиент указывает, какие протоколы он поддерживает,
Затем сервер выбирает и подтверждает протокол. Обоснование
изменение состоит в том, что это приводит к более близкому согласованию ALPN с
другие стандарты согласования протоколов.

Короче говоря, ALPN является преемником NPN.

§Имя сервера
Индикация (SNI)

Зашифрованный туннель TLS может быть установлен между любыми двумя TCP
одноранговые узлы: клиенту необходимо знать только IP-адрес другого однорангового узла.
чтобы установить соединение и выполнить рукопожатие TLS.Однако что, если
сервер хочет разместить несколько независимых сайтов, каждый со своим
Сертификат TLS на том же IP-адресе — как это работает? Обманывать
вопрос; это не так.

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

§TLS, HTTP и
Выделенные IP-адреса

Рабочий процесс TLS + SNI идентичен заголовку Host
реклама в HTTP, где клиент указывает имя хоста
сайт, который он запрашивает: один и тот же IP-адрес может содержать много разных
домены, и оба SNI и Host необходимы для
устранить неоднозначность между ними.

К сожалению, некоторые старые клиенты (например, большинство запущенных версий IE
в Windows XP, Android 2.2 и другие) не поддерживают SNI. Как
результат, если вам нужно предоставить TLS таким клиентам, то вам может понадобиться
выделенный IP-адрес для каждого хоста.

§ Возобновление сеанса TLS

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

§Идентификаторы сеанса

Первый механизм возобновления идентификаторов сеанса (RFC 5246) был
введен в SSL 2.0, что позволило серверу создавать и отправлять
32-байтовый идентификатор сеанса как часть его ServerHello
сообщение во время полного согласования TLS, которое мы видели ранее. С
идентификатор сеанса на месте, и клиент, и сервер могут хранить
предварительно согласованные параметры сеанса — с ключом по идентификатору сеанса — и повторное использование
их для последующего сеанса.

В частности, клиент может включить идентификатор сеанса в
ClientHello сообщение, чтобы указать серверу, что он
все еще помнит согласованный набор шифров и ключи из предыдущих
рукопожатие и может использовать их повторно. В свою очередь, если сервер может
найти параметры сеанса, связанные с объявленным идентификатором, в его
cache, тогда может произойти сокращенное рукопожатие (рис. 4-3). В противном случае полный
требуется согласование нового сеанса, которое приведет к созданию нового сеанса
Я БЫ.Рисунок 4-3. Сокращенное рукопожатие TLS
протокол

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

Возобновление сеанса — важная оптимизация как для HTTP / 1.Икс
и развертывания HTTP / 2. Сокращенное рукопожатие исключает полное
круговая задержка и значительно снижает вычислительные затраты
для обеих сторон.

Фактически, если браузеру требуется несколько подключений к одному и тому же
хост (например, когда используется HTTP / 1.x), он часто намеренно ждет
для завершения первого согласования TLS перед открытием дополнительных
подключения к одному серверу, чтобы их можно было «возобновить» и
повторно использовать те же параметры сеанса.Если вы когда-нибудь смотрели в сети
проследить и задаться вопросом, почему вы редко видите несколько TLS на одном хосте
переговоры в полете, вот почему!

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

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

§Билеты на сеанс

Для решения этой проблемы при развертывании сеанса TLS на стороне сервера.
кеши, механизм замены «Session Ticket» (RFC 5077) был
введено, что устраняет требование к серверу сохранять
состояние сеанса для каждого клиента.Вместо этого, если клиент указывает, что он
поддерживает билеты сеанса, сервер может включать новый сеанс
Запись билета , которая включает все согласованные данные сеанса
зашифровано секретным ключом, известным только серверу.

Этот билет сеанса затем сохраняется клиентом и может быть включен
в расширении SessionTicket внутри
ClientHello сообщение следующего сеанса. Таким образом, все
данные сеанса хранятся только на клиенте, но билет по-прежнему в безопасности
потому что он зашифрован ключом, известным только серверу.

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

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

§Цепь
Доверительных и Сертификационных Центров

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

• И Алиса, и Боб генерируют свои собственные открытый и закрытый ключи.

• И Алиса, и Боб скрывают свои закрытые ключи.

• Алиса делится своим открытым ключом с Бобом, а Боб — с
  Алиса.

• Алиса создает новое сообщение для Боба и подписывает его.
  закрытый ключ.

• Боб использует открытый ключ Алисы для проверки предоставленного сообщения.
  подпись.

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

Затем Алиса получает сообщение от Чарли, которого она никогда не видела,
но который утверждает, что является другом Боба.Фактически, чтобы доказать, что он
дружив с Бобом, Чарли попросил Боба подписать свой открытый ключ с помощью Боба.
закрытый ключ и прикрепил эту подпись к своему сообщению (рис. 4-4). В этом случае Алиса сначала проверяет
Подпись Боба на ключе Чарли. Она знает открытый ключ Боба и поэтому
возможность проверить, действительно ли Боб подписал ключ Чарли. Потому что она доверяет
Решение Боба проверить Чарли, она принимает сообщение и выполняет
аналогичная проверка целостности сообщения Чарли, чтобы убедиться, что это так,
действительно, от Чарли.Рисунок 4-4. Цепочка доверия для Алисы, Боб,
и Чарли

То, что мы только что сделали, это установление цепочки доверия: Алиса доверяет
Боб, Боб доверяет Чарли, и в результате транзитивного доверия Алиса решает доверять
Чарли. Пока никто в цепочке не скомпрометирован, это позволяет нам
создавать и расширять список доверенных лиц.

Аутентификация в Интернете и в вашем браузере выполняется точно так же
процесс, как показано. Это означает, что на этом этапе вы должны спросить:
кому доверяет ваш браузер и кому вы доверяете, когда используете
браузер? На этот вопрос есть как минимум три ответа:

Сертификаты, указанные вручную

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

Центры сертификации

Центр сертификации (ЦС) — это доверенная третья сторона, которая
доверяет как субъект (владелец) сертификата, так и сторона
полагаясь на сертификат.

Браузер и операционная система

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

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

Рисунок 4-5. Подписание ЦС цифровых
сертификаты

Каждый браузер позволяет вам проверять цепочку доверия вашего безопасного
соединение (рис. 4-6), обычно доступное, щелкнув
на значке замка рядом с URL-адресом.

Рисунок 4-6. Цепочка сертификатов доверия для
igvita.com (Google Chrome, версия 25)

• igvita.com сертификат подписан StartCom Class 1 Primary
  Промежуточный сервер.

• Сертификат первичного промежуточного сервера StartCom класса 1 подписан
  Центром сертификации StartCom.

• StartCom Certification Authority — это признанный корневой сертификат
  орган власти.

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

§Прозрачность сертификата

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

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

§ Отзыв сертификата

Иногда издателю сертификата необходимо отозвать или
признать сертификат недействительным по ряду возможных причин:
закрытый ключ сертификата был скомпрометирован, сертификат
сам авторитет был скомпрометирован, или из-за множества более мягких
такие причины, как заменяющий сертификат, изменение принадлежности и т. д.
на. Для решения этой проблемы сами сертификаты содержат инструкции
(Рисунок 4-7) о том, как
проверьте, не были ли они отозваны.Следовательно, чтобы гарантировать, что цепочка доверия
не скомпрометирован, каждый одноранговый узел может проверить статус каждого сертификата с помощью
следуя встроенным инструкциям вместе с подписями, так как это
проверяет цепочку сертификатов.

Рисунок 4-7. Инструкции CRL и OCSP для
igvita.com (Google Chrome, версия 25)

§Сертификат
Список отзыва (CRL)

Список отозванных сертификатов (CRL) определен RFC 5280 и
определяет простой механизм проверки статуса каждого сертификата:
каждый центр сертификации ведет и периодически публикует список
серийных номеров отозванных сертификатов.Любой, кто пытается подтвердить
сертификат затем может загрузить список отзыва, кэшировать его и
проверьте наличие в нем определенного серийного номера — если он
присутствует, то он был отозван.

Этот процесс прост и понятен, но он имеет ряд
ограничения:

• Растущее число отзывов означает, что список CRL будет
  становятся только длиннее, и каждый клиент должен получить весь список
  серийные номера.

• Нет механизма мгновенного уведомления о сертификате
  отзыв — если CRL был кэширован клиентом до
  сертификат был отозван, то CRL будет считать отозванным
  сертификат действителен до истечения срока действия кеша.

• Необходимость получить последний список CRL из CA может блокировать
  проверка сертификата, которая может значительно увеличить задержку
  Рукопожатие TLS.

• Получение CRL может завершиться ошибкой по разным причинам, и в таких
  случаях поведение браузера не определено. Большинство браузеров рассматривают такие
  случаев как «мягкий сбой», позволяя продолжить проверку — да,
  ой.

§Онлайн
Протокол статуса сертификата (OCSP)

Чтобы устранить некоторые ограничения механизма CRL, Online
Протокол статуса сертификата (OCSP) был введен RFC 2560, который
предоставляет механизм для выполнения проверки в реальном времени статуса
сертификат.В отличие от файла CRL, который содержит все отозванные серийные номера
номеров, OCSP позволяет клиенту запрашивать базу данных сертификатов CA
непосредственно для только серийного номера, о котором идет речь, при проверке
цепочка сертификатов.

В результате механизм OCSP потребляет меньше полосы пропускания и может
для обеспечения проверки в реальном времени. Однако требование выполнить
Запросы OCSP в реальном времени создают свой собственный набор проблем:

• CA должен быть в состоянии обрабатывать нагрузку запросов в реальном времени.

• Центр сертификации должен гарантировать, что служба работает и доступна по всему миру.
  всегда.

• Запросы OCSP в реальном времени могут нарушить конфиденциальность клиента, поскольку
  CA знает, какие сайты посещает клиент.

• Клиент должен блокировать запросы OCSP во время проверки
  цепочка сертификатов.

• Поведение браузера снова не определено и обычно
  приводит к «мягкому сбою», если выборка OCSP завершается неудачно из-за сети
  тайм-аут или другие ошибки.

В качестве реальной точки данных телеметрия Firefox показывает, что OCSP
время ожидания запросов составляет 15% времени, и добавить примерно
350 мс до подтверждения TLS в случае успеха — см. Hpbn.co/ocsp-performance.

§OCSP Сшивание

По причинам, указанным выше, ни отзыва CRL, ни OSCP
механизмы предлагают гарантии безопасности и производительности, которые мы желаем
для наших приложений.Однако не отчаивайтесь, ведь сшивание OCSP
(RFC 6066, расширение «Запрос статуса сертификата») адресовано большинству
проблемы, которые мы видели ранее, разрешив выполнение проверки
сервер и будет отправлен («скреплен») как часть рукопожатия TLS на
клиент:

• Вместо клиента, отправляющего запрос OCSP, это сервер
  который периодически извлекает подписанный OCSP с отметкой времени
  ответ от CA.

• Затем сервер добавляет (т. Е. «Скрепляет») подписанный OCSP.
  ответ как часть рукопожатия TLS, позволяя клиенту
  проверить как сертификат, так и приложенный отзыв OCSP
  запись, подписанная CA.

Эта смена ролей безопасна, поскольку скрепленная запись подписана
ЦС и может быть проверен клиентом, и предлагает ряд
важные преимущества:

• Клиент не пропускает историю переходов.

• Клиенту не нужно блокировать и запрашивать сервер OCSP.

• Клиент может завершить обработку отзыва, если сервер
  opts-in (путем рекламы флага OSCP «Must-Staple») и
  проверка не удалась.

Короче говоря, чтобы получить максимальную безопасность и гарантии производительности,
не забудьте настроить и протестировать сшивание OCSP на своих серверах.

Протокол записи TLS

В отличие от уровней IP или TCP ниже, все данные обмениваются внутри
Сеанс TLS также создается с использованием четко определенного протокола (рис. 4-8). Запись TLS
протокол отвечает за идентификацию различных типов сообщений
(рукопожатие, предупреждение или данные через поле «Тип содержимого»), а также
обеспечение безопасности и проверка целостности каждого сообщения.

Рисунок 4-8. Структура записи TLS

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

• Протокол записи принимает данные приложения.

• Полученные данные разбиваются на блоки: максимум 2 ¹⁴
  байт или 16 КБ на запись.

• Код аутентификации сообщения (MAC) или HMAC добавляется к каждой записи.

• Данные в каждой записи зашифрованы с использованием согласованного шифра.

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

Хорошая новость заключается в том, что вся только что показанная работа выполняется TLS.
сам слой и полностью прозрачен для большинства приложений. Тем не мение,
протокол записи вводит несколько важных выводов, которые мы
нужно знать:

• Максимальный размер записи TLS составляет 16 КБ

• Каждая запись содержит 5-байтовый заголовок, MAC (до 20 байтов для
  SSLv3, TLS 1.0, TLS 1.1 и до 32 байтов для TLS 1.2) и заполнение
  если используется блочный шифр.

• Чтобы расшифровать и проверить запись, вся запись должна быть
  доступный.

Выбор правильного размера записи для вашего приложения, если у вас есть
возможность сделать это может быть важной оптимизацией. Небольшие записи влекут за собой
большие накладные расходы ЦП и байтов из-за кадрирования записи и проверки MAC,
тогда как большие записи должны быть доставлены и собраны заново
Уровень TCP, прежде чем они могут быть обработаны уровнем TLS и доставлены в
ваше приложение — перейдите к разделу «Оптимизация размера записи TLS, чтобы получить полный доступ»
Детали.

§Оптимизация для TLS

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

§Сокращение вычислений
Стоит

Создание и поддержка зашифрованного канала вводит
дополнительные вычислительные затраты для обоих партнеров. В частности, сначала
существует асимметричное (с открытым ключом) шифрование, используемое во время TLS
рукопожатие (объяснение TLS Handshake). Затем, когда общий секрет
установлен, он используется как симметричный ключ для шифрования всех записей TLS.

Как мы уже отмечали ранее, криптография с открытым ключом более вычислительно
дорого по сравнению с криптографией с симметричным ключом, а в
первые дни Интернета часто требовали дополнительного оборудования для выполнения
«Разгрузка SSL.»Хорошая новость в том, что в этом больше нет необходимости и
то, что когда-то требовало специального оборудования, теперь можно сделать прямо на
ПРОЦЕССОР. Крупные организации, такие как Facebook, Twitter и Google, которые
предлагать TLS миллиардам пользователей, выполнять все необходимые TLS
переговоры и вычисления в программном обеспечении и на серийном оборудовании.

В январе этого года (2010) Gmail перешел на использование HTTPS для
все по умолчанию. Ранее он был представлен как
вариант, но теперь все наши пользователи используют HTTPS для защиты своей электронной почты
между их браузерами и Google, все время.Для этого
нам не пришлось развертывать никаких дополнительных машин и специального оборудования. На
на наших производственных интерфейсных машинах SSL / TLS составляет менее 1%
загрузки ЦП, менее 10 КБ памяти на одно соединение и менее
более 2% накладных расходов сети. Многие считают, что SSL / TLS требует
много процессорного времени, и мы надеемся, что предыдущие цифры (общедоступны для
первый раз) поможет это развеять.

Если вы перестанете читать сейчас, вам нужно запомнить только одно:
SSL / TLS больше не требует больших вычислительных затрат.

Адам Лэнгли (Google)

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

Дуг Бивер (Facebook)

Эллиптическая кривая Диффи-Хеллмана (ECDHE) — это всего лишь немного больше.
дороже RSA для эквивалентного уровня безопасности… На практике
развертывании, мы обнаружили, что включение и определение приоритета шифра ECDHE
наборы фактически вызвали незначительное увеличение загрузки ЦП. HTTP
сообщения поддержки активности и возобновление сеанса означают, что большинство запросов не
требуется полное рукопожатие, поэтому операции рукопожатия не влияют на наши
Использование процессора.Мы обнаружили, что 75% клиентских запросов Twitter пересылаются
соединения установлены с помощью ECDHE. Остальные 25% составляют
в основном это старые клиенты, которые еще не поддерживают шифр ECDHE
апартаменты.

Джейкоб Хоффман-Эндрюс (Twitter)

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

Говоря об оптимизации циклов ЦП, убедитесь, что ваши серверы
в актуальном состоянии с последней версией библиотек TLS! Кроме того
к улучшениям безопасности, вы также часто будете видеть производительность
преимущества. Безопасность и производительность идут рука об руку.

§Включение 1-RTT TLS
Рукопожатия

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

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

Чтобы получить наилучшую сквозную производительность, обязательно проведите аудит обоих
собственные и сторонние сервисы и серверы, используемые вашим приложением,
включая вашего провайдера CDN. Для быстрого обзора табеля успеваемости
популярные серверы и CDN, посетите istlsfastyet.com.

§Оптимизировать повторное использование подключения

Лучший способ минимизировать задержку и вычислительные затраты
установка новых соединений TCP + TLS предназначена для оптимизации повторного использования соединений.Таким образом снижаются затраты на установку по запросам и обеспечивается значительная
более быстрый опыт для пользователя.

Убедитесь, что настройки вашего сервера и прокси-сервера позволяют
соединения keepalive и аудит настроек тайм-аута соединения. Много
популярные серверы устанавливают агрессивные тайм-ауты соединения (например, некоторые Apache
версии по умолчанию имеют таймаут 5 секунд), что заставляет много ненужных
повторные переговоры. Для достижения наилучших результатов используйте свои журналы и аналитику, чтобы
определить оптимальные значения тайм-аута.

§Предприятие Раннее
Прекращение действия

Как мы обсуждали в Учебнике по латентности и
Пропускная способность, мы не сможем ускорить передачу наших пакетов,
но мы можем заставить их пройти меньшее расстояние. Разместив наш «край»
серверов ближе к пользователю (рис. 4-9), мы можем значительно сократить
время приема-передачи и общая стоимость рукопожатий TCP и TLS.

Рисунок 4-9. Досрочное увольнение клиента
связи

Простым способом добиться этого является использование услуг
сеть доставки контента (CDN), которая поддерживает пулы пограничных серверов
по всему миру или развернуть свой собственный.Позволяя пользователю
разорвать соединение с ближайшим сервером, вместо того, чтобы пересекать
через океаны и континентальные ссылки на вашу страну происхождения, клиент получает
преимущество «досрочного прекращения» с более короткими поездками туда и обратно. Эта техника
одинаково полезен и важен как для статического, так и для динамического контента: static
контент также может кэшироваться и обслуживаться пограничными серверами, тогда как
динамические запросы могут быть перенаправлены по установленным соединениям из
край к исходной точке.

§ Некэшированная исходная выборка

Метод использования CDN или прокси-сервера для получения
ресурс, который может потребоваться настроить для каждого пользователя или содержит другие
частные данные, и, следовательно, не является глобально кешируемым ресурсом на
edge, обычно известен как «некэшируемая исходная выборка».

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

Фактически в качестве дополнительного уровня оптимизации некоторые CDN
провайдеры будут использовать соседние серверы на обеих сторонах соединения!
Клиентское соединение разрывается на ближайшем узле CDN, который затем
передает запрос узлу CDN, расположенному близко к источнику, и
затем запрос направляется к источнику.Переход в сети CDN
позволяет маршрутизировать трафик по оптимизированной магистрали CDN,
что может помочь еще больше уменьшить задержку между клиентом и источником
серверы.

§Настройка кэширования сеанса и возобновления без сохранения состояния

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

Идентификаторы сеанса, от которых зависит кеширование сеанса TLS, были
введены в SSL 2.0 и имеют широкую поддержку среди большинства клиентов и
серверы. Однако, если вы настраиваете TLS на своем сервере, не
Предположим, что поддержка сеанса будет включена по умолчанию. На самом деле это больше
Обычно он отключен на большинстве серверов по умолчанию, но вам виднее!
Дважды проверьте и проверьте конфигурацию вашего сервера, прокси и CDN:

• Серверы с несколькими процессами или рабочими должны использовать общий
  кеш сеанса.

• Размер общего кеша сеанса должен быть настроен в соответствии с вашими уровнями
  трафика.

• Должен быть указан период ожидания сеанса.

• В конфигурации с несколькими серверами маршрутизация одного и того же IP-адреса клиента или одного и того же
  Идентификатор сеанса TLS на один и тот же сервер — это один из способов обеспечить
  использование кеша сеанса.

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

• Проверяйте и отслеживайте статистику кеширования сеансов TLS для наилучшего
  представление.

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

§Включение ложного запуска TLS

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

Чтобы получить лучшее из обоих миров — рукопожатие в оба конца для новых и
повторных посетителей и экономия вычислительных ресурсов для повторных посетителей — мы можем
используйте TLS False Start, которое является дополнительным расширением протокола, которое
позволяет отправителю отправлять данные приложения (рис. 4-10), когда рукопожатие
только частично завершено.Рисунок 4-10. Рукопожатие TLS с False
Начинать

False Start не изменяет протокол рукопожатия TLS, а скорее
влияет только на время протокола, когда данные приложения могут быть
послал. Интуитивно понятно, как только клиент отправил
ClientKeyExchange запись, она уже знает шифрование
ключ и может начать передачу данных приложения — остальную часть
рукопожатие проводится для подтверждения того, что никто не вмешивался в
записи рукопожатия и могут выполняться параллельно.В результате False
Пуск позволяет нам сохранить рукопожатие TLS за один проход независимо от того,
от того, выполняем ли мы полное или сокращенное рукопожатие.

§Развертывание TLS Ложь
Старт

Потому что False Start только изменяет время рукопожатия
протокол, он не требует никаких обновлений самого протокола TLS
и может быть реализован в одностороннем порядке, то есть клиент может просто начать
передача зашифрованных данных приложения раньше.Ну вот и
теория.

На практике, даже если TLS False Start должен быть обратным
совместим со всеми существующими клиентами и серверами TLS, что позволяет
по умолчанию для всех подключений TLS оказалось проблематичным из-за некоторых
плохо реализованные сервера. В результате все современные браузеры
может использовать TLS False Start, но будет делать это только при определенных
условия соблюдаются сервером:

• Chrome и Firefox требуют объявления протокола ALPN для
  присутствовать в рукопожатии сервера, и что набор шифров
  выбранный сервером обеспечивает прямую секретность.

• Safari требует, чтобы набор шифров, выбранный сервером
  обеспечивает прямую секретность.

• Internet Explorer использует комбинацию черного списка известных
  сайты, которые ломаются при включении TLS False Start, и тайм-аут
  для повторения рукопожатия, если квитирование TLS False Start не удалось.

Чтобы включить ложный запуск TLS во всех браузерах, сервер должен
рекламировать список поддерживаемых протоколов через расширение ALPN — e.грамм.,
«h3, http / 1.1» — и должен быть настроен для поддержки и предпочтения наборов шифров.
которые обеспечивают прямую секретность.

§Оптимизировать размер записи TLS

Все данные приложения, доставляемые через TLS, передаются в
протокол записи (рисунок 4-8). Максимальный размер каждого
размер записи составляет 16 КБ, и в зависимости от выбранного шифра каждая запись будет
добавить от 20 до 40 байтов служебных данных для заголовка, MAC и
необязательная прокладка.Если после этого запись помещается в один TCP-пакет,
тогда мы также должны добавить служебные данные IP и TCP: 20-байтовый заголовок для
IP и 20-байтовый заголовок для TCP без параметров. В результате есть
Потенциально от 60 до 100 байтов накладных расходов для каждой записи. Для
типичный максимальный размер блока передачи (MTU) 1500 байт на
провода, эта структура пакета переводит как минимум 6% кадрирования
накладные расходы.

Чем меньше запись, тем выше накладные расходы на кадрирование.Тем не мение,
просто увеличить размер записи до максимального размера (16 КБ) — это
не обязательно хорошая идея. Если запись охватывает несколько пакетов TCP,
тогда уровень TLS должен дождаться прибытия всех пакетов TCP, прежде чем
он может расшифровать данные (рис. 4-11). Если какой-либо из этих пакетов TCP получит
потерян, переупорядочен или задросселирован из-за перегрузки, тогда
отдельные фрагменты записи TLS необходимо буферизовать перед
их можно декодировать, что приводит к дополнительной задержке.На практике,
эти задержки могут создать значительные узкие места для браузера, которые
предпочитает использовать данные в потоковом режиме.

Рисунок 4-11. WireShark захватывает
11211-байтовая запись TLS, разделенная на 8 сегментов TCP

Маленькие записи несут накладные расходы, большие записи вызывают задержку, и там
нет единственного значения для «оптимального» размера записи. Вместо этого для Интернета
приложения, которые использует браузер, лучшая стратегия —
для динамической регулировки размера записи в зависимости от состояния TCP
связь:

• Если соединение новое и окно перегрузки TCP низкое, или
  когда соединение неактивно в течение некоторого времени (см. Медленный запуск
  Restart), каждый пакет TCP должен содержать ровно одну запись TLS,
  и запись TLS должна занимать полный максимальный размер сегмента
  (MSS), выделенный TCP.

• Когда окно перегрузки соединения велико, и если мы
  передача большого потока (например, потокового видео), размер
  запись TLS может быть увеличена для охвата нескольких пакетов TCP (до
  16 КБ), чтобы уменьшить нагрузку на кадры и ЦП на клиенте и сервере.

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

Использование динамической стратегии обеспечивает максимальную производительность для
интерактивный трафик: небольшой размер записи исключает ненужную буферизацию
задержка и улучшает время до первого — {HTML-байт,…, видео
frame} , а больший размер записи оптимизирует пропускную способность за счет
минимизация накладных расходов TLS для долгоживущих потоков.

Чтобы определить оптимальный размер записи для каждого состояния, начнем с
начальный случай нового или незанятого TCP-соединения, когда мы хотим избежать
Записи TLS из нескольких пакетов TCP:

• Выделите 20 байтов для служебных данных кадрирования IPv4 и 40 байтов для
  IPv6.

• Выделите 20 байтов для служебных данных кадрирования TCP.

• Выделите 40 байтов для служебных данных опций TCP (отметки времени, SACK).

Если исходный MTU составляет 1500 байт, остается 1420 байт.
для записи TLS, доставленной по IPv4, и 1400 байт для IPv6. Быть
в будущем используйте размер IPv6, который оставляет нам 1400 байт для
каждую запись TLS и при необходимости отрегулируйте, если ваш MTU ниже.

Затем решение о том, когда следует увеличить размер записи.
и сбросить, если соединение было бездействующим, может быть установлено на основе
предварительно настроенные пороги: увеличьте размер записи до 16 КБ после
Передано X КБ данных, сбросить запись
размер после Y миллисекунд простоя.

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

§ Оптимизация TLS
в Google

По состоянию на начало 2014 г. серверы Google используют небольшие записи TLS, которые подходят
в один сегмент TCP для первого 1 МБ данных, увеличьте запись
размер до 16 КБ после этого для оптимизации пропускной способности, а затем сбросить
размер записи обратно в один сегмент после одной секунды
бездействие — вспенить, сполоснуть, повторить.

Аналогично, если ваши серверы обрабатывают большое количество TLS
соединений, то минимизация использования памяти для каждого соединения может быть
жизненная оптимизация. По умолчанию популярные библиотеки, такие как OpenSSL
будет выделять до 50 КБ памяти на каждое соединение, но, как и в случае
размер записи, возможно, стоит проверить документацию или источник
код для настройки этого значения. Серверы Google сокращают свои
Буферы OpenSSL уменьшаются примерно до 5 КБ.

§Оптимизировать
Цепочка сертификатов

Проверка цепочки доверия требует, чтобы браузер прошел через
цепочку, начиная с сертификата сайта, и рекурсивно проверьте
сертификат родителя, пока он не достигнет доверенного корня. Следовательно, это
важно, чтобы предоставленная цепочка включала все промежуточные
сертификаты. Если какие-либо из них опущены, браузер будет вынужден приостановить работу.
процесс проверки и получить недостающие сертификаты, добавив
дополнительные поиски DNS, рукопожатия TCP и HTTP-запросы в
процесс.

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

И наоборот, не включайте ненужные сертификаты, такие как
доверенные корни в вашей цепочке сертификатов — они добавляют ненужные байты.
Напомним, что цепочка сертификатов сервера отправляется как часть TLS.
рукопожатие, которое, вероятно, происходит через новое TCP-соединение, которое
на ранних этапах своего алгоритма медленного старта.Если сертификат
размер цепочки превышает начальное окно перегрузки TCP, тогда мы
непреднамеренно добавить дополнительные обходы к рукопожатию TLS:
длина сертификата переполнит окно перегрузки и вызовет
сервер, чтобы остановить и дождаться подтверждения клиента перед продолжением.

На практике размер и глубина цепочки сертификатов были очень значительными.
большие проблемы и проблемы со старыми стеками TCP, которые инициализировали свои
начальное окно перегрузки до 4 сегментов TCP — см. Медленный запуск.Для новее
развертываний, начальное окно перегрузки увеличено до 10 TCP
сегментов и должно быть более чем достаточно для большинства сертификатов
цепи.

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

§Настройка сшивания OCSP

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

Для проверки статуса сертификата браузер может использовать один из
несколько методов: Список отозванных сертификатов
(CRL), Статус онлайн-сертификата
Протокол (OCSP) или OCSP
Сшивание. У каждого метода есть свои ограничения, но OCSP Stapling
обеспечивает, безусловно, лучшие гарантии безопасности и производительности — см.
подробности в предыдущих разделах.Обязательно настройте свои серверы на
включить (скрепить) ответ OCSP от CA к предоставленному
цепочка сертификатов. Это позволит браузеру выполнить
проверка отзыва без дополнительных сетевых обходов и с улучшенными
гарантии безопасности.

• ответов OCSP могут иметь размер от 400 до 4000 байт.
  Привязка этого ответа к вашей цепочке сертификатов увеличит его
  size — обратите особое внимание на общий размер сертификата
  цепочка, чтобы она не переполняла начальное окно перегрузки
  для новых TCP-соединений.

• Текущие реализации OCSP Stapling допускают только один OCSP
  ответ должен быть включен, что означает, что браузеру, возможно, придется
  возврат к другому механизму отзыва, если ему нужно проверить
  другие сертификаты в цепочке — сократите длину своего
  цепочка сертификатов. В будущем OCSP Multi-Stapling должен
  решить эту конкретную проблему.

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

§Включить строгую транспортную безопасность HTTP (HSTS)

HTTP Strict Transport Security — важная политика безопасности
механизм, который позволяет источнику объявлять правила доступа совместимому
браузер через простой HTTP-заголовок, например « Strict-Transport-Security:
max-age = 31536000 «.В частности, он инструктирует пользовательского агента, чтобы
соблюдать следующие правила:

• Все запросы к источнику следует отправлять по HTTPS. Этот
  включает как навигацию, так и все другие подресурсы того же происхождения
  запросы — например, если пользователь вводит URL без префикса https
  пользовательский агент должен автоматически преобразовать его в запрос https;
  если страница содержит ссылку на не-https ресурс, пользователь
  агент должен автоматически преобразовать его, чтобы запросить версию https.

• Если безопасное соединение не может быть установлено, пользователь не
  разрешено обойти предупреждение и запросить версию HTTP, т.е.
  источник только HTTPS.

• max-age указывает время жизни указанного HSTS
  набор правил в секундах (например, max-age = 31536000 равен 365-дневному
  время жизни для рекламируемой политики).

• includeSubdomains указывает, что политика должна
  применяется ко всем субдоменам текущего происхождения.

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

Обязательно тщательно протестируйте развертывание TLS перед включением
HSTS.После кэширования политики клиентом невозможность согласования
Соединение TLS приведет к отказу, т. Е. пользователь увидит
страницу с ошибкой браузера, и продолжить работу не удастся. Это поведение
явный и необходимый выбор дизайна для предотвращения сетевых атак
от обмана клиентов для получения доступа к вашему сайту без HTTPS.

Список предварительной загрузки §HSTS

Механизм HSTS оставляет самый первый запрос источнику
незащищены от активных атак — e.грамм. злонамеренная сторона могла
понизить рейтинг запроса клиента и предотвратить регистрацию
Политика HSTS. Чтобы решить эту проблему, большинство браузеров предоставляют отдельный HSTS
список предварительной загрузки «, который позволяет источнику запросить
включен в список сайтов с поддержкой HSTS, которые поставляются с
браузер.

Когда вы будете уверены в развертывании HTTPS, подумайте о
добавление вашего сайта в список предварительной загрузки HSTS через hstspreload.appspot.com.

§Включить HTTP
Закрепление открытого ключа (HPKP)

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

Компрометация центра сертификации DigiNotar является одним из
несколько громких примеров, когда злоумышленник смог выдать и
использовать поддельные, но действительные сертификаты против сотен известных
места.

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

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

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

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

HPKP также предоставляет режим «только отчет», который не обеспечивает принудительное выполнение
предоставлен PIN-код, но может сообщать об обнаруженных сбоях.Это может быть
отличный первый шаг к валидации вашего развертывания и служит
механизм выявления нарушений.

§Обновить содержимое сайта
на HTTPS

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

• Смешанное «активное» содержимое (напр.грамм. поставлены скрипты и таблицы стилей
  через HTTP) будет заблокирован браузером и может нарушить
  функциональность сайта.

• Смешанный «пассивный» контент (например, изображения, видео, аудио и т. Д.,
  доставляется через HTTP) будет получен, но позволит злоумышленнику
  наблюдать и делать выводы о действиях пользователей, а также снижать производительность за счет
  требующие дополнительных подключений и рукопожатий.

Проверяйте свой контент и обновляйте ресурсы и ссылки, в том числе
сторонний контент, чтобы использовать HTTPS.Механизм политики безопасности контента (CSP) может
окажут здесь большую помощь, как для выявления нарушений HTTPS, так и для обеспечения соблюдения
желаемая политика.

Content-Security-Policy: обновления-небезопасные-запросы
Content-Security-Policy-Report-Only: default-src https :;
  report-uri https://example.com/reporting/endpoint
 

1. Указывает браузеру обновить все (собственные и сторонние)
   запросы к HTTPS.

2. Указывает браузеру сообщать о любых нарушениях, не связанных с HTTPS, на
   назначенная конечная точка.

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

§ Контрольный список для выполнения

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

Имея это в виду, краткий контрольный список для включения в повестку дня:

• Получите максимальную производительность от TCP; см. Оптимизация для
  TCP.

• Обновите библиотеки TLS до последней версии и (пере) соберите серверы
  против них.

• Включите и настройте кэширование сеанса и возобновление без сохранения состояния.

• Отслеживайте процент попаданий в кэширование сеанса и настраивайте конфигурацию
  соответственно.

• Настройте шифры прямой секретности для включения ложного запуска TLS.

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

• Используйте динамическое изменение размера записи TLS для оптимизации задержки и
  пропускная способность.

• Проверяйте и оптимизируйте размер вашей цепочки сертификатов.

• Настройте сшивание OCSP.

• Настройте HSTS и HPKP.

• Настройте политики CSP.

• Включить HTTP / 2; см. HTTP / 2.

§Тестирование и проверка

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

    $> openssl s_client -state -CAfile root.ca.crt -connect igvita.com:443 

  ПОДКЛЮЧЕНО (00000003)
  SSL_connect: до инициализации / подключения
  SSL_connect: SSLv2 / v3 пишет клиенту привет A
  SSL_connect: SSLv3 читает сервер привет A
  глубина = 2 / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
          / CN = Центр сертификации StartCom
  проверить возврат: 1
  глубина = 1 / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
          / CN = ЦС первичного промежуточного сервера StartCom класса 1
  проверить возврат: 1
  глубина = 0 / описание = ABjQuqt3nPv7ebEG / C = США
          / CN = www.igvita.com/[email protected]
  проверить возврат: 1
  SSL_connect: SSLv3 читать сертификат сервера A
  SSL_connect: сервер чтения SSLv3 выполнен A
  SSL_connect: SSLv3 записывает обмен ключами клиента A
  SSL_connect: спецификация шифра изменения записи SSLv3 A
  SSL_connect: запись SSLv3 завершена A
  SSL_connect: данные сброса SSLv3
  SSL_connect: чтение SSLv3 завершено A
  ---
  Цепочка сертификатов
   0 с: / description = ABjQuqt3nPv7ebEG / C = US
       /CN=www.igvita.com/[email protected]
     i: / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
       / CN = ЦС первичного промежуточного сервера StartCom класса 1
   1 с: / C = IL / O = StartCom Ltd./ OU = Безопасная подпись цифрового сертификата
       / CN = ЦС первичного промежуточного сервера StartCom класса 1
     i: / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
       / CN = Центр сертификации StartCom
  ---
  Сертификат сервера
  ----- НАЧАТЬ СЕРТИФИКАТ -----
  ... отрезать ...
  ---
  Имена ЦС сертификатов клиента не отправлены
  ---
  Рукопожатие SSL прочитало 3571 байт и записало 444 байта
  ---
  Новый, TLSv1 / SSLv3, шифр RC4-SHA
  Открытый ключ сервера - 2048 бит
  Поддерживается безопасное повторное согласование
  Сжатие: НЕТ
  Расширение: НЕТ
  SSL-сессия:
      Протокол: TLSv1
      Шифр: RC4-SHA
      Идентификатор сеанса: 269349C84A4702EFA7...
      Идентификатор сеанса-ctx:
      Мастер-ключ: 1F5F5F33D50BE6228A ...
      Key-Arg: Нет
      Время начала: 1354037095
      Тайм-аут: 300 (сек)
      Проверить код возврата: 0 (ок)
  ---
 

1. Клиент завершил проверку полученной цепочки сертификатов.

2. Цепочка полученных сертификатов (два сертификата).

3. Размер полученной цепочки сертификатов.

4. Выданный идентификатор сеанса для возобновления TLS с отслеживанием состояния.

В предыдущем примере мы подключаемся к igvita.com через порт TLS по умолчанию (443) и
выполните рукопожатие TLS. Поскольку s_client не делает
предположения об известных корневых сертификатах, вручную указываем путь
к корневому сертификату, который на момент написания является StartSSL
Центр сертификации для примера домена.В вашем браузере уже есть
общие корневые сертификаты и, таким образом, может проверять цепочку, но
s_client не делает таких предположений. Попробуйте опустить корень
сертификат, и вы увидите в журнале ошибку проверки.

Проверка цепочки сертификатов показывает, что сервер отправил два
сертификаты, которые в сумме составляют 3571 байт. Также мы можем видеть
согласованные переменные сеанса TLS — выбранный протокол, шифр, ключ — и мы можем
также убедитесь, что сервер выдал идентификатор сеанса для текущего
сессия, которая может быть возобновлена ​​в будущем.

Обновление

для включения TLS 1.1 и TLS 1.2 в качестве безопасных протоколов по умолчанию в WinHTTP в Windows

Это обновление обеспечивает поддержку Transport Layer Security (TLS) 1.1 и TLS 1.2 в Windows Server 2012, Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Об этом обновлении

Приложения и службы, написанные с использованием WinHTTP для соединений Secure Sockets Layer (SSL), которые используют флаг WINHTTP_OPTION_SECURE_PROTOCOLS, не могут использовать TLS 1.1 или TLS 1.2. Это связано с тем, что определение этого флага не включает эти приложения и службы.

Это обновление добавляет поддержку записи реестра DefaultSecureProtocols, которая позволяет системному администратору указывать, какие протоколы SSL следует использовать при использовании флага WINHTTP_OPTION_SECURE_PROTOCOLS.

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

Так обстоит дело с некоторыми приложениями Microsoft Office, когда они открывают документы из библиотеки SharePoint или веб-папки, туннелей IP-HTTPS для подключения DirectAccess и других приложений с использованием таких технологий, как WebClient, с использованием WebDav, WinRM и других.

Это обновление требует, чтобы компонент Secure Channel (Schannel) в Windows 7 был настроен для поддержки TLS 1.1 и 1.2. Поскольку эти версии протокола не включены по умолчанию в Windows 7, необходимо настроить параметры реестра, чтобы приложения Office могли успешно использовать TLS 1.1 и 1.2.

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

Как получить это обновление

Внимание! Если вы устанавливаете языковой пакет после установки этого обновления, вы должны переустановить это обновление.Поэтому мы рекомендуем вам установить все необходимые языковые пакеты перед установкой этого обновления. Дополнительные сведения см. В разделе Добавление языковых пакетов в Windows.

Метод 1. Центр обновления Windows

Это обновление предоставляется как Рекомендуемое обновление в Центре обновления Windows. Дополнительные сведения о том, как запустить Центр обновления Windows, см. В разделе Как получить обновление через Центр обновления Windows.

Метод 2: Каталог Центра обновления Майкрософт

Чтобы получить автономный пакет для этого обновления, перейдите на веб-сайт каталога Центра обновления Майкрософт.

Обновить подробную информацию

Предварительные требования

Чтобы применить это обновление, необходимо установить пакет обновления 1 для Windows 7 или Windows Server 2008 R2.

Нет никаких предварительных условий для установки этого обновления в Windows Server 2012.

Информация реестра

Чтобы применить это обновление, необходимо добавить подраздел реестра DefaultSecureProtocols.
Примечание Для этого можно вручную добавить подраздел реестра или установить «Простое исправление» для заполнения подраздела реестра.

Требование перезагрузки

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

Обновление информации о замене

Это обновление не заменяет ранее выпущенное обновление.

Дополнительная информация

Для соответствия стандарту индустрии платежных карт

(PCI) требуется TLS 1.1 или TLS 1.2.

Для получения дополнительной информации о флаге WINHTTP_OPTION_SECURE_PROTOCOLS см. Флаги опций.

Как работает запись реестра DefaultSecureProtocols

Важно. Этот раздел, метод или задача содержат шаги, которые говорят вам, как изменить реестр.Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы выполните следующие действия внимательно. Для дополнительной защиты сделайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. В разделе Резервное копирование и восстановление реестра в Windows.

Когда приложение указывает WINHTTP_OPTION_SECURE_PROTOCOLS, система проверит наличие записи реестра DefaultSecureProtocols и, если она есть, переопределит протоколы по умолчанию, указанные в WINHTTP_OPTION_SECURE_PROTOCOLS, протоколами, указанными в записи реестра.Если запись в реестре отсутствует, WinHTTP будет использовать существующие настройки операционной системы по умолчанию для Win WINHTTP_OPTION_SECURE_PROTOCOLS HTTP. Эти настройки WinHTTP по умолчанию соответствуют существующим правилам приоритета и отменяются протоколами, отключенными SCHANNEL, и протоколами, установленными для каждого приложения с помощью WinHttpSetOption.

Примечание Программа установки исправления не добавляет значение DefaultSecureProtocols. Администратор должен вручную добавить запись после определения протоколов переопределения.Или вы можете установить «Простое исправление» для автоматического добавления записи.

Запись реестра DefaultSecureProtocols может быть добавлена ​​по следующему пути:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ WinHttp

На компьютерах на базе x64 протокол DefaultSecureProtocols также необходимо добавить в путь Wow6432Node:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ WinHttp

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

Например:

Администратор хочет переопределить значения по умолчанию для WINHTTP_OPTION_SECURE_PROTOCOLS, чтобы указать TLS 1.1 и TLS 1.2.

Возьмите значение TLS 1.1 (0x00000200) и значение TLS 1.2 (0x00000800), затем сложите их вместе в калькуляторе (в режиме программиста), и результирующее значение реестра будет 0x00000A00.

Простое исправление

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

Банкноты

• Этот мастер может быть только на английском языке. Однако автоматическое исправление также работает для других языковых версий Windows.

• Если вы не используете компьютер, на котором возникла проблема, сохраните решение простого решения на флэш-накопитель или компакт-диск, а затем запустите его на компьютере, на котором возникла проблема.

Примечание В дополнение к подразделу реестра DefaultSecureProtocols, Easy fix также добавляет SecureProtocols в следующем месте, чтобы помочь включить TLS 1.1 и 1.2 для Internet Explorer.

Запись реестра SecureProtocols со значением 0xA80 для включения TLS 1.1 и 1.2 будет добавлена ​​по следующим путям:

HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Настройки Интернета

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Internet Settings

Включить TLS 1.1 и 1.2 в Windows 7 на уровне компонента SChannel

Согласно статье о параметрах TLS-SSL, для включения и согласования TLS 1.1 и 1.2 в Windows 7 вы ДОЛЖНЫ создать запись «DisabledByDefault» в соответствующем подразделе (клиент) и установить для нее значение «0». Эти подразделы не будут созданы в реестре, поскольку эти протоколы по умолчанию отключены.

Создайте необходимые подключи для TLS 1.1 и 1.2; создайте значения DWORD DisabledByDefault и установите для него значение 0 в следующих местах:

Для TLS 1.1

Расположение в реестре: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocols \ TLS 1.1 \ Client
Имя DWORD: DisabledByDefault
Значение DWORD: 0

для TLS 1.2

Расположение в реестре: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocols \ TLS 1.2 \ Клиент
Имя DWORD: DisabledByDefault
Значение DWORD: 0

Информация о файле

Версия этого обновления программного обеспечения на английском языке (США) устанавливает файлы, атрибуты которых указаны в следующих таблицах.

Windows 7 и Windows Server 2008 R2

Банкноты

• Файлы, относящиеся к конкретному продукту, этапу (RTM, SP n ) и ветви обслуживания (LDR, GDR), можно определить, проверив номера версий файлов, как показано в следующей таблице.

  Версия	Товар	Веха	Сервисное отделение
  6.1,760 1,23 ххх	Windows 7 или Windows Server 2008 R2	СП1	LDR

• Сервисные отделения

  GDR содержат только те исправления, которые широко выпускаются для решения широко распространенных критических проблем.Филиалы службы LDR содержат исправления в дополнение к широко выпускаемым исправлениям.

• Файлы МАНИФЕСТА (.manifest) и MUM (.mum), установленные для каждой среды, перечислены в разделе «Сведения о дополнительных файлах». MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не указаны атрибуты, подписаны цифровой подписью Microsoft.

x86 Windows 7

ia64 Windows Server 2008 R2

x64 Windows 7 и Windows Server 2008 R2

Windows Server 2012

Банкноты

• Файлы, относящиеся к конкретному продукту, этапу (RTM, SP n ) и ветви обслуживания (LDR, GDR), можно определить, проверив номера версий файлов, как показано в следующей таблице.

  Версия	Товар	Веха	Сервисное отделение
  6.2,920 0,21 ххх	Windows Server 2012	RTM	LDR

• Сервисные отделения

  GDR содержат только те исправления, которые широко выпускаются для решения широко распространенных критических проблем.Филиалы службы LDR содержат исправления в дополнение к широко выпускаемым исправлениям.

• Файлы МАНИФЕСТА (.manifest) и MUM (.mum), установленные для каждой среды, перечислены в разделе «Сведения о дополнительных файлах». MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не указаны атрибуты, подписаны цифровой подписью Microsoft.

x64 Windows Server 2012

Дополнительная информация о файле

x86 Windows 7

ia64 Windows Server 2008 R2

x64 Windows Server 2012

x64 Windows 7 и Windows Server 2008 R2

Список литературы

Узнайте о терминологии, которую Microsoft использует для описания обновлений программного обеспечения.