Безопасность на транспортном уровне: SSL и TLS

Алгоритмы сжатия

Как мы уже говорили, сжатие является дополнительной услугой в SSLv3. Для SSLv3 не определен алгоритм сжатия. Поэтому заданным по умолчанию методом сжатия служит NULL. Однако система может использовать любой алгоритм сжатия по выбору сторон.

Генерирование криптографических параметров

Чтобы обеспечить целостность и конфиденциальность сообщения, в SSL необходимо иметь: шесть криптографических объектов секретности, четыре ключа и два инициализирующих вектора (IV). Клиенту нужно: один ключ для передачи сообщения установления подлинности (HMAC - HASH-BASED MESSAGE AUTHENTICATION CODE), один ключ для шифрования и один IV для шифрования блока. Сервер нуждается в том же самом. SSL требует, чтобы ключи для одного направления отличались от ключей для другого направления. Если будет атака в одном направлении, она не затронет другое направление. Для генерации параметров используют следующую процедуру:

Клиент и сервер обмениваются двумя случайными числами, одно из которых создано клиентом, а другое - сервером.

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

Создается 48-байтовый главный секретный код (master secret) из предварительного главного секретного кода (pre-master secret), с применением хэш-функций (SHA-1 и MD5), как это показано на рис. 7.8. (рис 7.8) Вычисление главного секретного кода из предварительного главного секретного кода

Главный секретный код используется для того, чтобы создать материал для ключей (key material), который имеет переменную длину. Для этого применяют то же самое множество хэш-функций, что и в предыдущем случае, и подставляют спереди различные константы, как это показано на рис. 7.9. Алгоритм повторяется, пока не получится материал для ключа адекватного размера.

Обратите внимание, что длина блока материала для ключей зависит от выбранного набора шифра и размера ключей, необходимых для этого набора.

(рис 7.9) Вычисление материала для ключей из главного секретного кода

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

Сеансы и соединение

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

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

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

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

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

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

Сеанс определяется состоянием сеанса - это множество параметров, установленных между сервером и клиентом. табл. 7.2 показывает список параметров для состояния сеанса.

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

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

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

7.2. Четыре протокола

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

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

Протокол установления соединения

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

Фаза 1: Установление характеристик для обеспечения безопасности

В Фазе 1 клиент и сервер объявляют свои характеристики безопасности, которые нужны и удобны для обоих. В этой фазе устанавливается и выбирается ID сеанса. Стороны согласуют конкретный метод сжатия. Наконец, выбирают два случайных числа: одно выбирается клиентом и другое - сервером, чтобы создать главный секретный код. В этой фазе стороны обмениваются двумя сообщениями: ClientHello и ServerHello. рис. 7.14 содержит дополнительные детали Фазы 1.

ClientHello. Клиент посылает сообщение. Оно содержит следующую информацию:

ServerHello. Сервер отвечает клиенту сообщением ServerHello, оно содержит:

Фаза II: Смена ключей сервера и установление подлинности

В фазе II сервер, если необходимо, подтверждает свою подлинность. Передатчик может передать свой открытый ключ и может также запросить сертификат клиента. В конце сервер объявляет, что процесс serverHello окончен. рис. 7.15 дает дополнительные сведения о Фазе II.

Certificate (сертификат) - если это требуется, сервер передает сообщение certificate, чтобы подтвердить свою подлинность. Сообщение включает список сертификатов типа X.509. Если алгоритм смены ключей - анонимный Диффи-Хеллман (Diffie-Hellman), то сертификат не нужен.

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

CertificateRequest - сервер может потребовать, чтобы клиент подтвердил свою подлинность. В этом случае сервер передает CertificateRequest сообщение в Фазе II, в котором запрашивает от клиента подтверждение в Фазе III. Сервер не может запросить сертификат от клиента, если клиент использует метод "анонимный Диффи-Хеллман".

ServerHelloDone - последнее сообщение в Фазе II. Оно является сигналом клиенту, что Фаза II закончена и что клиент должен запустить Фазу III.

Давайте тщательно рассмотрим установление подлинности сервера и смену ключей в этой фазе. Первые два сообщения здесь базируются на методе смены ключей. рис. 7.16 показывает четыре из шести методов обмена ключей, которые мы обсуждали раньше. Мы не включили Нулевой (NULL) метод, потому что в нем нет никакого обмена. Мы не включили метод Fortezza, потому что в этой книге мы его глубоко не рассматривали.

