TLS 1.3 Introduction

HTTPS
TLS 1.3 Introduction

1. Назначение протокола TLS

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

  • Аутентификация: Серверная сторона канала всегда должна быть аутентифицирована; клиентская сторона может быть аутентифицирована дополнительно. Аутентификация может выполняться с помощью асимметричного алгоритма (например, RSA, алгоритма цифровой подписи на основе эллиптических кривых (ECDSA) или алгоритма цифровой подписи на основе кривой Эдвардса (EdDSA)) или с помощью симметричного предварительного общего ключа (PSK).

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

  • Целостность: при отправке данных по установленному каналу невозможно, чтобы данные были подделаны и не были обнаружены. То есть, как только данные будут изменены, одноранговый узел немедленно обнаружит подделку.

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

Во-вторых, состав протокола TLS

Протокол TLS в основном состоит из двух основных компонентов:

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

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

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

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

Стандарт TLS 1.3 заменяет предыдущие версии TLS, включая версию 1.2, и объявляет их устаревшими.RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2. также отменен вRFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side StateОпределенный в нем механизм билетов TLS и замена его механизмом Pre-Shared Key (PSK). Поскольку TLS 1.3 изменил способ экспорта ключей, он обновилRFC5705 Keying Material Exporters for Transport Layer Security (TLS). Он также изменяет способ передачи сообщений протокола статуса онлайн-сертификата (OCSP), поэтому обновленRFC6066 https://tools.ietf.org/html/rfc6066, отмененRFC6961 he Transport Layer Security (TLS) Multiple Certificate Status Request Extension, как описано в главе Статус OCSP и расширения SCT.

3. Основное различие между TLS 1.3 и TLS 1.2

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

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

  • Добавлен режим 0-RTT, который экономит время приема и передачи для некоторых данных приложения на этапе установления соединения за счет определенных функций безопасности.Что касается вопросов безопасности 0-RTT, мы обсудим их ниже..

  • Наборы статических шифров RSA и Diffie-Hellman были удалены; все алгоритмы обмена ключами на основе открытого ключа теперь обеспечивают безопасность в прямом направлении.

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

  • Функция вывода ключей была переработана. Новый дизайн упрощает анализ криптографами благодаря улучшенным свойствам разделения ключей. В качестве базового примитива используется функция извлечения и расширения ключа (HKDF) на основе HMAC.

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

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

  • Другие криптографические улучшения включают изменение заполнения RSA для использования схемы вероятностной подписи RSA (RSASSA-PSS), удаление сжатия, DSA и настройку группы DHE.

  • Механизм согласования версии TLS1.2 устарел. Поддержка использования списков версий в расширениях. Это повышает совместимость с серверами, которые неправильно реализуют согласование версий.

  • Возобновление сеанса с состоянием на стороне сервера и без него, а также наборы шифров на основе PSK для более ранних версий TLS были заменены одним новым обменом PSK.

  • Обновите ссылки, чтобы они указывали на последнюю версию RFC (например, RFC 5280 вместо RFC 3280).

4. Улучшения, затрагивающие TLS 1.2

Некоторые необязательные реализации TLS 1.2 также определены в спецификации TLS 1.3, включая те, которые не поддерживают TLS 1.3.

  • Механизмы защиты от понижения версии, определенные в TLS 1.3
  • Схема подписи RSASSA-PSS
  • Расширение «supported_versions» в ClientHello можно использовать для согласования версии, используемой TLS, которая имеет приоритет над полем legacy_version в ClientHello.
  • Расширение «signature_algorithms_cert» позволяет клиенту показать, какой алгоритм подписи он использует для проверки сертификата X.509.

Пять, обзор протокола TLS 1.3

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

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

TLS 1.3 поддерживает 3 основных режима обмена ключами:

  • (EC)DHE (Диффи-Хеллман на основе конечных полей или эллиптических кривых)
  • PSK - only
  • PSK with (EC)DHE

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

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

+ указывает на заслуживающее внимания расширение, отправленное в ранее аннотированном сообщении
* Указывает необязательные или условные сообщения/расширения, которые не всегда отправляются
() означает, что сообщение защищено ключом, полученным из Client_early_traffic_secret
{} указывает, что сообщение защищено ключом, полученным из [sender]_handshake_traffic_secret
[] указывает, что сообщение защищено ключом, полученным из [sender]_application_traffic_secret_N

