Шифрование данных TLS

Защищенная передача данных по TLS

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

TLS-протокол основан на протоколе Netscape SSL версии 3.0 и состоит из двух частей — TLS Record Protocol и TLS Handshake Protocol. Различие между SSL 3.0 и TLS 1.0 незначительные, поэтому далее в тексте термин «SSL» будет относиться к ним обоим.

TLS Working Group, основанная в 1996 году, продолжает работу над протоколом. TLS предоставляет возможности аутентификации и безопасной передачи данных через Интернет с использованием криптографических средств. Часто происходит лишь аутентификация сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих сообщений и создания поддельных.

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

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

Handshake в деталях

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

Ниже описан простой пример установления соединения:
-Клиент посылает сообщение ClientHello, указывая наиболее последнюю версию поддерживаемого TLS протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS.
-Сервер отвечает сообщением ServerHello, содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом.
-Сервер посылает сообщение Certificate, которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен)
-Сервер может запросить сертификат у клиента, в таком случае соединение будет взаимно аутентифицировано.
-Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание handshake.
-Клиент отвечает сообщением ClientKeyExchange, которое содержит PreMasterSecret открытый ключ, или ничего (опять же зависит от алгоритма шифрования).
-Клиент и сервер, используя PreMasterSecret ключ и случайно сгенерированные числа, вычисляют общий секретный ключ. Вся остальная информация о ключе будет получена из общего секретного ключа (и сгенерированных клиентом и сервером случайных значений).
-Клиент посылает ChangeCipherSpec сообщение, которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе handshake алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22.
-Клиент посылает сообщение Finished, которое содержит хеш и MAC (код аутентификации сообщения), сгенерированные на основе предыдущих сообщений handshake.
-Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удается, handshake считается неудавшимся и соединение должно быть оборвано.
-Сервер посылает ChangeCipherSpec и зашифрованное Finished сообщение и в свою очередь клиент тоже выполняет расшифровку и проверку.

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

Защищенный обмен данными TLS

Защищенная передача данных по TLS

Handshake в деталях