Фаза III: Смена ключей клиента и установление его подлинности

Фаза III предназначена подтвердить подлинность клиента. От клиента серверу можно передать до трех сообщений, как показано на рис. 7.17.

Сертификат. Чтобы сертифицировать себя на сервере, клиент передает сообщение Certificate. Обратите внимание, что его формат - тот же самый, что и у сообщения Certificate, передаваемого сервером в Фазе II, но содержание различно. В данном случае Certificate включает цепочку сертификатов, которые сертифицируют клиента. Такое сообщение передают, только если сервер запросил сертификат в Фазе II. Если есть запрос и клиент не имеет сертификата, чтобы передать его, тогда передается аварийное сообщение (часть аварийного протокола, который будет обсуждаться позже) с предупреждением, что сертификата нет. Сервер может продолжить сеанс или может решить прервать его.

ClientKeyExchange. После передачи сообщения Certificate клиент передает сообщение ClientKeyExchange, которое включает в себя вклад в предварительный главный секретный код. Содержание этого сообщения базируется на используемом алгоритме смены ключей. Если метод - RSA, клиент создает полный предварительный главный секретный код и зашифровывает его открытым ключом RSA сервера. Если метод - анонимный или кратковременный Диффи-Хеллман, клиент передает свой полуключ. Если метод - Fortezza, клиент передает параметры Fortezza. Содержание этого сообщения пусто, если метод - "фиксированный Диффи-Хеллман".

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

Рассмотрим более подробно установление подлинности клиента и смену ключей в этой фазе. Основой данного метода здесь являются три сообщения. рис. 7.18 показывает четыре из шести методов, которые мы рассматривали раньше. Опять мы исключили метод NULL и метод Fortezza.

Фаза IV: Завершение и окончание

В Фазе IV клиент и сервер передают сообщения, чтобы изменить спецификацию шифра и закончить процедуру установления связи. В этой фазе происходит обмен четырьмя сообщениями, как это показано на рис. 7.19.

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

Finished. Это сообщение также передает клиент. Сообщение Finished объявляет об окончании процедуры установления связи клиентом.

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

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

Протокол ChangeCipherSpec

Мы видели, что переговоры о наборе шифров и генерация криптографической секретности формируются постепенно по ходу выполнения протокола установления соединения. Возникает вопрос: когда две стороны могут использовать эти параметры секретности? SSL утверждает, что стороны не могут использовать эти параметры или секретность, пока они не передали или не получили специальное сообщение: ChangeCipherSpec - сообщение, которым обмениваются клиент и сервер в ходе выполнения протокола установления соединения и которое определено в протоколе ChangeCipherSpec. По этой причине объекты не посылают или не получают сообщение. Передатчик и приемник нуждаются не в одном, а в двух состояниях. Одно - состояние ожидания, при котором сохраняются параметры и секретности. Другое - активное состояние, при котором параметры и секретность используются протоколом передачи записей, чтобы подписаться/проверить или зашифровать/расшифровывать сообщения. Кроме того, каждое состояние содержит два множества значений: читать (входящее), писать (исходящее).

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

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

Сначала клиент передает ChangeCipherSpec-сообщение. После этого клиент перемещает параметры "писать" (исходящие) из состояния ожидания в активное состояние. Теперь он может использовать эти параметры, чтобы подписаться или зашифровать исходящее сообщение. После получения этого сообщения сервер перемещает параметры "читать" (входящие) из состояния ожидания в активное состояние. Теперь сервер может верифицировать и расшифровывать сообщение. Это означает, что сообщение Finished, передаваемое клиентом, может быть подписано клиентом и расшифровано сервером.

Сервер передает сообщение ChangeCipherSpec после получения от клиента сообщения Finished. После передачи этого сообщения он перемещает параметры "писать" (входящие) из состояния ожидания в активное состояние. Сервер может теперь использовать эти параметры для того, чтобы подписать или зашифровать исходящие сообщения. После того как клиент получает это сообщение, он перемещает первый абзац (входящий) из состояний ожидания в активное состояние. Теперь клиент может проверить (верифицировать) и расшифровать сообщения.

