Какой протокол имеет транспортный уровень шифрования

TLS/SSL Protocol

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are two closely related protocols designed to protect confidentiality and integrity of data in transit between two hosts.

TLS/SSL can add a secure layer to a number of already existing application layer protocols (e.g. HTTP, LDAP, FTP, SMTP, and others). It can also be used to create a VPN solution (e.g. OpenVPN).

History

SSL protocol was developed by Netscape in 1994. In 1996 Netscape released SSL 3.0 which is would be the last version. IETF continued the development of the protocol under a new name — Transport Layer Security (TLS). In 1999 IETF released TLS 1.0 as a standard in RFC2246.

Architecture

The TLS/SSL Protocol is composed of multiple layers. The lowest level, layered on top of some reliable transport protocol (e.g. TCP), is the Record Protocol. It is used for encapsulation of several higher level protocols:

• Handshake Protocol — allows the server and client to authenticate each other, to negotiate an encryption algorithm, and exchange cryptographic keys.
• Alert Protocol — alert messages convey the severity and a description of the alert (errors, closure, handshake failures, etc.). Alert messages with a level of fatal result in the immediate termination of the connection. Alert messages are encrypted and compressed, as specified by the current connection state.
• Application Protocol — protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP.

Handhake Protocol

In order to establish a secure session between a client and a server, TLS protocol performs several authentication and shared key creation steps known as the Handshake. During the handshake, the following messages may be exchanged:

Below is a sample Handshake exchange between a client and a server:

Client Hello

Client Hello — the client transmits a hello message in order to establish security enhancement capabilities between client and server. Client Hello message contains client’s protocol version, session id (used to resume previously cached handshake), a list of supported ciphers suites, a list of compression methods, and random data.

Server Hello

Server Hello — the server transmits its own hello message in response to client’s hello. It contains server’s choice of the protocol version, session id (attempts to match session id received from the client), the chosen cipher suite, the chosen compression method, and random data.

In the example below, TLS_RSA_WITH_AES_256_CBC_SHA cipher suite selection can be interpreted as follows:

• Key Exchange Algorithm — TLS
• Authentication Algorithm — RSA
• Cipher for Data Transfer — AES 256 CBC Block Cipher
• MAC Digest Algorithm — SHA

Below is a sample Server Hello packet snippet:

Certificate

Certificate — the server sends its certificate which includes server’s public key. The client may use this information to verify authenticity of the server.

Server Hello Done

Server Hello Done — the server completes it’s hello messages. Protocol, cipher, and compression negotiations are complete.

Client Key Exchange

Client Key Exchange — with this message, the premaster key is set through direct transmission of the RSA-encrypted secret which will allow each side to agree upon the same premaster secret. Other key exchange algorithms are supported. (Diffie-Hellman key exchange is deprecated).

Computing the master secret

Once the client generates and sends out the premaster key, both client and server will compute the master key using a PRF (Pseudo Random Function). PRF takes a key (premaster key sent by the client), a label (master key), and a seed (client random value + server random value). PRF will generate a 48 byte master key by splitting the premaster key in half and XORing those halves with MD5 and SHA-1 hashes of respective halves.

Client Change Cipher Spec

Change Cipher Spec — the client notifies the server, that all further communication will be encrypted

Client Encrypted Finished

Encrypted Finished — this message is sent by the client to verify that the key exchange and authentication processes were successful. The finished message is protected with the just-negotiated algorithms, keys, and secrets. Once the other party receives and validates this message, it will be able to send application data over the connection.

Server Change Cipher Spec

Change Cipher Spec — upon the receipt of a valid Finished message from the client, the server will also announce that it is switching to encrypted communication with its own Change Cipher Spec announcement.

Server Encrypted Finished

Encrypted Finished — at last the server will issue its own encrypted Finished message to make sure the client and the server can understand each other. This concludes the handshake.

Протокол безопасности транспортного уровня (TLS), версия 1.2 (RFC 5246) (Часть 1)

На настоящий момент (август 2021 года) мною не было найдено хоть сколько-нибудь приемлемого перевода стандарта протокола TLS версии 1.2 на русский язык. Единственный найденный перевод находится сайте protocols.ru и при всем уважению к его автору, не устраивает меня по причине неудобочитаемости и трудности восприятия. И хотя на сайте efim360.ru находится качественно выполненный перевод стандарта протокола TLS версии 1.3, многие места этого перевода могут вызвать некоторые трудности для понимания, особенно у начинающего изучать криптографию читателя. Для устранения таких «белых пятен» и было задумано осуществить перевод стандарта протокола TLS версии 1.2 на русский язык.

Развитием стандарта TLS занимается организация IETF (Internet Engineering Task Force). На настоящий момент протокол TLS 1.2 считается устаревшим после выхода в августе 2018 года стандарта протокола TLS 1.3. Тем не менее, спецификация протокола версии 1.2 до сих пор является наиболее распространенной версией протокола TLS, что не лишает практического смысла ее перевод на русский язык. С момента опубликования в августе 2008 года стандарта TLS 1.2 выходили другие стандарты, обновлявшие спецификацию TLS 1.2. Данные стандарты приведены в исходном тексте спецификации. Тем не менее, автор считает нужным привести их и здесь:

E. Rescorla, M. Ray, S. Dispensa, N. Oskov «Transport Layer Security (TLS) Renegotiation Indication Extension», RFC 5746, February 2010 – Устранение уязвимости во время пересогласования (англ. renegotiation) сервером и клиентом новых ключей. Описание расширения индикации пересогласования (Renegotiation Indication Extension).

M. Brown, R. Housley, «Transport Layer Security (TLS) Authorization Extensions», RFC 5878, May 2010 – Документ описывает расширения авторизации для протокола рукопожатия TLS (TLS Handshake Protocol). Расширения указываются в клиентских и серверных сообщениях «hello»[1] для подтверждения того, что обе стороны поддерживают желаемый тип авторизации данных.

S. Turner, T. Polk, «Prohibiting Secure Sockets Layer (SSL) Version 2.0», RFC 6176, March 2011 – Документ содержит требование запрета на согласование использования протокола Secure Sockets Layer (SSL) версии 2.0 при установлении соединения между сервером и клиентом.

A. Popov, «Prohibiting RC4 Cipher Suites», RFC 7465, February 2015 — Документ содержит требование запрета на согласование криптонаборов на основе потокового шифра RC4 при установлении соединения между сервером и клиентом. Документ обязателен для протокола TLS всех версий.

