Протокол SSL/TLS

Обзор

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

Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет TLS иметь обратную совместимость с SSL 3.0.

Перечислим задачи протокола SSL/TLS в порядке их приоритета:

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

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

Протокол Рукопожатия обеспечивает безопасность соединения, которая основана на следующих свойствах:

Одно из преимуществ TLS состоит в том, что он независим от при-кладного протокола.

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

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

Протокол Записи

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

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

Состояния соединения

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

Определены следующие параметры состояния:

Из мастер-секрета создаются шесть ключей:

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

Вычисление ключей

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

НМАС и псевдослучайная функция

Для обеспечения целостности используется НМАС с хэш-функциями MD5 и SHA-1, обозначаемыми как HMAC_MD5 (secret,data) и HMAC_SHA (secret, data).

В алгоритме определена псевдослучайная функция PRF, которая расширяет секрет до нужной длины для создания всех необходимых ключей. Эта функция получает в качестве входа секрет, "зерно" (seed - значение, которое с одной стороны является случайным, а с другой стороны не явля-ется секретным, т.е. может стать известно оппоненту) и стандартное значение, и создает выход требуемой длины.

Сначала определяется функция расширения данных P_hash (secret, data), которая использует хэш-функцию для расширения секрета до нужной длины следующим образом:

P_hash (secret, seed) = HMAC_hash (secret, A(1) || seed) || 
HMAC_hash (secret, A(2) || seed) ||
HMAC_hash (secret, A(3) || seed) ||

А (i) определяется следующим образом:

А (0) = seed
A (i) = HMAC_hash (secret, A (i - 1))

P_hash может иметь столько итераций, сколько необходимо для создания данных требуемой длины. Например, если P_SHA-1 используется для создания 64 байтов данных, то количество итераций должно быть равно 4, при этом будет создано 80 байтов данных; последние 16 байтов заключительной итерации будут отброшены, чтобы оставить только 64 байта выходных данных.

Для получения ключевого материала нужной длины секрет, вычисленный в протоколе Рукопожатия, делится на две половины, одна половина используется для создания данных с помощью P_MD5, а другая - для созда-ния данных с помощью P_SHA-1.

PRF определяется как результат сложения по модулю 2 результатов выполнения P_MD5 и P_SHA-1.

PRF (secret, label, seed) = P_MD5 (S1, label + seed) ⊕ 
P_SHA-1 (S2, label + seed)

Label является фиксированной текстовой строкой.

Заметим, что поскольку MD5 создает 16-байтные значения, а SHA-1 создает 20-байтные значения, то количество итераций каждой из функций будет разным. Например, для создания 80-байтного значения необходимо выполнить 5 итераций P_MD5 и 4 итерации P_SHA-1.

Для создания ключей вычисляется следующее значение:

key_block = PRF (SecurityParameters.master_secret,
"key expansion",  
SecurityParameters.server_random + SecurityParame-ters.client_random)

Количество итерация в PRF определяется суммарной длиной ключей. Затем key_block разбивается на блоки для получения требуемых ключей.

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

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

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

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

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

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

Alert-протокол

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

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

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

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

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

Клиент посылает сообщение 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. После этого посылается сообщение обмена ключа клиента. Содержимое этого сообщения зависит от выбранного алгоритма выработки общего секрета. Если клиент посылал свой сертификат, то он посылает сообщение, содержащее цифровую подпись для проверки всех сообщений Рукопожатия.

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

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

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

Следует заметить, что, так как 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 байтам. Длина премастер-секрета изменяется в зависимости от метода обмена ключа.

Добавление дополнительных возможностей в протокол

Рассмотрим расширения, которые позволяют добавлять новые функциональности в SSL/TLS. Рассмотрим общие механизмы расширений для протокола Рукопожатия и конкретные расширения, используемые для добавления новых возможностей.

Сейчас SSL/TLS используется в самых разных окружениях, возможности которых не учитывались при разработке протокола. Данные расширения разработаны для того, чтобы SSL/TLS мог максимально эффективно функционировать в новых окружениях, такие, например, как беспроводные сети.

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

Данные расширения предназначены для обеспечения следующих возможностей:

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

Описываемые расширения могут использоваться клиентами и серверами, поддерживающими версию TLS 1.0. Расширения поддерживают обратную совместимость – это означает, что клиенты версии TLS 1.0, которые поддерживают расширения, могут общаться с серверами TLS 1.0, не поддерживающими расширения, и наоборот.

Обратная совместимость достигается следующим образом.

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

В качестве имени сервера как правило, поддерживается только DNS-имя.

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

Переговоры о максимальной длине фрагмента

Прежняя версия SSL/TLS указывает, что максимальная длина незашифрованного фрагмента равна 214 байт. Для некоторых клиентов может требоваться использовать меньшую длину фрагмента из-за ограничений памяти или ограничений полосы пропускания.

Сервер, получивший расширенный Client Hello с расширением Max Fragment Length, может принять эту длину и включить расширение Max Fragment Length в Server Hello.

После того, как стороны успешно договорились о максимальной длине фрагмента, отличной от 2¹⁴, клиент и сервер должны немедленно начать фрагментировать сообщения (включая сообщения Рукопожатия), чтобы гарантировать, что не посылаются сегменты большей длины, чем та, о ко-торой договорились.

Новая длина применяется в течение всей сессии, включая возобновляемые сессии.

URL сертификат клиента

SSL/TLS требует, чтобы при выполнении аутентификации клиента сертификаты клиента посылались серверу в протоколе Рукопожатия. Для клиентов, имеющих ограничения на память, существует возможность посылать URL сертификата вместо самих сертификатов, чтобы они могли не хранить свои сертификаты и тем самым не занимать память.

Для ведения переговоров о посылке серверу URL сертификата клиенты могут включать расширение типа Client Certificate Url в Client Hello.

Сервер, получивший расширенный Client Hello, содержащий расширение Client Certificate Url, может указать, что имеет возможность принимать URL сертификата, указывая расширение типа Client Certificate Url в Server Hello.

Указание доверенного СА

Клиенты, которые имеют ограниченную память, могут хранить только небольшое количество сертификатов корневых СА. В этом случае они могут указать серверу, какими корневыми сертификатами они владеют.

Для этого клиенты могут включить расширение типа Trusted Ca Keys в Client Hello. Поле Extension Data данного расширения должно содержать Trusted Authorities.

Урезанный НМАС

В настоящий момент набор шифрования использует в качестве МАС НМАС либо с MD5, либо с SHA-1 для аутентификации соединений уровня записи. Результат вычисления хэш-функции используется в качестве значения МАС. Однако в некоторых ограниченных окружениях может оказаться желательным использовать 80-битные значения МАС.

Для того чтобы вести переговоры об использовании 80-битного урезанного МАС, клиенты могут включить расширение Truncated Hmac в расширенный Client Hello.

При получении расширенногоHello, содержащего расширение Truncated Hmac, сервер может согласиться использовать урезанный МАС, включая расширения Truncated Hmac с пустым Extension Data в расширенный Server Hello.

Запрос статуса сертификата

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