Московский государственный университет имени М.В.Ломоносова
Опубликован: 28.11.2014 | Доступ: свободный | Студентов: 1150 / 81 | Длительность: 23:26:00
ISBN: 978-5-9556-0163-2
Лекция 11:

Протокол SSL/TLS

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

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

В результате выполнения протокола Рукопожатия будут созданы следующие элементы сессии:

Таблица 11.1.
Идентификатор сессии Произвольная последовательность байтов, выбираемая сервером для идентификации активного или возобновляемого состояния сессии.
Сертификат участника Х.509 v3 сертификат участника. Этот элемент может быть нулевым.
Метод сжатия Алгоритм, используемый для сжатия данных перед шифрованием.
Набор алгоритмов Алгоритм симметричного шифрования данных (например, NULL, DES, AES и т.д.), МАС-алгоритм (такой как MD5 или SHA-1) и параметры этих алгоритмов.
Мастер-секрет 48-байтный секрет, разделяемый клиентом и сервером.
Возобновляемо Флаг, определяющий, может ли данная сессия использоваться для создания нового ТСР-соединения.

Протокол изменения шифрования

Протокол состоит из единственного сообщения, которое зашифровано и сжато, как определено в текущем состоянии соединения.

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

Alert-протокол

Одним из протоколов, выполняющихся выше протокола Записи, является протокол Аlert. Содержимым протокола является либо фатальное, либо предупреждающее сообщение. Фатальное сообщение должно приводить к немедленному разрыву данного ТСР-соединения. В этом случае другие соединения, соответствующие данной сессии, могут быть продолжены, но идентификатор сессии должен быть помечен как недействительный для предотвращения использования данной сессии для установления новых соединений. Подобно другим сообщениям, сообщения Alert зашифрованы и сжаты, как определено в текущем состоянии соединения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следует заметить, что, так как Session ID передается без шифрования и обеспечения целостности, он не содержит конфиденциальную информацию. Содержимое всего Рукопожатия, включая Session ID, защищено Finished-сообщениями, которыми участники обмениваются в конце рукопожатия.

Список Cipher Suite, передаваемый от клиента серверу в сообщении Client Hello, содержит перечень криптографических алгоритмов, поддерживаемых клиентом, упорядоченный по предпочтениям клиента. Сервер выбирает по одному алгоритму из каждой категории, который он поддерживает. Если такого алгоритма не существует, сервер возвращает фатальный Alert и закрывает соединение.

После посылки сообщения Client Hello клиент ждет сообщения Server Hello. Любое другое сообщение, возвращаемое сервером, за исключением Hello Request, трактуется как фатальная ошибка.

Сервер посылает Server Hello в ответ на сообщение Client Hello, для того чтобы выбрать конкретный набор алгоритмов. Если для какого-то типа алгоритмов клиент и сервер не имеют одинакового алгоритма, ТСР-соединение будет сброшено.

Сообщение Certificate (сервера)

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

Тип сертификата должен соответствовать выбранному алгоритму обмена ключа. Обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключа.

Сообщение сервера обмена ключа посылается сервером только тогда, когда сообщение Server Certificate (если оно послано) не содержит достаточно данных для того, чтобы клиент мог осуществить обмен премастер-секретом.

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

Сообщение Certificate Request

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

Сообщение Server Hello Done

Сообщение Server Hello Done посылается сервером как признак окончания фазы Server Hello.

Сообщение Certificate (клиента)

Это первое сообщение, которое клиент посылает после получения сообщения Server Hello Done. Оно посылается только в том случае, если сервер запросил аутентификацию клиента.

Сообщение Client Key Exchange

Данное сообщение посылается клиентом всегда. Оно следует сразу за сообщением Client Certificate, если оно посылалось. В противном случае это первое сообщение, посланное клиентом после получения сообщения Server Hello Done.

После получения данного сообщения сервер может вычислить премастер-секрет, который передается либо с помощью RSA шифрования, либо вычисляется по алгоритму Диффи-Хеллмана. В любом случае каждая сторона вычисляет один и тот же премастер-секрет.

Проверка целостности с помощью сертификата клиента

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

Сообщение Finished

Сообщение Finished всегда посылается непосредственно после сообщения Сhange Сipher Spec для проверки успешного выполнения обмена ключа и процессов аутентификации. Сообщение Change Cipher Spec должно быть получено после остальных сообщений Рукопожатия и перед Finished-сообщением.

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

Вычисление мастер-секрета

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

master_secret = PRF(pre_master_secret, "master se-cret",ClientHello.random+ServerHello.random)       [0..47]

Длина мастер-секрета всегда равна 48 байтам. Длина премастер-секрета изменяется в зависимости от метода обмена ключа.

Денис Янченко
Денис Янченко
Россия
Ксения Благодарова
Ксения Благодарова
Россия, Липецк, ЛГПУ, 2018