Конечно, после обмена сообщениями Finished обе стороны могут работать в обоих направлениях, используя активные параметры для чтения/записи.

Аварийный протокол

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

Протокол передачи записей

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

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

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

Фрагментация/Объединение

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

Сжатие/Расширение

В передатчике все фрагменты прикладного уровня сжаты с использованием метода сжатия, о котором договариваются во время процедуры установления связи. Метод сжатия не должен вносить потери (расширенный фрагмент должен быть точной копией первоначального фрагмента). Размер фрагмента не должен превысить 1024 байта. Некоторые методы сжатия работают только с заранее заданными размерами блоков, и если размер блока меньше, то блок дополняется. Поэтому размер сжатого фрагмента может быть больше, чем размер первоначального фрагмента. В приемнике сжатый фрагмент расширяется, чтобы создать точную копию оригинала. Если размер расширенного фрагмента превышает 214, вырабатывается аварийное сообщение "неправильное расширение" (fatal decompression). Обратите внимание, что сжатие/расширение в SSL - дополнительные функции.

Подписание/Подтверждение

В передатчике метод подтверждения подлинности определяется в течение установления соединения (NULL, MD5 или SHA-1) и создает подпись (MAC), как это показано на рис. 7.22.

Алгоритм хэширования применяется дважды. Сначала хэширование создается путем последовательных соединений (конкатенации) следующих значений:

секретный MAC (писать) (ключ подтверждения подлинности для исходящих сообщений);

заполнение 1, которое представляет байт 0x36, повторяемый 48 раз для MD5 и 40 раз для SHA-1;

порядковый номер этого сообщения; (рис 7.22) Вычисление MAC

тип сжатия, который определяет протокол верхнего уровня, обеспечившего сжатие фрагмента;

длина сжатия, которая указывает длину сжатого фрагмента;

сжатый фрагмент.

Второй раз завершающее хэширование (MAC) создается последовательным соединением (конкатенацией) следующих значений:

В приемнике проводится верификация - вычисление нового хэша и сравнение его с полученным хэшированием.

Шифрование/Дешифрование

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

Создание кадра

В передатчике после шифрования добавляется заголовок протокола передачи записей. Заголовок удаляется в приемнике перед дешифрованием.

7.3. Форматы сообщения SSL

Мы уже знаем, что сообщения из трех протоколов и данные от прикладного уровня инкапсулируются (вставляются) в сообщения протокола передачи записей. Другими словами, сообщение в протокол передачи записей инкапсулируется из четырех различных источников на стороне передатчика. На стороне приемника протокол передачи записей извлекает сообщения и доставляет их различным пунктам назначения. Протокол передачи записей имеет общий заголовок, который добавляется к каждому сообщению, прибывающему от источников, как показано на рис. 7.23.

Ниже приводится описание полей.

ChangeCipherSpec-протокол

Как мы говорили раньше, протокол ChangeCipherSpec имеет одно сообщение: ChangeCipherSpec. Это сообщение содержит только один байт, инкапсулированный в сообщение протокола передачи записей со значением 20, как показано на рис. 7.24.

Однобайтовое поле в сообщении названо CCS, и его значение в настоящее время равно 1.

Аварийный протокол

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

Два поля аварийного сообщения разъясняются ниже.

Протокол установления соединения

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

Сообщение HelloRequest

Сообщение HelloRequest, которое используется редко, является запросом от сервера к клиенту для перезапуска сеанса. Это может быть необходимо, если в сервере обнаружены сбои и необходим новый сеанс. Например, если сеанс становится таким длинным, что это угрожает его безопасности, сервер может передать рассматриваемое сообщение. Клиент тогда должен передать сообщение ClientHello и договориться о параметрах безопасности. рис. 7.27 показывает формат такого сообщения. Это - четыре байта со значением типа 0. Он не имеет никакого текстового блока, так что значение поля длины - также 0.

Сообщение ClientHello

Сообщение ClientHello - первое сообщение в обмене при установлении соединения. На рис. 7.28 показан формат сообщения.

Поле "тип" и поле длины предварительно были уже обсуждены. Ниже приводится краткое описание других полей.

Сообщение ServerHello