Рукопожатие можно рассматривать как состоящее из трех фаз (см. выше):

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

На этапе обмена ключами Клиент отправляет сообщение ClientHello, содержащее случайный одноразовый номер (ClientHello.random), версию протокола, список пар симметричного шифра/хеш-кода HKDF, набор общих ключей Диффи-Хеллмана или Набор меток предварительно общих ключей (в расширении «key_share») или и то, и другое; и, возможно, другие расширения.

Сервер обрабатывает ClientHello и определяет соответствующие параметры шифрования для соединения. Затем он отвечает своим собственным ServerHello, указывающим согласованные параметры соединения. ClientHello и ServerHello вместе определяют общий секрет. Если используется установленный ключ (EC)DHE, ServerHello будет содержать расширение «key_share» вместе с временным общим параметром Diffie-Hellman сервера, который должен использоваться совместно с одним из параметров клиента, находящихся в той же группе. Если используется ключ PSK, в ServerHello включается расширение «pre_shared_key», чтобы указать, какой PSK, предоставленный клиентом, выбран. Обратите внимание, что реализации могут использовать (EC)DHE и PSK вместе, и в этом случае необходимо предоставить оба расширения.

Затем Сервер отправит два сообщения для установки параметров Сервера:

  • EncryptedExtensions: ответы на расширения ClientHello, которым не нужно определять параметры шифрования, кроме тех, которые относятся к отдельным сертификатам.
  • CertificateRequest: если требуется проверка подлинности клиента на основе сертификата, обязательным параметром является сертификат. Опустите это сообщение, если проверка подлинности клиента не требуется.

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

  • Сертификат: Сертификат терминала и расширения для каждого сертификата. Если сервер не аутентифицируется с помощью сертификата и если сервер не отправляет CertificateRequest (тем самым указывая, что клиент не должен аутентифицироваться с помощью сертификата), клиент проигнорирует это сообщение. Обратите внимание, что при использовании исходного открытого ключа[RFC7250]или расширение информации кеша[RFC7924], сообщение будет содержать не сертификат, а дополнительное значение, соответствующее долговременному ключу сервера.

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

  • Готово: MAC (код аутентификации сообщения) для всего сообщения подтверждения. Это сообщение обеспечивает подтверждение ключа, привязывая идентификатор терминала к обменному ключу, так что рукопожатие может быть аутентифицировано также в режиме PSK.

После получения сообщения от Сервера Клиент отвечает своими сообщениями аутентификации, а именно Certificate, CertificateVerify (при необходимости) и Finished.

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

1. Неправильная доля DHE

Если клиент не предоставляет достаточное расширение «key_share» (например, оно содержит только группы DHE или ECDHE, которые сервер не принимает или не поддерживает), сервер будет использовать HelloRetryRequest для исправления несоответствия, а клиенту необходимо использовать соответствующее расширение «key_share», чтобы перезапустить рукопожатие, как показано на изображении ниже. Если никакие общие параметры шифрования не могут быть согласованы, сервер ДОЛЖЕН выдать соответствующее предупреждение, чтобы прервать рукопожатие.

        Client                                               Server

        ClientHello
        + key_share             -------->
                                                  HelloRetryRequest
                                <--------               + key_share
        ClientHello
        + key_share             -------->
                                                        ServerHello
                                                        + key_share
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                     {Certificate*}
                                               {CertificateVerify*}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

Как показано выше, поток сообщений завершенного процесса рукопожатия с несовпадающими параметрами

Обратите внимание, что это рукопожатие включает в себя первоначальный обмен ClientHello/HelloRetryRequest и не может быть сброшен новым ClientHello.

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

2. Мультиплексирование и общий ключ (PSK)

В то время как предварительный общий ключ TLS (PSK) может быть установлен вне диапазона, предварительный общий ключ также может быть установлен при предыдущем соединении, а затем повторно использован (возобновление сеанса). После завершения рукопожатия сервер может отправить клиенту ключ PSK, соответствующий уникальному ключу из начального рукопожатия. Затем клиент может использовать этот ключ PSK для согласования использования соответствующего PSK в будущих рукопожатиях. Если сервер принимает его, контекст безопасности для нового соединения криптографически связывается с первоначальным соединением, а ключ из исходного рукопожатия используется для загрузки криптографического состояния вместо полного рукопожатия. В TLS 1.2 и ниже эта функция представлена ​​«идентификаторами сеанса» и «билетами сеанса».[RFC5077]предоставлять. Оба этих механизма устарели в TLS 1.3.

