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

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

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

Рис. 7.17. Протокол установления соединения, Фаза III

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

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

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

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

увеличить изображение
Рис. 7.18. Четыре случая Фазы III

1. RSA. В этом случае не передается сообщение Certificate, если сервер явно не запросил его в Фазе II. ClientKeyExchange включает в себя предварительный главный секретный код, который зашифрован открытым ключом RSА, полученным в Фазе II.
2. Анонимный DH. В этом методе не передается сообщение Certificate. Сервер не имеет права запросить сертификат в Фазе II, потому что и клиент и сервер - анонимны. В ClientKeyExchange-сообщении сервер передает параметры Диффи-Хеллмана и свой полуключ. Обратите внимание, что в этом методе клиент не проверен на подлинность сервером.
3. Кратковременный DH. В этом методе клиент обычно имеет сертификат. Сервер должен передать его RSA- или DSS-сертификат (на основе согласованного множества шифров). В ClientKeyExchange сообщении клиент подписывает параметры DH, а также и свой полуключ, и передает их. Подлинность клиента подтверждается серверу подписью второго сообщения. Если клиент не имеет сертификата, а сервер запрашивает его, клиент передает аварийное сообщение. Если это приемлемо для сервера, клиент передает параметры DH и ключ в исходном тексте. Конечно, в этой ситуации клиент не проверен сервером на подлинность.
4. Фиксированный DH. В этом методе клиент обычно передает сертификат DH в первом сообщении. Обратите внимание, что здесь второе сообщение пустое. Клиент подтверждает свою подлинность серверу, посылая сертификат DH.

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

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

Рис. 7.19. Протокол установления соединения, Фаза IV

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

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

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

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