Шифрование трафика
Простой способом зашифровать данные, передаваемые по сети - это протоколы SSL и TLS. Они расположены на уровне представления (presentation) данных, на 6-ом уровне модели протокола TCP / IP, что позволяет без проблем использовать их для прикладных протоколов 7го уровня (HTTP, WebSocket, ...).
SSL / TLS используют комбинацию технологий симметричного и асимметричного шифрования. На этапе установления соединения (handshake) используется асимметричное шифрование. Также, оно используется для проверки подлинности. Для передачи данных используется симметричное шифрование. TLS позволяет убедиться в целостности данных и аутентифицировать отправителя.
Преимущества SSL / TLS:
- Конфиденциальность - данные передаются в зашифрованном виде, что делает бессмысленным их перехват.
- Целостность - исключается подмена или порча передаваемой информации.
- Аутентификация - проверка подлинности передающего и принимающего. Нельзя выдать себя за другого и подменить данные.
Протокол Диффи-Хеллмана
Симметричное шифров ание имеет преимущество в скорости перед ассиметричным, поэтому именно оно используется в SSL / TLS для шифрования трафика.
Протокол Диффи-Хеллмана позволяет клиенту и серверу сгенерировать симметричные ключи шифрования через открытый канал связи.
Идея протокола Диффи-Хеллмана:
Клиент и сервер генерируют собственные (локальные) секреты. Для алгоритма используется однонаправленная функция для которой легко вычислить значение и проблематично вычислить аргументы по значению. Клиент и сервер передают по открытому каналу друг другу значения функции от секретных аргументов. Проводят над этими значениями и аргументами собственные вычисления и, в результате применения некоторых преобразований, могут прийти к одному и тому же значению.
Перехват промежуточных значений и знание алгоритма без локального секрета не даст возможности восстановить результат.
Важно: В процессе установления соединения клиент (как и сервер) может передать ключ шифрования и с использованием ассиметричного шифрования. Такая возможность есть. Но это не безопасный способ обменяться симмет ричными ключами, так как при компрометации приватного ключа ассиметричного алгоритма - становится возможным расшифровать сообщение содержащее ключ шифрования трафика. Протокол Диффи-Хеллмана решает проблему создания сессионного ключа через открытый канал связи.
SSL
SSL (Secure Sockets Layer) - протокол передачи данных, обеспечивающий шифрование, защиту и аутентификацию.
Не будем останавливаться на нем подробно, так как его можно считать устаревшим начиная с 1999 года, когда появился TLS 1.0. В настоящее время, если кто-то говорит про SSL, то это, скорее всего, TLS. Часто используется термин SSL для обозначения сертификатов TLS.
SSL был медленным и менее безопасным чем современный TLS. На этапе установления соединения требовал больше активности между клиентом и сервером. Содержал не стойкие алгоритмы шифрования.
TLS
TLS – прямой преемник SSL.
Основная цель TLS заключалась в том, чтобы сделать SSL более безопасным, а спецификации протокола более точными и полными.
TLS предполагает, что между узлами установлено надёжное соединение, протокол не поддерживает повторную отправку потерянных пакетов данных. Но существует DTLS для работы в условиях негарантированной доставки.
Отличия TLS от SSL:
- рукопожатие (handshake). Это процесс аутентификации сертификата, т.е. процесс в ходе которого каждая из сторон удостоверяется в том, что противоположная сторона является той за кого себя выдает. В TLS ускорили процесс рукопожатия, устранив дополнительные шаги.
- оповещения – это способ передачи сообщений об ошибках. В TLS оповещений больше и они зашифрованы.
- аутентификация сообщений - для проверки подлинности и целостности сообщения используются коды аутентификации сообщений (MAC или message authentication code). SSL использует устаревший MD5, TLS использует HMAC.
- наборы шифров - набор алгоритмов, создающих ключи для шифрования информации. Обычно это: алгоритм обмена ключами, алгоритм проверки, алгоритм массового шифрования и алгоритм MAC. В TLS используются современные алгоритмы.
TLS 1.0 и TLS 1.1 - уже устаревшие версии TLS.
не следует доверять TLS и связанным технологиям свою жизнь или жизнь других людей
Сертификаты
TLS-сертификат - это важнейший компонент в TLS.
Сертификат содержит открытый ключ сервера для сервера и открытый ключ клиента для клиента. Дополнительно к публичному ключу в сертификат включается подпись, сделанная промежуточным сертификатом (приватным ключом) выше уровня. Они используются на этапе установления соединения, чтобы проверить подлинность друг друга и безопасно обменяться ключами для дальнейшей работы.
Проверка подлинности сертификата. Аутентификация узлов.
В TLS возможна обоюдная (двухсторонняя) аутентификация узлов, использующая TLS-сертификаты.
Сервер может указать клиенту имена удостоверяющих центров, ключи которых сервер будет использовать для проверки клиентского сертификата.
Цепочка сертификатов - это несколько TLS-сертификатов, среди которых один серверный сертификат, один "корневой сертификат" и "промежуточные сертификаты".
Серверный сертификат - это сертификат, который по имени соответствует серверу и содержит серверный открытый ключ электронной подписи (в большинстве случаев - RSA или ECDSA).
Корневые сертификаты - это сертификат удостоверяющего центра.
Сервер или клиент может предоставить цепочку сертификатов, каждый из них подписан вышестоящим центром:
"сертификат сервера" --подписан в X-->
"промежуточные сертификаты X" --подписан в Y-->
"промежуточные сертификаты Y" --подписан Z-->
"корневой сертификат Z"
Правильные/валидные подписи сертификатов всей цепочки подтверждают подлинность сертификата сервера.
TLS 1.3
Рукопожатие (handshake)
Рукопожатие (handshake) - это самый важный этап, который следует сразу за tcp handshake. В процессе рукопожатия клиент и сервер договариваются об используемых шифрах, методах аутентификации и симметричных ключах шифрования.
Практически сразу, еще до окончания рукопожатия клиент и сервер переходят на зашифрованный обмен:
Если рассматривать этот процесс не углубляясь в детали, то мы имеем:
1. выработка начального значения общего криптографического секрета
Клиент передает на сервер приветствие, настройки сессии и секрет (handshake_traffic_secret) для генерации набор симметричных ключей (для клиента и сервера), которые будут использоваться для шифрования сообщений рукопожатия.
2. определение параметров соединения
Сервер передает клиенту настройки сессии (ServerHello). Это последнее сообщение, которое передается без шифрования. Далее весь обмен будет зашифрован.
В зашифрованном виде сервер передает клиенты свою цепочку сертификатов и если требуется, то запрос клиентского сертификата.
Важно: ответ сервера зашифрован с помощью набор симметричных ключей сгенерированного на основе handshake_traffic_secret и предыдущих сообщений.
Важно: так как ответ сервера зашифрован, то нельзя узнать какой сертификат сервер передал клиенту и передал ли его вообще.
3. аутентификация (сервера и клиента)
Последним эт апом клиент и сервер удостоверяются что собеседник является тем за кого себя выдает.
Симметричные ключи генерируются по протоколу Диффи-Хеллмана на основе локального секрета, сообщений которые были переданы до момента создания ключа и handshake_traffic_secret.
В TLS 1.3 используются симметричные ключи разных уровней для разных этапов: handshake, трафик и т.п. Каждый следующий ключ вычисляется на основе предыдущего ключа и дополнительных данных.
Полная схема установки соединения для TLS 1.3:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
здесь:
'*' необязательные сообщения (передаются в зависимости от контекста)
фигурные скобки - сообщения Handshake. передаются в зашифрованном виде
квадратные скобки - данные полезной нагрузки. передаются в зашифрованном виде, но с использованием другого набора ключей шифрования.
TLS 1.3 позволяет реализовать обоюдную (двухсторонную) аутентификацию. Для этого сервер передает CertificateRequest, сообщая клиенту, что он должен предоставить сертификат для проверки. CertificateVerify - подписанное клиентом сообщение. Проверив подпись по сертификату клиента (публичному ключу) можно убедиться, что клиент обладает приватной частью ключа.
Сокращённый вариант установления соединения. 0-RTT
Сокращённая схема предусмотрена для уменьшения потери времени на установление соединения.
0-RTT (Zero Round-Trip Time) - нулевая задержка приёма-передачи.
Работает только если клиент и сервер уже имеют общий секрет. Имея общий секрет, клиент отправляет его на первом этапе (п.1 см. выше) вместе с остальными данными и сразу (до ответа сервера) передает данные приложения. Сервер отвечает (п.2 см. выше) и сразу передает ответ приложения.
Такой подход вносит минимальные задержки, но менее безопасен.
Из-за того, что клиент должен хранит общий секрет, то при компрометации общего секрета первый запрос клиент к серверу может быть расшифрован. Стоит отметить, что ответ сервера и все остальные запросы и ответы будут шифроваться надежными ключами.