Cообщение ServerHello - ответ сервера на сообщение ClientHello. Формат подобен сообщению ClientHello, но с меньшим количеством полей. рис. 7.29 показывает формат сообщения.

Поле версии - то же самое, что и в сообщении ClientHello. Поле случайного числа сервера определяет значение, выбранное сервером. Длина ID сеанса и поле ID сеанса - те же самые, что и в сообщении ClientHello. Однако ID сеанса - обычно пробел (и длина обычно устанавливается на 0), если сервер не возобновляет старый сеанс. Другими словами, если сервер позволяет возобновление сеанса, он вставляет соответствующее значение в поле ID сеанса, которое используется клиентом (в сообщении ClientHello), когда клиент желает повторно открыть старый сеанс.

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

Сообщение Certificate

Сообщение Certificate может быть передано клиентом или сервером, чтобы передать список сертификатов открытого ключа. рис. 7.30 показывает формат.

Значение поля "тип" - 11. Текстовый блок сообщения включает следующие поля.

Сообщение ServerKeyExchange

ServerKeyExchange-сообщение передают от сервера к клиенту. рис. 7.31 показывает общий формат.

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

Сообщение CertificateRequest

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

Значение поля типа - 13. Текстовый блок сообщения включает следующие поля:

Сообщение ServerHelloDone

ServerHelloDone-сообщение - последнее сообщение, посылаемое во второй фазе процедуры установления связи. Сообщение сигнализирует, что Фаза II не доставляет никакой дополнительной информации. рис. 7.33 показывает формат.

Сообщение CertivicateVerify

Сообщение CertivicateVerify - это последнее сообщение Фазы III. В этом сообщении клиент доказывает, что он фактически имеет секретный ключ, связанный с его сертификатом открытого ключа. Чтобы доказать это, клиент создает хэш всех сообщений установления соединения, посланных перед этим сообщением, и подписывает их, используя алгоритм MD5 или SHA-1, основанный на типе сертификата клиента. рис. 7.34 показывает формат.

Если секретный ключ клиента связан с DSS-сертификатом, то хэширование базируется только на алгоритме SHA-1, и длина хэш - 20 байтов. Если секретный ключ клиента связан с сертификатом RSА, то есть два (конкатенированных) хэша: один - основанный на MD5 и другой - основанный на SHA-1. Полная длина - 16 + 20 = 36 байтов. рис. 7.35 показывает вычисления хэша.

Сообщение ClientKeyExchange

ClientKeyExchange - второе сообщение, посылаемое в течение третьей фазы процедуры установления связи. В этом сообщении клиент обеспечивает ключи. Формат сообщения зависит от заданных алгоритмов смены ключей, выбранных двумя сторонами. рис. 7.36 показывает общую идею формата.

Сообщение Finished

Cообщение Finished показывает, что переговоры закончены. Оно содержит все сообщения, которыми обменивались в течение процедуры установления связи, сопровождаемой указанием типа передатчика (клиент или сервер) и дополнением главного секретного кода. Точный формат зависит от типа используемого набора шифра. Общий формат показан на рис. 7.37 - последовательное соединение (конкатенация) двух хэшей. На рис. 7.38 изображено, как вычисляется каждый из них. Обратите внимание, что когда клиент или сервер передают сообщение Finished, они уже передали сообщение ChangedCipherSpec. Другими словами, криптографическая секретная информация (писать) находится в активном состоянии, клиент или сервер могут ее обработать. Сообщение Finished подобно фрагменту данных, прибывающему от прикладного уровня. Сообщение Finished может быть заверено (используя MAC из набора шифров) и зашифровано (используя алгоритм шифрования набора шифров).

Прикладные данные

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

После добавления общего заголовка со значением протокола 23 сообщение передачи записи передано. Обратите внимание, что общий заголовок не зашифрован. рис. 7.39 показывает общий формат.

7.4. Безопасность транспортного уровня

Безопасность транспортного уровня (TLS - Transport Layer Security) - протокол IEFT, стандартная версия протокола SSL. Эти два протокола очень похожи, но имеют небольшие отличия. Вместо того чтобы описывать TLS полностью, в этой секции мы только отметим отличия между протоколами TLS и SSL.

Версии

Первое отличие - номер версии (основное, но незначительное). Текущая версия SSL - 3.0; текущая версия TLS - 1.0. Другими словами, SSLv3.0 совместим с TLSv 1.0.