B. Moeller, A. Langley, «TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks», RFC 7507, April 2015 – Документ определяет сигнальное значение криптонабора (Signaling Cipher Suite Value (SCSV)), предотвращающее атаки на понижение версии протоколов TLS и DTLS (Datagram Transport Layer Security).

R. Barnes, M. Thomson, A. Pironti, A. Langley, «Deprecating Secure Sockets Layer Version 3.0», RFC 7568, June 2015 – Объявление о прекращении использования (англ. deprecating[2]) протокола Secure Sockets Layer версии 3.0 (SSLv3, SSL 3.0).

K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray, «Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension», RFC 7627, September 2015 – Спецификация определяет расширение TLS, которое контекстно связывает основной ключ[3] с полным логом протокола рукопожатия (TLS Handshake Protocol), вычисляющего этот ключ. Таким образом, предотвращается атака «man-in-the-middle», при которой злоумышленник при помощи одного основного ключа может устанавливать одновременно две сессии – одну с клиентом, другую – с сервером.

A. Langley, «A Transport Layer Security (TLS) ClientHello Padding Extension», RFC 7685, October 2015 – Документ описывает расширение протокола TLS, позволяющее увеличивать до желаемого размера (англ. to pad) сообщения ClientHello. Данная необходимость возникла в связи с тем, что некоторые реализации протокола, основанные на новых криптонаборах и расширениях, увеличивают сообщение ClientHello.

A. Langley, W. Chang, N. Mavrogiannopoulos,J. Strombergson, S. Josefsson, «ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)», RFC 7905, June 2016 – Документ описывает использование криптонабора ChaCha и аутентификатора Poly1305 в протоколах TLS и DTLS.

D. Gillmor, «Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)», RFC 7919, August 2016 – Документ водит группы ffdhe в регистр Supported Groups (поддерживаемые группы) параметров TLS. Введение данных групп позволяет узлам (англ. peer) установить общие параметры алгоритма Диффи-Хеллмана для конечного поля (англ. common finite field DH parameters), что позволяет устранить недостатки традиционного обмена ключами с использованием алгоритма Диффи-Хеллмана на основе конечного поля.

J. Salowey, S. Turner «IANA Registry Updates for TLS and DTLS», RFC 8447, August 2018 – Документ описывает изменения в регистрах IANA для протоколов TLS[4] и DTLS, начиная добавлением примечаний, заканчивая изменением политики регистрации.

Сам текст стандарта протокола может содержать ошибки, которые указываются в специальном разделе «Errata». Все ошибки разделены на два типа – подтвержденные (англ. verified) и неподтвержденные (англ. reported). Текст стандарта приводится с учетом подтвержденных ошибок. Указанные ошибки в тексте перевода учитываться не будут, но места в тексте, имеющие указание на ошибку, будут отмечаться соответствующим комментарием.

Первая часть перевода содержит вступительную часть, описание псевдоязыка и хэш-функции HMAC. Вторая часть перевода будет содержать описание протокола записи (TLS Record Protocol), третья – протокола процесса рукопожатия (TLS Handshaking Protocol), четвертая – заключительные положения и приложения.

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

Все примечания, сделанные переводчиком сопровождаются пометкой «(Прим. перев.)».

Содержание

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

6.1. Состояния соединения

6.2. Уровень записей

6.2.2. Сжатие и распаковка записей

6.2.3. Защита записей

6.2.3.1. Нулевой шифр и стандартный потоковый шифр

6.2.3.2. Блочный шифр в режиме сцепления блоков (CBC-шифр)

6.2.3.3. Шифры AEAD (с дополнительно прикрепляемыми данными)

6.3. Вычисление ключа

7. Протоколы процесса рукопожатия TLS

7.1. Протокол изменения параметров шифрования (Change Cipher Spec)

7.2. Протокол оповещений

7.2.1. Оповещения о закрытии соединения

7.2.2. Сообщения об ошибках

7.3. Обзор протокола рукопожатия

7.4. Протокол рукопожатия

7.4.1.1. Hello-запрос (Hello Request)

7.4.1.2. Клиентское hello-сообщение

7.4.1.3. Серверное hello-сообщение

7.4.1.4. Расширения hello-сообщений

7.4.1.4.1. Расширение «алгоритмы подписи» (signature_algorithms)

7.4.2. Серверный сертификат

7.4.3. Серверное сообщение обмена ключами (ServerKeyExchange)

7.4.4. Запрос сертификата

7.4.5. Сообщение ServerHelloDone (завершение серверного этапа отправки hello-сообщений)

7.4.6. Клиентский сертификат

7.4.7. Клиентское сообщение обмена ключами (ClientKeyExchange)

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

7.4.7.2. Открытое число клиента в алгоритме Диффи-Хеллмана

7.4.8. Сообщение о проверке сертификата (CertificateVerify)

7.4.9. Сообщение Finished

8. Криптографические вычисления

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

8.1.1. Алгоритм RSA

8.1.2. Алгоритм Диффи-Хеллмана

9. Обязательные криптонаборы

10. Протокол данных приложения

11. Вопросы безопасности

12. Регистры IANA

Общая часть

Данный документ описывает версию 1.2 протокола безопасности транспортного уровня TLS (англ. Transport Layer Security). Протокол TLS обеспечивает безопасность соединения в Интернете. Протокол позволяет клиент-серверным приложениям устанавливать между собой соединение, предотвращающее перехват (англ. eavesdropping), злонамеренное использование (англ. tampering) и фальсификацию (англ. forgery) сообщения.

1. Введение

Главная задача, реализуемая протоколом TLS – обеспечение конфиденциальности (англ. privacy) и целостности данных (англ. data integrity) при соединении между двумя приложениями. Протокол состоит из двух слоев: TLS Record Protocol (протокол записи) и TLS Handshake Protocol (протокол рукопожатия) [5]. На нижнем уровне, находящемся поверх какого-либо надежного транспортного протокола (напр. TCP [TCP][6]), находится TLS Record Protocol. TLS Record Protocol обеспечивает безопасность соединения с двумя базовыми свойствами:

Соединение конфиденциально. Для шифрования данных используется симметричное шифрование (напр. AES [AES][7], RC4 [SCH][8] и т. д.). При этом для каждого соединения генерируются уникальные ключи на основе секрета, который согласовывается (англ. to negotiate) при работе другого протокола (напр. TLS Handshake Protocol). TLS Record Protocol может, также, работать и без использования шифрования.