PSK можно использовать в сочетании с алгоритмом обмена ключами (EC)DHE для обеспечения прямой безопасности для общего ключа, или PSK можно использовать отдельно за счет потери прямой безопасности данных приложения.

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

          Client                                               Server

   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]


   Subsequent Handshake:
          ClientHello
          + key_share*
          + pre_shared_key          -------->
                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]

Когда сервер аутентифицируется с помощью PSK, он не отправляет сертификат или сообщение CertificateVerify. Когда клиент хочет возобновить сеанс через PSK, он также должен предоставить серверу «key_share», чтобы позволить серверу вернуться к повторному ответу на полный процесс рукопожатия, когда он отказывается возобновить сеанс. Сервер отвечает на расширение «pre_shared_key», чтобы установить соединение с использованием согласования ключа PSK, а также отвечает на расширение «key_share» для установления ключа (EC)DHE, тем самым обеспечивая безопасность в прямом направлении.

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

Примечание. При использовании предварительного общего ключа, предоставленного вне диапазона, ключевым соображением является использование достаточной энтропии при генерации ключа, как в[RFC4086]как обсуждалось в. Общий секрет, полученный из пароля или другого низкоэнтропийного источника, не является безопасным. Пароль с низкой энтропией, или парольная фраза, уязвим для атаки по словарю на основе связующего PSK. Указанный ключ PSK не является аутентифицированным обменом ключами на основе надежного пароля, даже если используется метод установления ключа Диффи-Хеллмана. В частности, он не предотвращает атаки методом грубой силы на пароли/предварительно общие ключи со стороны злоумышленника, который может наблюдать за процессом рукопожатия.

3. Данные 0-RTT

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

Как показано на рисунке ниже, данные 0-RTT добавляются к процессу установления связи 1-RTT в первом отправленном сообщении. В остальном рукопожатие такое же, как рукопожатие 1-RTT с возобновлением сеанса PSK.

         Client                                               Server

         ClientHello
         + early_data
         + key_share*
         + psk_key_exchange_modes
         + pre_shared_key
         (Application Data*)     -------->
                                                         ServerHello
                                                    + pre_shared_key
                                                        + key_share*
                                               {EncryptedExtensions}
                                                       + early_data*
                                                          {Finished}
                                 <--------       [Application Data*]
         (EndOfEarlyData)
         {Finished}              -------->
         [Application Data]      <------->        [Application Data]

На картинке выше показан информационный поток 0-RTT.

+ пометил заслуживающее внимания расширение, отправленное в ранее отмеченном сообщении
* Указывает необязательные или условные сообщения/расширения, которые не всегда отправляются
() означает, что сообщение защищено ключом, полученным из client_early_traffic_secret
{} указывает, что сообщение защищено ключом, полученным из [sender]_handshake_traffic_secret
[] указывает, что сообщение защищено ключом, полученным из [sender]_application_traffic_secret_N

Массивы 0-RTT несколько менее безопасны, чем другие типы данных TLS, в частности:

  1. Данные 0-RTT не имеют прямой защиты, они шифруются с использованием ключа, полученного из предоставленного PSK.
  2. Нет гарантии, что не будет повторных атак через несколько подключений. Обычный метод защиты данных TLS 1.3 1-RTT для предотвращения повторных атак заключается в использовании случайного числа, отправляемого сервером.Теперь 0-RTT не зависит от сообщения ServerHello, поэтому меры защиты еще хуже. Это соображение безопасности особенно важно, если данные аутентифицируются с помощью клиента TLS или аутентифицируются с помощью протокола приложения. Это предупреждение относится к любому использованию Early_exporter_master_secret.

Данные 0-RTT не могут быть реплицированы между соединениями (т. е. сервер не будет обрабатывать одни и те же данные дважды для одного и того же соединения), и злоумышленник не сможет замаскировать данные 0-RTT под данные 1-RTT (поскольку они защищены другое шифрование).защита ключа).

Безопасность 0-RTT будет рассмотрена в отдельной статье.

Ссылка:

RFC 8446

Репозиторий GitHub:Halfrost-Field

Follow: halfrost · GitHub

Source: GitHub.com/HAL мороз/га…

Категории