* метода сжатия ( Compression method ), то есть алгоритма сжатия данных перед их шифрованием;
* спецификатора шифрования ( Cipher spec ), который задает идентификаторы алгоритма шифрования данных и алгоритма хэширования, а также некоторые криптографические атрибуты (например, размер хэш-кода);
* главного секрета ( Master secret ), представляющего собой секретное значение, разделенное между клиентом и сервером;
* признака установления нового соединения ( Is resumable ) на основе текущего сеанса.
Эти характеристики затем используются для установки параметров безопасности в протоколе передачи записей. Возможность установить несколько защищенных соединений во время одного сеанса особенно важна, когда клиенту и серверу необходимо установить несколько кратковременных соединений.
В результате работы протокола Handshake Protocol формируются криптографические параметры. Когда клиент и сервер начинают взаимодействие, то согласовывают версию протокола, криптографические алгоритмы, аутентифицируют друг друга (по желанию) и используют криптографию с открытыми ключами для разделения общего секрета. Работа протокола Handshake Protocol выполняется за шесть шагов [70].
* 1-й шаг. Обмен приветственными сообщениями для согласования алгоритмов и обмена случайными числами.
* 2-й шаг. Обмен криптографическими параметрами для согласования начального секрета.
* 3-й шаг. Опциональный обмен сертификатами и криптографической информацией для взаимной аутентификации клиента и сервера.
* 4-й шаг. Генерация главного секрета на основе начального секрета и обмен случайными числами.
* 5-й шаг. Формирование параметров безопасности для протокола передачи записей.
* 6-й шаг. Оповещение о расчете тех же самых параметров безопасности и корректном завершении соединения.
Когда клиент желает установить новое соединение на основе данного сеанса или повторить этот сеанс, то отправляет свое приветственное сообщение с идентификатором сеанса, который должен быть возобновлен. Если сервер все еще хранит в кэш-памяти параметры сеанса и желает восстановить соединение, то в ответ отправляет свое приветственное сообщение с тем же самым идентификатором сеанса. В этот момент клиент и сервер обмениваются сообщениями о смене параметров шифрования и завершении формирования соединения.
При обмене сертификатами и ключами передаются данные, необходимые для генерации начального секрета. Если используется алгоритм RSA, то клиент генерирует случайное начальное число и шифрует его при помощи открытого RSA-ключа сервера. Если применяется алгоритм Диффи-Хэллмана, клиент и сервер обмениваются открытыми ключами, а затем в качестве начального секрета используется результат вычисления ключа согласования ключей по алгоритму Диффи-Хэллмана.
Главный секрет и симметричные ключи генерируются при помощи псевдослучайной функции PRF (PseudoRandom Function), полученной на основе алгоритмов SHA-1 и MD5. Чтобы гарантировать безопасность, применяются две разные однонаправленные хэш-функции. При первом применении функции PRF генерируется главный секрет из начального секрета и случайных чисел, полученных на основе приветственных сообщений клиента и сервера. В результате повторного применения функции PRF к тем же самым исходным данным получают два симметричных ключа, два значения начального вектора и два значения MAC (кода аутентификации сообщения) секрета. При возобновлении сеанса используется уже известное для данного сеанса значение главного секрета, но генерируются новые случайные числа на основе новых приветственных сообщений клиента и сервера, поэтому в результате формируется новый ключевой материал.
Протокол передачи записей использует один симметричный ключ, одно значение начального вектора и один MAC секрета для защиты трафика "клиент-сервер", а также другие значения перечисленных параметров для защиты трафика "сервер-клиент", - в целом, для корректной работы протокола передачи записей требуется шесть секретных чисел.
Протокол передачи записей
Протокол передачи записей Record Protocol состоит из нескольких подуровней. Обработка данных протокола прикладного уровня заключается в их разбиении на управляемые блоки, сжатии, снабжении имитовставкой, шифровании и последующей передаче результата. Полученные данные обрабатываются в обратном порядке: расшифровываются, проверяются на целостность, подвергаются декомпрессии, сборке, а затем доставляются приложению [6].
На подуровне фрагментации информация разбивается на записи, длина каждой записи не превышает 16384 байтов. Допускается агрегирование нескольких однотипных сообщений в одну запись, а также разбиение одного сообщения протокола прикладного уровня на несколько записей. На подуровне сжатия выполняется сжатие или декомпрессия всех фрагментов. Очевидно, что при компрессии не должно быть потери данных. Затем вычисляется имитовставка, то есть проверяется целостность сжатой записи, а полученное значение и сжатая запись шифруются. Проверка целостности осуществляется при помощи кода аутентификации сообщения (MAC) или кода аутентификации, полученного на основе хэш-кода сообщения (HMAC).
После принятия данных текст расшифровывается, для проверки его целостности повторно вычисляется MAC, причем вычисления выполняются с использованием порядкового номера записи с целью обнаружения потерянных, лишних или повторно сжатых записей.
Поддержка безопасности транспортного уровня на основе PKI
Сертификаты являются центральным компонентом всех сервисов аутентификации и управления ключами, предлагаемых как TLS, так и SSL. Эти сервисы полагаются на связывание идентичности субъекта с его открытым ключом. Для идентификации web-серверов рекомендуется использовать DNS-имена (типа www.alpha.com) и указывать их в дополнении сертификатов Subject Alternative Name (параметр dNSName ). Если DNS-имя не представлено в сертификате, то для идентификации используется отличительное имя субъекта.
Обычно при взаимодействии клиента и сервера сервер предъявляет сертификат, а клиент - нет, в результате чего происходит односторонняя аутентификация сервера клиентом, который сохраняет свою анонимность. Сервер может потребовать от клиента аутентификации, запрашивая сертификат по протоколу Handshake Protocol. В этом случае клиент должен иметь сертификат и предоставить его серверу. Обычно клиент предъявляет сертификат ключа подписи. В процессе верификации заверенного цифровой подписью сообщения, отправленного по протоколу Handshake Protocol, выясняется, способен ли клиент сгенерировать подпись при помощи своего секретного ключа, соответствующего открытому ключу подписи, который содержится в сертификате.
Сертификаты, используемые для поддержки безопасности транспортного уровня, также должны содержать дополнение Key Usage, отражающее соответствующее назначение открытого ключа, который содержится в сертификате:
* цифровая подпись, если необходимо выполнять верификацию подписей;
* шифрование ключей, чтобы обеспечить RSA-шифрование;
* согласование ключей, если необходима поддержка согласования ключей методом Диффи-Хэллмана.
Клиент должен быть уверен, что открытый ключ принадлежит серверу. Если используется некорректный открытый ключ, то постороннее лицо может получить начальный секрет и возможность сгенерировать главный секрет и все другие секретные параметры, вычисляемые с его помощью. Сертификат подтверждает принадлежность открытого ключа серверу.
При аутентификации клиента сервер полагается на принадлежность открытого ключа клиенту и принимает решение о возможности доступа. Если используется некорректный открытый ключ, то доступ к серверу может получить постороннее лицо, а не та сторона, которой доступ необходим. Сертификат обеспечивает необходимое связывание открытого ключа с идентичностью клиента.