Соединение надежно. При доставке сообщения осуществляется проверка его целостности при помощи кода утентификации сообщения[9] (далее – MAC) с использованием секретного ключа (англ. keyed MAC). Для вычисления MAC используются защищенные хеш-функции, (напр., SHA-1 и т. д.). TLS Record Protocol может функционировать и без вычисления MAC, но чаще всего используется в таком режиме только в том случае, если другой протокол использует TLS Record Protocol в качестве средства передачи (транспорта) для согласования (англ. negotiation) секретных параметров.

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

Аутентифицировать соединяющийся узел (англ. peer) возможно с использованием асимметричного шифрования (тж. шифрования на основе открытого ключа) (англ. public key cryptography) (напр. RSA [RSA][10], DSA [DSS][11] и т. д.). Такая аутентификация может быть и не обязательной, но чаще всего требуется, как минимум, для одного из соединяющихся узлов.

Согласование (англ. negotiation) общего секрета (англ. shared secret) защищено: вырабатываемый секрет[12] невозможно перехватить, и для любого аутентифицированного соединения невозможно получить секрет, даже находясь между двумя соединяющимися узлами.

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

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

1.1. Требования к терминологии

Ключевые слова и фразы интерпретируются согласно RFC 2119 [REQ]. Ключевое слово «ДОЛЖЕН» «MUST» равноценно словам «ТРЕБУЕТСЯ» «REQUIRED», «БУДЕТ» «SHALL». Ключевая фраза «НЕ ДОЛЖЕН» «MUST NOT», равноценна фразе «НЕ БУДЕТ» «SHALL NOT». Ключевое слово «НУЖНО» «SHOULD» равноценно cлову «РЕКОМЕНДУЕТСЯ» «RECOMMENDED». Ключевая фраза «НЕ НУЖНО» «SHOULD NOT» равноценна фразе «НЕ РЕКОМЕНДУЕТСЯ» «NOT RECOMMENDED». Ключевое слово «МОЖЕТ/ИМЕЕТ ВОЗМОЖНОСТЬ» «MAY» равноценно cлову «НЕ ОБЯЗАТЕЛЬНО» «OPTIONAL». (подробнее см. тж. RFC 2119 [REQ][14]).

1.2. Основные отличия от TLS 1.1

Данный документ является пересмотром протокола TLS 1.1 [TLS1.1][15], в котором улучшена гибкость, особенно в части, касающейся согласования криптографических алгоритмов. Основные изменения:

— Комбинация хеш-функций MD5/SHA-1 используемая для работы псевдослучайной функции (англ. pseudorandom function, PRF) заменена на PRF, указанную в криптонаборах ( cipher-suite-specified ). Все криптонаборы данного документа используют функцию расширенного преобразования данных (англ. data expansion function) P_SHA256 (см. Раздел 5 данного стандарта).

— Комбинация хеш-функций MD5/SHA-1 в документах, подписанных цифровой подписью заменена на вычисление одной хеш-функции (англ. single hash). Подписанные элементы ( digitally-signed ) теперь включают в себя поле, в котором явно указан используемый тип алгоритма хеширования (см. тж. Разд. 4.7 данного стандарта).

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

— Добавлена поддержка аутентифицированного шифрования с дополнительными данными (англ. Authenticated Encryption with Additional Data, AEAD) (см. Разд. 4.7, п. 6.2.3.3).

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

-В одном стандарте объединены определение расширений TLS (TLS Extensions definition) (см. п. 7.4.1.4) и AES-криптонаборы (Advanced Encryption Standard – усовершенствованные алгоритмы шифрования TLS), ранее определяемые в других документах ([TLSEXT][16] и [TLSAES][17]).

— Усилена процедура проверки номеров версий параметра EncryptedPreMasterSecret (см. п. 7.4.7.1).

Длина verify_data теперь зависит от криптонабора (по умолчанию – 12). (см. п. 7.4.7.1).

Улучшено описание защиты от атаки Бляйхенбахера/Клима (Bleichenbacher/Klima attack).

Сообщения о событиях (англ. alerts) ДОЛЖНЫ отправляться в большинстве случаев.

— После запроса сертификата ( certificate_request ) клиент ДОЛЖЕН отправлять пустой список сертификатов в том случае, если ему недоступен ни один сертификат.

— Криптонабор TLS_RSA_WITH_AES_128_CBC_SHA стал обязательным для использования при отсутствии иного в стандарте профиля приложения. (см п. 9).

— Добавлены криптонаборы HMAC-SHA256 .

— Удалены криптонаборы IDEA и DES. Они более не используются и будут опубликованы в отдельном документе.

— Поддержка обратно-совместимого с SSLv2 (SSL 2.0) сообщения «hello» теперь МОЖЕТ, а не БУДЕТ осуществляться. Поддержка, вероятно, НЕ БУДЕТ осуществляться в будущем.

— Для того, чтобы однородные case-блоки имели один и тот же код, в псевдоязык добавлено ограниченное «проваливание» (англ. fall-through). (см. тж. п. 4. 6. 1.).

— Добавлены разделы с описанием «подводных камней» при реализации протокола (англ. Implementation Pitfalls).

— Проведена редакторская работа для более ясного изложения материала.

2. Цели создания протокола

Цели разработки протокола TLS, в порядке значимости, следующие:

Криптографическая защита: TLS рекомендуется использовать для установления защищенного соединения между двумя сторонами (англ. parties).

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

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

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

3. Цели создания документа

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

Данный документ не предназначен для раскрытия каких-либо деталей определения служб (англ. service definition) или определения интерфейсов (англ. interface definition), хотя он и содержит места с описанием отдельных политик, поскольку в этом случае они требуются для поддержания устойчивой безопасности.

4. Псевдоязык

Данный документ содержит особый формат внешнего представления (англ. external representation)[18] данных. В нем используется весьма обобщенный и нестрого определенный синтаксис. Синтаксис псевдоязыка в своей структуре имеет несколько источников. Хотя в своем синтаксисе он и похож на язык «C», и на XDR [XDR][19] – в своем синтаксисе и содержимом, было бы слишком опрометчиво проводить слишком много параллелей между ними. Цель создания этого псевдоязыка – использование в документации протокола TLS; у него нет какого-либо применения, выходящего за пределы этой цели.

4.1. Базовый размер блока