Набор шифров

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

Генерация криптографической секретности

Генерация криптографической секретности в TLS более сложная, чем в SSL. TLS сначала определяет две функции: функцию расширения данных и псевдослучайную функцию. Рассмотрим их.

Функция расширения данных

Функция расширения данных использует заранее заданный код аутентификации на основе хэширования (HMAC-HASH-BASED MESSAGE AUTHENTICATION CODE), или MD5, или SHA-1 для того, чтобы расширить информацию засекречивания. Эту функцию можно рассматривать как функцию, содержащую множество секций, где каждая секция создает одно значение хэширования. Расширенная секретность - последовательное соединение значений хэширования. Каждая секция использует два HMAC, информацию засекречивания и начальное число. Функция расширения данных - это формирование цепочки в виде многих секций. Однако чтобы сделать следующую секцию зависимой от предыдущей, второе начальное число - фактически выход первого HMAC предыдущей секции, как это показано на рис. 7.40.

Псевдослучайная функция

TLS определяет псевдослучайную функцию (PRF - PseudoRandom Function), чтобы получить комбинацию двух функций расширения данных: одна из них использует MD5 и другая - SHA-1. На PRF поступает три части информации: секретный код, метка и начальное число.

Метка и начальное число связаны и служат начальным числом для каждой функции расширения данных. Информация засекречивания разделена на две части; каждая часть используется как информация засекречивания для каждой функции расширения данных. Выходы двух функций расширения данных складывают по модулю два, чтобы создать конечную расширенную информацию засекречивания. Обратите внимание, что поскольку хэш создается MD5 и SHA-1, он имеет различные размеры, поэтому должны быть созданы дополнительные секции функций на базе MD5, чтобы сделать два вывода с одинаковым размером. рис. 7.41 показывает идею применения PRF.

Главный секретный код

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

Материал для ключей

TLS использует функцию PRF, чтобы создать материал для ключей от главного секретного кода. На сей раз информация засекречивания содержит: главный секретный код; метку - это строка "расширение ключа"; и начальное число - конкатенацию случайного числа сервера и случайного числа клиента, как это показано на рис. 7.43.

Аварийный протокол

TLS поддерживает все аварийные сигналы, определенные в SSL, за исключением NoCertificate. TLS также добавляет к списку SSL некоторые новые. табл. 7.7 показывает полный список аварийных сигналов, поддерживаемых TLS.

Протокол установления соединения

TLS вносит некоторые изменения в протокол установления соединения. Были специально изменены детали сообщения CertificateVerify и сообщения Finished.

Сообщение CertificateVerify (сертификат верифицирован)

В SSL хэширование, используемое в .Сообщении CertificateVerify . - это хэширование с двумя шагами, а именно: сообщение установления соединения плюс заполнение и главный секретный код. TLS упростил процесс: в нем хэшируется только сообщение установления соединения, как показано на рис. 7.44.

Сообщение Finished

Было также изменено вычисление хэш для сообщения Finished. TLS использует PRF, чтобы вычислить два хэша, применяемых для сообщения Finished, как это показано на рис. 7.45.

Протокол передачи записей

Единственное изменение в протоколе передачи записей - использование HMAC, чтобы подписать сообщение. TLS применяет MAC, как это определено в лекции 11, для того чтобы создать HMAC. TLS также добавляет версию протокола (названную сжатой версией) к тексту, который будет подписан. рис. 7.46 показывает, как формируется HMAC.

7.4. Рекомендованная литература

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

Книги

[Res01], [Tho00], [Sta06], [Rhe03] и [PHS03] рассматривают SSL и TLS.

Сайты

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

http://www.ietf.org/rfc/rfc2246.txt

7.6. Итоги

7.7. Набор для практики

Обзорные вопросы

Упражнения

Master Secret = MD5 (pre-master | SHA-1 ("A" |pre-master I CR I SR)) |
MD5 (pre-master| SHA-1 ("A" | pre-master | CR I SR)) | 
MD5 (pre-master |SHA-1 ("A" | pre-master  | CR | SR))
Master Secret	Главный секретный код
pre-master	Предварительный главный секретный код
|	Конкатенация
CR	Случайное число клиента
SR	Случайное число сервера