Безопасное сетевое взаимодействие (часть 2)

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

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

Протокол Рукопожатия включает следующие шаги:

1. Обмен сообщениями Hello для согласования алгоритмов, обмен случайными значениями и проверка возобновляемости сессии.
2. Обмен необходимыми криптографическими параметрами, которые позволяют клиенту и серверу согласовать премастер-секрет (клиент посылает премастер-секрет серверу).
3. Обмен сертификатами и криптографической информацией, что позволяет клиенту и серверу аутентифицировать друг друга.
4. Предоставление параметров безопасности на уровень Записи.
5. Возможность клиенту и серверу проверить, что они вычислили одни и те же параметры безопасности и что Рукопожатие произошло без вмешательства злоумышленника.

Заметим, что протоколы более высокого уровня всегда должны считать, что TLS выберет наиболее сильное соединение между двумя участниками. Протокол разработан для минимизации риска атак типа встреча посередине, но защита от атак, при которых злоумышленник может блокировать доступ к порту, где функционирует сервис безопасности, и попытаться стать участником переговоров аутентифицированного соединения, не предусмотрена. Фундаментальное правило состоит в том, что протоколы более высокого уровня должны учитывать свои требования к безопасности и никогда не передавать информацию по менее безопасному каналу, чем требуется. Протокол TLS является безопасным, и выбранный набор алгоритмов обеспечивает соответствующий уровень безопасности. Например, если в результате переговоров были выбраны 3DES, 1024-битный ключ RSA и сертификат сервера проверен, соединение можно считать безопасным.

Данные цели достигаются протоколом Рукопожатия, который можно просуммировать следующим образом. Клиент посылает сообщение Client Hello, на которое сервер должен ответить сообщением Server Hello или фатальной ошибкой и прерыванием соединения. Client Hello и Server Hello используются для определения максимального уровня безопасности между клиентом и сервером. Client Hello и Server Hello устанавливают следующие атрибуты: Protocol Version, Session ID, Cipher Suite и Compression Method. Дополнительно создаются и передаются два случайных значения: ClientHello.random и ServerHello.random.

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

После сообщений Hello сервер посылает сертификат для аутентификации. Дополнительно может быть послано сообщение обмена ключа сервера, если сервер не имеет сертификата или его сертификат служит только для подписи. Если сервер аутентифицирован, он может запросить сертификат клиента, если того требует установленная политика безопасности. Теперь сервер посылает сообщение Server Hello Done, указывающее на то, что фаза Hello -сообщений Рукопожатия завершена. Затем сервер ждет ответа клиента. Если сервер послал сообщение запроса сертификата, клиент должен послать сообщение Certificate. После этого посылается сообщение обмена ключа клиента, содержимое этого сообщения зависит от выбранного алгоритма открытого ключа в сообщениях Client Hello и Server Hello. Если клиент имеет сертификат для подписывания, то посылается сообщение цифровой подписи для явной проверки всех сообщений Рукопожатия.

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

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

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

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

Поток сообщений при сокращенном Рукопожатии

Рассмотрим в деталях каждое сообщение протокола Рукопожатия.

Последовательность сообщений при полном Рукопожатии

Клиент		Сервер
ClientHello
		ServerHello
		Certificate *
		ServerKeyExchange *
		CertificateRequest *
		ServerHelloDone
Certificate *
ClientKeyExchange
CertificateVerify *
[ ChangeCipherSpec ]
Finished
		[ChangeCipherSpec ]
		Finished
Прикладные данные		Прикладные данные