Представление всех элементов данных (англ. data item) явно определено. Базовый размер блока данных – один байт (т. е. 8 бит). Элементы данных, содержащие больше одного байта (далее – мультибайтовый элемент)– являются конкатенацией байтов, слева направо, сверху вниз. Мультибайтовый элемент (числовой в следующем примере) образуется из потока байтов (в нотации языка C) следующим образом:

Такой алгоритм размещения байтов (англ. byte ordering) в мультибайтовых значениях является стандартным сетевым порядком байтов (англ. network byte order), который, также, называется форматом от старшего к младшему (англ. big-endian format, BE format).

4.2. Разное

Комментарии начинаются с символов « /* » и заканчиваются символами « */ ».

Необязательные компоненты обозначаются заключением их в двойные скобки « [[ ]] ».

Однобайтовые элементы (англ. single-byte entities), содержащие неинтерпретируемые данные, имеют непрозрачный тип данных (англ. type opaque).

4.3. Векторы

Вектор (одномерный массив) – это поток однородных элементов данных. Размер вектора может быть определен в документации, либо не определён до момента запуска приложения. В любом случае, значение длины задает количество байт, но не число элементов вектора. Синтаксис для обозначения нового вектора типа T’ , то есть вектора типа T фиксированной длины:

Здесь T’ занимает n байт в потоке данных, где n – кратно размеру T . Размер длины вектора не включается в кодированный поток.

В следующем примере Datum определен как три последовательных байта, не интерпретируемых протоколом, а Data – как три последовательных вектора Datum , которые в общей сложности, имеют длину 9 байтов:

opaque [21] Datum[3]; /* три неинтерпретируемых байта */
Datum Data[9]; /* 3 последовательных 3-байтовых вектора */

Векторы переменной длины определяются заданием поддиапазона действительных длин (англ. subrange of legal lengths) с использованием нотации <floor. ceiling> ( <низ…потолок> ). Когда поддиапазон задан, длина вектора предшествует основному содержимому вектора в байтовом потоке данных. Длина вектора задается таким типом целого числа, который может потребоваться для хранения заданного значения максимальной длины вектора (значение ceiling ( потолок )), даже если текущее значение длины можно сохранить, задав для его хранения меньшее количество байтов. Вектор переменной длины, имеющий в поле размера значение 0, рассматривается как пустой вектор.

В следующем примере mandatory – это вектор, который должен содержать от 300 до 400 байт данных непрозрачного типа. Он ни в коем случае не может быть пустым. Поле длины указанного вектора должно иметь тип uint16, занимая, таким образом 2 байта в памяти. Такой размер поля является достаточным для представления числа 400 (см. раздел 4. 4.).

С другой стороны, вектор longer может иметь размер до 800 байт, что может составить 400 элементов (блоков) типа uint16 , также он может быть пустым. Его код должен включать двухбайтовое поле со значением длины (также, типа uint16 ), которое предшествует самому вектору. Длина закодированного вектора в данном случае должна быть четным числом (например, длина вектора, имеющего тип данных uint16 , равная 17 байт, будет некорректной).

opaque mandatory<300..400>;/* поле длины занимает 2 байта, не может быть пустым */
uint16 longer<0..800>; /* от 0 до 400 беззнаковых целых чисел размером 16 бит (2 байта)*/

4.4. Числа

Базовый числовой тип данных – беззнаковый байт ( uint8 ). Все типы данных с большим размером – образуются из последовательностей байтов фиксированной длины, конкатенирующихся по правилам, указанным в разделе 4.1, и также являются беззнаковыми. Предопределены следующие числовые типы данных:

uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];

Все значения, указанные здесь или где-либо еще в спецификации – приведены в сетевом формате (от большего к меньшему) (англ. big-endian order). Число типа uint32 , представленное 4 байтами с 16-ричными значениями (hex bytes) 01 02 03 04 эквивалентно десятичному числу 16909060.

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

4.5. Перечисления (перечисленный тип)

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

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

Чтобы избежать определения излишних элементов, есть дополнительная возможность определить значение без присоединенного к нему указателя (англ. associated tag).

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

Имена элементов перечисления ограничены именами, перечисленными в его определении. В первом примере полная ссылка на второй элемент перечисления будет выглядеть как Color.blue . Такой тип ссылки не является обязательным, если цель, которой присваивается имя, правильно определена:

Color color = Color.blue; /* может использоваться, избыточно */
Color color = blue; /* корректно, неявное указание */

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

4.6. Структурированные типы (структуры)

Для удобства, можно создать типы структур из простейших типов. Каждая декларация (определение) задает новый уникальный тип. Синтаксис такой декларации в большой степени похож на синтаксис языка C:

Ссылки на поля внутри структуры могут быть даны с использованием имени его типа, при этом синтаксис будет очень похож на синтаксис ссылок на элементы перечислений. Например, T.f2 дает ссылку на второе поле предыдущей декларации. Определения (декларации) структурных типов данных могут быть встроенными (англ. embedded).

4.6.1. Варианты

Продекларированные структуры могут включать в себя варианты, выбор которых основывается на некоторых особенностях окружения. Механизм выбора вариантов (англ. selector) задается перечислением, которое определяет возможные варианты, определенные структурой. Для каждого элемента перечисления, задающего механизм выбора, должен иметься свой вариант, задаваемый оператором case (англ. case arm), внутри определения, задающего структурный тип. Варианты имеют механизм ограниченного проваливания[22]: если два варианта идут непосредственно друг за другом и не имеют полей между собой, то в этом случае оба они будут содержать одни и те же поля. Так, в нижеприведенном примере два варианта « orange » и « banana » будут содержать поле со значением V2 . Обратите внимание, что данный синтаксис является новшеством протокола TLS 1.2.

Для указания на структуру выбора вариантов к ней может быть прикреплена метка (англ. label). В псевдоязыке не представлен механизм, при помощи которого происходит выбор варианта при запуске приложения.

struct <
uint16 number;
opaque string<0..10>; /* переменная длина */
> V1;

struct <
uint32 number;
opaque string[10]; /* фиксированная длина */
> V2;

struct <
select (VariantTag) < /* неявное значение механизма выбора*/
case apple:
V1; /* VariantBody, указатель = apple */
case orange:
case banana:
V2;/* VariantBody, указатель = orange или banana */
> variant_body; /* необязательная метка структуры вариантов*/
> VariantRecord;

4.7. Криптографические атрибуты

