Безопасное сетевое взаимодействие (часть 2)

Используемые расширения

Рассмотрим используемые расширения TLS.

Заметим, что любые сообщения, соответствующие этим расширениям, посылаются при Рукопожатии и должны включаться в вычисления хэша в сообщение Finished.

Сначала рассмотрим расширение, позволяющее клиенту указать сервер, с которым он соединяется. Затем опишем расширение для указания максимальной длины фрагмента. Далее опишем расширение, которое позволяет клиенту указать URLs сертификатов, и расширение, позволяющее указать ключи корневых СА. Наконец, опишем расширение, которое позволяет задействовать урезанный HMAC, и расширение, поддерживающее интеграцию сообщения с информацией о статусе сертификата в Рукопожатие TLS.

Указание имени сервера

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

Для того чтобы указать имя сервера, клиент может включить расширение типа server_name в Client Hello. Поле extension_data должно содержать ServerNameList:

struct {
    NameType name_type;
    select (name_type) {
        case host_name: HostName;
    } name;
} ServerName;
enum {
    host_name(0), (255)
} NameType;
opaque HostName<1..2^16-1>;
struct {
    ServerName server_name_list<1..2^16-1>
} ServerNameList;

На сегодня в качестве имени сервера поддерживается только DNS hostname. Это не означает какой-либо зависимости TLS от DNS, в дальнейшем могут быть добавлены другие типы имен. TLS может трактовать имена серверов как данные неизвестной структуры (opaque) и передавать их приложению.

HostName содержит полностью определенное DNS hostname сервера. Hostname является байтовой строкой, представленной с использованием UTF-8.

Сервер, который получил сообщение Client Hello, содержащее расширение server_name, может использовать данную информацию для выбора сертификата, возвращаемого клиенту, либо для каких-то других аспектов безопасности. В данном случае сервер должен включить расширение типа server_name в расширенное Server Hello. Поле extension_date данного расширения должно быть пустым.

Если сервер понимает расширение Client Hello, но не смог распознать имя сервера, он должен послать unrecognized_name Alert (который может быть фатальным).

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

Переговоры о максимальной длине фрагмента

Прежняя версия TLS указывает, что максимальная длина незашифрованного фрагмента равна 2¹⁴ байт. Для некоторых клиентов может потребоваться вести переговоры о меньшей максимальной длине фрагмента из-за ограничений памяти или ограничений ширины полосы пропускания.

Для этого клиент может указать расширение типа max_fragment_length в Client Hello. Поле extension_data данного расширения должно содержать:

enum{
    2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;

значение которого является требуемой максимальной длиной фрагмента. Допустимыми значениями для данного поля являются: 2⁹, 2¹⁰, 2¹¹ и 2¹².

Сервер, получивший расширенный Client Hello с расширением max_fragment_length, может принять эту длину, включая расширение типа max_fragment_length в Server Hello. Поле extension_data данного расширения должно содержать MaxFragmentLength, которое является тем же самым, что и запрошенная максимальная длина фрагмента.

Если запрошена недопустимая длина фрагмента, сервер должен прервать Рукопожатие с Alert illegal_parameter. Аналогично, если клиент получил ответ с максимальной длиной фрагмента, отличной от запрошенной, он также должен прервать Рукопожатие с Alert illegal_parameter.

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

Новая длина применяется для продолжения сессии, включая возобновляющиеся сессии.

URLs сертификата клиента

TLS требует, чтобы при выполнении аутентификации клиента сертификаты клиента посылались серверу в течение Рукопожатия. Для клиентов, имеющих различные ограничения, может потребоваться посылать URLs сертификата вместо самих сертификатов, чтобы они могли не хранить свои сертификаты и тем самым не занимать память.

Для ведения переговоров о посылке серверу URLs сертификата клиенты могут включать расширение типа client_certificate_url в Client Hello. Поле extension_data данного расширения должно быть пустым.

Заметим, что необходимо вести переговоры об использовании URLs сертификатов клиента, чтобы существующие серверы TLS 1.0 могли функционировать.

Сервер, получивший расширенный Client Hello, содержащий расширение client_certificate_url, может указать, что имеет возможность принимать URLs сертификата, указывая расширение типа client_certificate_url в Server Hello. Поле extension_data данного расширения должно быть пустым.

После успешного завершения переговоров об использовании URLs сертификата клиента клиент может посылать сообщение CertificateURL вместо сообщения Certificate:

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
    false(0), true(1)
} Boolean;
struct {
    CertChainType type;
    URLAndOptionalHash 
        url_and_hash_list<1..2^16-1>;
} CertificateURL;
struct {
    opaque url<1..2^16-1>;
    Boolean hash_present;
    select (hash_present) {
        case false: struct {};
        case true: SHA1Hash;
    } hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];

Здесь url_and_hash_list содержит последовательность URLs и хэши (необязательно).

При использовании сертификатов Х.509 существует две возможности:

• Если Certificate.type есть individual_certs, то каждый URL ссылается на единственный сертификат Х.509v3 в DER-представлении; при этом первым указывается сертификат клиента.
• Если Certificate.type есть PkiPath, то список содержит единственный URL, ссылающийся на цепочку сертификатов в представлении DER, при этом используется тип PkiPath, описанный ниже.

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

Хэш, соответствующий каждому URL, либо не присутствует, либо является SHA-1 хэшем сертификата или цепочки сертификатов (в случае сертификатов Х.509 DER-представлением сертификата или DER-представлением PkiPath ).

Заметим, что когда используется список URLs для сертификатов Х.509, упорядоченность URLs является той же самой, что и в сообщении Certificate, в противоположность упорядоченности, в которой сертификаты представлены в PkiPath. В любом случае самоподписанный корневой сертификат в цепочке может быть опущен, в предположении, что сервер уже проверил его действительность.

При получении CertificateURL сервер должен пытаться получить цепочку сертификатов клиента из URLs и затем обработать ее обычным образом. Может использоваться кэшированная копия содержимого любого URL из цепочки, проверяя, что SHA-1 хэш присутствует и соответствует хэшу кэшированной копии.

Серверы, которые поддерживают данное расширение, должны поддерживать http:URL схему для URLs сертификатов и могут поддерживать другие схемы.

Если протокол, используемый для получения сертификатов или цепочки сертификатов, возвращает MIME форматированный ответ (как делает НТТР), то должен применяться следующий MIME Content-Type: при возврате единственного сертификата Х.509v3 Content-Type есть application/pkix-cert, при возврате цепочки сертификатов Х.509v3 Content-Type есть application/pkix-pkipath.

Если для URL присутствует SHA-1 хэш, то сервер должен убедиться, что SHA-1 хэш содержимого объекта, полученного из URL (после декодирования произвольного MIME Content-Transfer-Encoding), соответствует данному хэшу. Если полученный объект не имеет корректного SHA-1 хэша, сервер должен прервать Рукопожатие с Alert bad_certificate_hash_value.

Заметим, что клиент может выбрать либо посылку Certificate, либо посылку CertificateURL после успешных переговоров о посылке URLs сертификатов. Опция посылки сертификата обеспечивает клиенту гибкость при обработке нескольких сертификатов.

Если сервер столкнулся с непредвиденной задержкой при получении сертификатов по указанному CertificateURL, он должен при истечении таймаута создать Alert ошибки certificate_unobtainable.