Протокол TLS

Обзор протокола диалога

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

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

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

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

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

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

Протокол TLS является безопасным, и любой шифровой набор предлагает свой уровень безопасности. Если вы согласуете использование 3DES с 1024-битовым RSA -ключом при связи с ЭВМ, чей сертификат вы проверили, вы можете быть уверены в безопасности. Однако вы никогда не должны посылать данные по каналу, где применяется 40-битовая шифрование, если только вы не уверены, что данные не стоят того, чтобы кто-то тратил силы на их дешифрование.

Эти цели достигаются протоколом диалога, который может быть суммирован следующим образом. Клиент посылает сообщение hello, на которое сервер должен также откликнуться сообщением hello, в противном случае возникает ситуация фатальной ошибки и соединение разрывается. Сообщения client hello и server hello используются для установления более безопасного взаимодействия клиента и сервера. Сообщения client hello и server hello устанавливают следующие атрибуты: версия протокола, ID-сессии, шифровой набор и метод сжатия. Кроме того, партнеры генерируют и пересылают друг другу два случайных числа: ClientHello.random и ServerHello.random.

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

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

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

Рис. 16.1. Обмен сообщениями в процессе диалога

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

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

Клиент посылает ClientHello, используя ID-сессии, которая должна быть возобновлена. Сервер проверяет свой кэш сессий на соответствие. Если соответствие имеется, а сервер желает возобновить соединение со специфицированным состоянием сессии, он посылает ServerHello с тем же значением ID-сессии. В этой точке как клиент, так и сервер должны послать сообщения об изменении шифровой спецификации, после чего перейти к завершающим сообщениям finished. Раз восстановление сессии завершилось, клиент и сервер могут начать обмен прикладными данными. (Смотри диаграмму на рис. 16.2.) Если соответствия с ID-сессии не найдено, сервер генерирует новый ID сессии, а клиент TLS и сервер осуществляют полный диалог.

Рис. 16.2. Обмен сообщениями для упрощенного диалога