Алгоритмом определено пять криптографических операций – цифровое подписание (англ. digital signing), потоковое шифрование (англ. stream cipher encryption), блочное шифрование (англ. block cipher encryption), аутентифицированное шифрование с дополнительными данными (англ. authenticated encryption with additional data (AEAD)), шифрование с открытым ключом (англ. public key encryption). Указанные операции имеют следующие ключевые обозначения (англ. key word designation): digitally-signed , stream-ciphered , block-ciphered , aead-ciphered , и public-key-encrypted , соответственно. Криптографическая обработка поля определяется путем прикрепления к нему спереди соответствующего ключевого обозначения, идущего перед описанием типа этого поля. На криптографические ключи влияет рабочее состояние сессии (см. Разд. 6. 1).

Элемент digitally-signed кодируется как структурированный тип (struct) DigitallySigned :

struct <
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
> DigitallySigned;

Поле algorithm описывает используемый алгоритм (см. п. 7.4.1.4.1. для подробной информации об этом поле). Обратите внимание, что введение поля algorithm является изменением по сравнению с предыдущими версиями. Поле signature – цифровая подпись, использующая указанные алгоритмы на содержимом элемента. Само содержимое этого поля находится не в сети, но вычисляется простым образом. Длина подписи определяется алгоритмом подписи и ключом.

При использовании для подписи алгоритма RSA, непрозрачный вектор содержит подпись, сгенерированную схемой RSASSA-PKCS1-v1_5 , описанной в [PKCS1][23]. В обсуждении, поднятом в [PKCS1], было условлено, что тип данных DigestInfo [24][25] должен быть закодирован с использованием отличительных правил кодирования (англ. Distinguished Encoding Rules (DER))) [X680][26] [X690][27]. Для непараметрических алгоритмов хеширования (включая SHA-1), поле DigestInfo.AlgorithmIdentifier.parameters должно содержать значение NULL , но реализуемые приложения должны работать как со значением этого поля NULL , так и, вообще, без указания параметров. Обратите внимание, что более ранние версии TLS использовали другую схему подписания на основе алгоритма RSA, которая не включала в себя использование DigestInfo .

При использовании для подписи алгоритма DSA, 20 байт хеша, полученного при помощи алгоритма SHA-1, пропускаются непосредственно через алгоритм цифрового подписания (англ. Digital Signing Algorithm (DSA)) без дополнительного хеширования. При этом рассчитывается два значения – r и s. Подпись, полученная при помощи DSA, является непрозрачным вектором, как и в случае использования RSA, содержимое которого рассчитывается при помощи DER-кодирования последовательности Dss-Sig-Value . При этом, Dss-Sig-Value выражается как:

Dss-Sig-Value ::= [28] SEQUENCE [29] <
r INTEGER,
s INTEGER,
>

Обратите внимание: в текущей терминологии аббревиатура «DSA» означает «Digital Signature Algorithm» (то есть, относится к алгоритму), в то же время аббревиатура «DSS» относится к стандарту NIST[30]. В оригинальных спецификациях TLS и SSL использовалась только аббревиатура «DSS». Данный документ для обозначения алгоритма использует аббревиатуру «DSA», а для обозначения стандарта – «DSS». В то же время использование в определениях кода аббревиатуры «DSS» сделано в целях исторической преемственности.

При потоковом шифровании криптографически защищенный генератор псевдослучайных чисел с ключом (англ. secure keyed pseudorandom number generator) генерирует последовательность, равную по размеру незашифрованному сообщению (англ. plaintext), после получают зашифрованное сообщение, применяя операцию сложения по модулю 2 (исключающего «ИЛИ») исходного сообщения и сгенерированной псевдослучайной последовательности.

При блочном шифровании каждый блок незашифрованного сообщения зашифровывается в блок шифротекста. Блочное шифрование происходит в режиме построения цепи шифроблоков (англ. Cipher Block Chaining, CBC). Размер зашифрованных, таким образом, элементов, будет кратен длине шифроблока.

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

При шифровании с открытым ключом алгоритм открытого ключа используется для шифрования данных таким образом, чтобы расшифровка могла произойти только при помощи соответствующего закрытого ключа. Элемент public-key-encrypted (зашифрованный открытым ключом) является непрозрачным вектором переменной длины <0..2^16-1> , определяемой алгоритмом шифрования и ключом.

RSA-шифрование выполняется на основе схемы RSAES-PKCS1-v1_5 , указанной в [PKCS1].

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

stream-ciphered struct <
uint8 field1;
uint8 field2;
digitally-signed opaque <
uint8 field3<0..255>;
uint8 field4;
>;
> UserType;

4.8. Константы

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

Неопределенным типам (непрозрачным (англ. opaque), векторам переменной длины, структурам, содержащим непрозрачный тип) не могут присваиваться значения. Ни одно из полей мульти-элементной структуры или вектора не может быть пропущено.

struct <
uint8 f1;
uint8 f2;
> Example1;

Таким образом, структура типа Example1 будет содержать два поля f1 и f2 со значениями 1 и 4, соответственно.

5. HMAC и псевдослучайная функция

Для защиты целостности сообщений слой записи TLS (англ. TLS record layer) использует MAC с ключом (англ. keyed MAC). Шифронаборы (тж. криптонаборы) (англ. cipher suites), определенные в этом документе, используют конструкцию, известную как HMAC, в которой происходит хеширование MAC-аутентификатора, описанную в [HMAC][31]. При необходимости другие криптонаборы могут определять свои собственные MAC-конструкции.

В добавок к этому, этой конструкции требуется расширенное преобразование (англ. expansion) секретов в блоки данных для целей генерации либо валидации ключа. Данная псевдослучайная функция (англ. Pseudo Random Function (PRF)) в качестве входных данных берет секрет, свое начальное значение (тж. затравка) (англ. seed), метку идентификации (англ. identifying label, label) и выдает данные произвольной длины.

В данном разделе мы определяем только одну PRF, которая основана на алгоритме HMAC. Данная функция, работающая в связке с хеш-функцией SHA-256, используется для всех криптонаборов, определенных в этом документе, а также в других документах, касающихся протокола TLS 1.2, опубликованных ранее этого документа. Новые криптонаборы должны явно определять PRF и, в общем случае, должны использовать для протокола TLS PRF с хеш-функцией SHA-256, либо с более сильным стандартом хеширования.

Для начала определим функцию расширенного преобразования данных (англ. data expansion function) P_hash(secret, data) , которая использует одну хеш-функцию для преобразования секрета и начального значения в выходные данные произвольного размера:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + .

