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

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

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

увеличить изображение
Рис. 7.12. Четыре протокола SSL

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

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

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

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

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

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

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

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

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

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

• Номер версии SSL. Это два номера версии:

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

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

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

Рис. 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, потому что в этой книге мы его глубоко не рассматривали.

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

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