Протокол SSL/TLS

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

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

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

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

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

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

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

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

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

• Клиент запрашивает использование расширений с помощью расширенного сообщения Client Hello, описанного ниже. TLS 1.0 требует, чтобы серверы принимали расширенные сообщения Client Hello, даже если они не понимают расши-рения.
• Сервер может не посылать никакого ответа на расширения, которые он не поддерживает.

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

В качестве имени сервера как правило, поддерживается только 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 и тем самым сохранить ширину полосы пропускания в ограниченных сетях.