где «+» означает конкатенацию.

A() определяется как:

A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))

Функция P_hash может иметь столько итераций, сколько это необходимо для выдачи требуемого количества данных. Например, если P_SHA256 используется для создания 80 байт данных, то необходимо будет произвести три итерации функции (до A(3) включительно), создав 96 байт выходных данных; последние 16 байтов финальной итерации будут отброшены, оставив 80 байт выходных данных.

PRF для целей протокола TLS создается путем применения функции P_hash с секретом в качестве ее аргумента:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)

Метка (англ. label) является ASCII-строкой. Ее следует включать в функцию в точной форме, в которой она была взята, без байта длины, а также не перенося нулевой символ (англ. null character). Например, метка «slithy toves», до начала обработки функцией хеширования будет выглядеть как:

73 [32] 6C 69 74 68 79 20 74 6F 76 65 73

[1] Клиентские и серверные сообщения «hello» рассмотрены в п. 7.4.1 данного стандарта (Прим. перев.).

[2] Хотя в некоторых русскоязычных источниках слово «deprecating» дается в переводе «устаревание», автору перевода наиболее подходящим видится термин «прекращение использования», поскольку для термина «устаревший» в английском языке используется слово «obsolete» (Прим. перев.).

[3] Клиентское сообщение об обмене ключами (Client Key Exchange Message) содержит начальный ключ (англ. premaster key) после чего псевдослучайная функция вычисляет основной ключ (англ. master key) (подробнее см. разделы 7.4.7 и 8.1 спецификации протокола TLS 1.2) (Прим. перев.).

[4] Регистры IANA для TLS разделены на две части: Transport Layer Security (TLS) Parameters (Параметры TLS) и Transport Layer Security (TLS) Extensions (Расширения TLS) (Прим. перев.).

[5] Протокол рукопожатия также можно назвать протоколом согласования параметров. Но поскольку для термина «согласование параметров» в английском языке имеется слово «negotiation», был оставлен используемый в официальном документе для обозначения данного уровня протокола TLS сленговый термин «рукопожатие» (англ. handshake) (Прим. перев.).

[6] Postel, J., «Transmission Control Protocol«, STD 7, RFC 793, September 1981.

[7] National Institute of Standards and Technology,»Specification for the Advanced Encryption Standard (AES)» FIPS 197. November 26, 2001.

[8] B. Schneier. «Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.», Published by John Wiley & Sons, Inc. 1996.

[9] В русскоязычной источниках также используется термин «имитовставка».(Прим. перев.).

[10] R. Rivest, A. Shamir, and L. M. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems«, Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

[11] NIST FIPS PUB 186-2, «Digital Signature Standard«, National Institute of Standards and Technology, U.S. Department of Commerce, 2000. — На август 2021 года указанный стандарт является недействующим. Действующий стандарт — NIST FIPS 186-4, «Digital Signature Standard», National Institute of Standards and Technology, U.S. Department of Commerce, 2013 (Прим. перев.).

[12] Также можно употребить термин «секретный ключ».(Прим. перев.).

[13] Как было сказано в предисловии, в сентябре 2015 года вышел RFC 7627, который направлен на устранение уязвимости от атаки «man-in-the-middle», в которой злоумышленник устанавливает две сессии с клиентом и сервером, используя один и тот же секрет (секретный ключ). (Прим. перев.).

[14] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels«, BCP 14, RFC 2119, March 1997.

[15] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1«, RFC 4346, April 2006.

[16] Eastlake, D., 3rd, «Transport Layer Security (TLS) Extensions: Extension Definitions«, Work in Progress, February 2008. – На август 2021 года актуальной версией является: Eastlake, D., 3rd, «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011 (Прим. перев.). – Поддерживаемые IANA расширения TLS также приведены в разделе регистров Transport Layer Security (TLS) Extensions. (Прим. перев.).

[17] Chown, P., «Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)«, RFC 3268, June 2002.

[18] Внешнее представление (англ. external representation) является англоязычным термином для структурированного представления данных и информации, включающего как формальные структуры, так и и наглядный материал (графики, схемы, иллюстрации). Данный термин в англоязычной литературе противопоставляется внутреннему представлению данных (internal representation) или, также, промежуточному представлению (intermediate representation), обозначающему структуры данных или код, используемые компилятором или виртуальной машиной для представления исходного кода. (Прим. перев.).

[19] Eisler, M., Ed., «XDR: External Data Representation Standard«, STD 67, RFC 4506, May 2006.

[20] << — оператор побитового сдвига влево. (Прим. перев.).

[21] Opaque – непрозрачный тип данных. См. тж. раздел 4. 2 (Прим. перев.).

[22] Проваливанием (англ. fall-through) в языках С/C++ называется ситуация, когда в блоке case оператора передачи управления switch отсутствует служебное слово brake . До стандарта C++17 компилятор в этом случае выдал бы сообщение об ошибке проваливания. (Прим. перев.).

[23] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1«, RFC 3447, February 2003.

[24] О синтаксисе типа DigestInfo см. раздел A.2.4 RFC 3447 [PKCS1] (Прим. перев.).

[25] Результат преобразования данных хеш-функцией в английском языке может обозначаться термином «digest», что в русскоязычной литературе может переводиться как «сводка сообщения». (Прим. перев.).

[26] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation.

Российский аналог — ГОСТ Р ИСО/МЭК 8824-1-2001. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации. (Прим. перев.).

[27] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

Российский аналог — ГОСТ Р ИСО/МЭК 8825-1-2003 Информационная технология. Правила кодирования ACH.1. Часть 1. Спецификация базовых (BER), канонических (СER) и отличительных (DER) правил кодирования.

[28] ::= — символ определения в форме нотации Бэкуса-Наура. (Прим. перев.).

[29] Sequence (англ.) – последовательность. В информатике – порядок действий, задаваемых алгоритмом. Таким образом, Dss-Sig-Value является последовательным вычислением значений r и s .

[30] NIST — The National Institute of Standards and Technology, Национальный институт стандартов и технологии (США). (Прим. перев.).

[31] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication«, RFC 2104, February 1997.

[32] 73 – ASCII-код в 16-ричном формате для символа «s» и т. д. (Прим. перев.).

Протокол TLS: что это, зачем нужен и как работает

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

Иллюстрация: Оля Ежак для Skillbox Media

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

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

Из этой статьи вы узнаете:

Что такое TLS

TLS, или transport layer security, — это протокол, который защищает данные во время их передачи по Сети. Он работает на четвёртом, транспортном, уровне сетевой модели OSI, где отвечает за создание безопасных сессий обмена данными между браузером и сервером.

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

Аббревиатура HTTPS означает, что сайт использует защищённую версию протокола HTTP — Hypertext Transfer Protocol Secure. По сути, это и есть обычный HTTP, только нашпигованный средствами защиты, за которые как раз и отвечает TLS.

Чтобы понять, как работает TLS, проведём аналогию с фильмом «Чёрная пантера». Если помните, у вакандийцев есть два характерных атрибута коммуникации. Во-первых, это фирменные приветствия со скрещёнными на груди руками, которые позволяют им узнавать друг друга. А во-вторых, конечно, вакандийский язык, понятный в основном жителям этой страны.

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

Дальше в статье мы подробнее разберём процесс рукопожатия и обмена сообщениями в TLS — но перед этим обсудим ещё одну важную тему.

В чём разница между SSL и TLS

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

Протокол SSL разработала компания Netscape в середине 1990-х, чтобы улучшить свой браузер Navigator (олды помнят). Для своей эпохи SSL был вполне хорош, но со временем в его безопасности нашлись серьёзные бреши. Одной из самых критичных стала небезопасная проверка паддинга.

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

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

Чтобы лучше понять, как это работает, представьте, что вы пытаетесь угадать чей-то пароль. Но вместо обычного «пароль неверный» система говорит вам ещё и о том, что он слишком длинный или в нём нет каких-то символов. Тем самым система помогает хакеру сузить количество вариантов «паролей».

Исправить эту уязвимость одними обновлениями было невозможно — она была связана с самим дизайном SSL, а не конкретными реализациями. Именно из-за подобных проблем, а также из-за банкротства Netscape, разработка перешла в так называемый Инженерный совет интернета — IETF. Там протокол улучшили, исправили косяки безопасности и выпустили под новым названием — TLS.

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

Сегодня протокол SSL считается устаревшим — использовать его не рекомендуется из-за вышеуказанных проблем. Однако термины SSL и TLS до сих пор часто путают и используют как синонимы. Но теперь вы знаете, как всё обстоит на самом деле, и можете помочь «распутаться» окружающим.

Как TLS шифрует данные

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

Вашими молитвами только и живём, дорогой Игорь Николаевич!

Совсем не ограничиваем себя.

Если урожай хороший народится — доведём мельницу до порядку.

Покуда в Петербурге гуляния, уж дайте себе волю.

Любуйтесь красотами и с людьми знакомьтесь.

О нас не беспокойтесь, Бог даст — Тверь не пропадёт.

Хорошо живём, ни на что не жалуемся.

Ответа скорого не ждём, но пишите уж по возможности.

В реальности ключи, конечно, намного сложнее, но смысл тот же — подсказка для правильного чтения.

В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.

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

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

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

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

Помимо шифрования в TLS используется несколько алгоритмов хеширования.

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

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

На сайте wtools.io можно сделать хеш из любого текста — мы, например, захешировали текст этой статьи:

Основной алгоритм хеширования в TLS — это SHA на 256, 512 или 384 бит. Использование MD5 и SHA-1 не рекомендуется — с современными мощностями их слишком легко взломать обычным перебором.

Основные алгоритмы шифрования в TLS

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

AES (Advanced Encryption Standard). Симметричный алгоритм шифрования, использующий для защиты данных ключи длиной от 128 до 256 бит. Чем длиннее ключ, тем выше защита, но ниже производительность.

3DES (Triple Data Encryption Standard). Чуть менее безопасный алгоритм. Он делает то же самое, что и AES, но тремя разными ключами. Это как если бы вы спрятали свои данные в коробку, эту коробку в другую коробку, а её в свою очередь убрали в третью коробку. Получается сложная конструкция из коробок, которая не даёт посторонним людям узнать, что внутри.

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

Как работает TLS

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

Допустим, вы заходите на сайт Skillbox Media, чтобы почитать статью про ИИ общего назначения. На этом этапе ни ваш браузер, ни сервер ещё ничего друг о друге не знают. Чтобы исправить эту ситуацию, начинает свою работу протокол рукопожатия (handshake protocol). Вот из каких этапов состоит процесс его исполнения:

Приветствие

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

Обмен ключами

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

Завершение рукопожатия

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

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

Фрагментация

Данные разбиваются на фрагменты меньшего размера для последующего шифрования.

Компрессия

Данные сжимаются, их объём уменьшается (если применяется сжатие).

Шифрование

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

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

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

Передача данных

Зашифрованные и аутентифицированные фрагменты данных передаются по Сети между клиентом и сервером.

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

Что такое механизм возобновления сессий

Чтобы ускорить обмен сообщениями, разработчики добавили в TLS механизм возобновления сессий — 0-RTT (zero round trip time resumption, нулевое время приёма-передачи). Он позволяет клиенту и серверу возобновить сессию, если она почему-то была прервана — например, из-за ошибки сети или бага на стороне сервера.

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

На первый взгляд, выглядит круто — но есть у этого механизма и недостатки:

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

❌ «Перегрузка» токенами. Если сервер обслуживает сайт с миллионами пользователей, хранить в памяти токены каждой сессии может быть проблематично. К счастью, на этот случай придумали механизм session ticket, который позволяет серверу «не держать всё в себе».

❌ Ограниченные динамические параметры. Динамические параметры — это своего рода условные знаки, которые стороны используют во время сессии, чтобы подтвердить, что они — это всё ещё они. В механизме 0-RTT эти параметры используются реже, чем в обычном режиме.

❌ Задержки в ответах. В рамках сессии 0-RTT клиент отправляет порцию данных на сервер до того, как получит ответ о «доставке» предыдущей. Это может привести к рассинхрону между сервером и клиентом — клиент может отправить несколько запросов до того, как получит ответ на первый.

Защита от атак типа man-in-the-middle

Атака типа man-in-the-middle («человек посередине») — одна из частых угроз безопасности в сетевых коммуникациях. Так называют ситуацию, когда злоумышленник внедряется в коммуникационный канал между клиентом и сервером, перехватывает и модифицирует передаваемые данные.

В TLS есть механизмы для защиты от таких атак:

• Шифрование данных. Самый очевидный пункт: протокол TLS обеспечивает шифрование данных, что делает их непригодными для прослушивания или изменения злоумышленником.
• Аутентификация сервера. Клиент проверяет подлинность сайта при помощи публичного ключа и убеждается, что связывается с нужным сервером, а не с посредником. Если сертификат не проходит проверку или отсутствует, клиент может предупредить о потенциальной атаке.
• Аутентификация клиента. В некоторых случаях, когда требуется двусторонняя аутентификация, клиент предоставляет свой собственный сертификат серверу. Сервер может проверить этот сертификат и убедиться в подлинности клиента.
• Обмен ключами по протоколу Диффи — Хеллмана. Протокол TLS позволяет клиенту и серверу согласовать общий секретный ключ с помощью протокола Диффи — Хеллмана.
• Цифровая подпись. В протоколе TLS используют цифровые подписи для проверки подлинности и целостности передаваемых данных. Цифровая подпись гарантирует, что данные не были изменены в процессе передачи.

Конечно, совершенных средств защиты нет нигде, кроме… ну, может быть, Форт-Нокса или бункера Бэтмена. Атаки типа «человек посередине» периодически случаются даже с таким навороченным протоколом, как TLS, особенно если уделить не слишком много времени его настройке.

Версии TLS: чем различаются и какую использовать

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

Давайте посмотрим, как менялся протокол TLS и какие фишки в нём появлялись от версии к версии.

TLS 1.0 (1999 год)

Что изменилось (по сравнению с SSL 3.0):

• Добавлены новые функции, используемые для генерации ключей и вычисления MAC (message authentication code).
• Изменены форматы сообщений, завершающих рукопожатие (finished messages).
• Появились новые коды ошибок (alerts).
• Добавлена обязательная поддержка протокола Диффи — Хеллмана.

TLS 1.1 (2006 год)

Что изменилось:

• Произведена замена уязвимых алгоритмов хеширования MD5 и SHA-1 на более безопасные, такие как SHA-256.
• Внедрены продвинутые алгоритмы шифрования, такие как AES и Camellia.
• Добавлена защита от атак на паддинг с помощью генерации случайных чисел.
• Улучшена защита от атак с использованием цепочки блоков шифрования (CBC).

TLS 1.2 (2008 год)

Что изменилось:

• Добавлены новые алгоритмы шифрования, такие как AES-GCM (Advanced Encryption Standard — Galois/Counter Mode).
• Улучшена проверка целостности данных и аутентификации.
• Добавлены расширения, позволяющие клиенту и серверу согласовывать поддерживаемые функции и параметры.

TLS 1.3 (2018 год)

Что изменилось:

• Добавлен механизм возобновления сессий RTT (0-RTT), о котором мы подробно рассказывали чуть выше.
• Сократилось время установки соединения благодаря оптимизации протокола рукопожатия.
• Удалены устаревшие и уязвимые функции: алгоритмы шифрования на основе CBC, проверка подписи на основе RSA/DSA и другие.
• У клиента появилась возможность отправлять данные без ожидания подтверждения от сервера.

Уязвимости протокола TLS

Абсолютной защиты данных не существует. Как и у любой технологии, у TLS есть свои уязвимости:

• Атаки на слабые алгоритмы шифрования в старых версиях TLS. Вычислительные мощности сегодняшних компьютеров позволяют относительно легко взломать алгоритмы шифрования, которые какое-то время назад считались неприступными. Используйте современные алгоритмы шифрования.
• Уязвимости в реализации и настройке. Использование сторонних библиотек, попустительское отношение к проверкам сертификатов и обновлениям снижает защиту ваших данных.
• Социальная инженерия и фишинг. Даже с последней корректно настроенной версией TLS не нарушайте правила безопасности в Сети — не переходите по подозрительным ссылкам и не оставляйте конфиденциальные данные там, откуда их могут извлечь злоумышленники.
• Утечка информации и анализ трафика. Использование одних и тех же логина и пароля может скомпрометировать безопасность ваших данных.
• Уязвимости в ОС. Отключённый файрвол и пренебрежение обновлениями операционной системы сделают ваши данные уязвимыми.

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

• Улучшенная криптография. Современные алгоритмы шифрования и хеширования, которые обеспечивают более надёжную защиту данных и устойчивость к известным атакам.
• Изъятие слабых алгоритмов шифрования, таких как MD5 и SHA-1, для уменьшения рисков, связанных с их использованием.
• Обновлённый процесс установки соединения. В последней версии оптимизировали установку соединения, чтобы сократить обмен сообщениями и улучшить производительность.
• Прямая секретность (forward secrecy). Даже если долгосрочные ключи сервера или клиента скомпрометированы, предыдущие сессии останутся защищёнными.
• Улучшенная защита от атак типа MITM. Четвёртая версия протокола TLS включает ряд изменений для повышения защиты от атак MITM, таких как более строгая проверка сертификатов и использование надёжных алгоритмов аутентификации.

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

Рекомендации: как обеспечить безопасность TLS

Напоследок — несколько советов для сетевиков и администраторов сайтов о том, как правильно использовать протокол TLS, чтобы добиться максимальной безопасности своих ресурсов:

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

Безопасность транспортного уровня (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 был 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 году. Она включала поддержку аутентифицированных шифровальных шифров, ряд изменений в том, как использовались хэш-функции, и много других улучшений..

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

TLS 1.0 и 1.1 теперь объявлены устаревшими в 2023 году, но версия 1.2 широко используется. Версия 1.3 начинает расширяться.

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

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

Диаграмма, показывающая стек TLS. Стек протокола TLS Джеффрейтеджосукмоно. Лицензировано под CC0.

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

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

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

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

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

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

Основное рукопожатие TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

компрессия

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

набивка

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

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

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

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

TLS & модель OSI

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

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

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

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

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

Он может защищать протоколы, такие как HTTP, SMTP, FTP, XMPP и NNTP, а также другие. Самым распространенным приложением является протокол Hypertext Transfer Protocol Secure (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 году было обнаружено, что это может быть использовано злоумышленниками, чтобы они могли вводить трафик, чтобы он выглядел так, как будто он исходит от клиента. Серверы примут запрос как законный, что означает, что злоумышленники потенциально могут манипулировать исходящими сообщениями.

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

BEAST

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

Сроки атаки

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

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

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

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

Понижение атаки

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

Heartbleed

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

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

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

тонуть

Атака «Расшифровка RSA с устаревшим и ослабленным шифрованием» (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 по лицензии СС0