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

Указание доверенного СА

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

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

struct {
    TrustedAuthority 
        trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;
struct {
    IdentifierType identifier_type;
    select (identifier_type) {
        case pre_agreed: struct {};
        case key_sha1_hash: SHA1Hash;
        case x509_name: DistinguishedName;
        case cert_sha1_hash: SHA1Hash;
    } identifier;
} TrustedAuthority;
enum {
    pre_agreed(0), key_sha1_hash(1), 
    x509_name(2), cert_sha1_hash(3), (255)
} IdentifierType;
opaque DistinguishedName<1..2^16-1>;

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

• pre_agreed – не предоставляется никакой идентификации ключа корневого СА.
• key_sha1_hash – содержит SHA-1 хэш ключа корневого СА. Для ключей DSA и ECDSA это хэш значения subjectPublicKey. Для ключей RSA хэш есть строка байтов модуля без начальных нулевых байтов (аналогично форматам хэша ключа в других окружениях).
• х509_name – содержит DER представление DN CA.
• cert_sha1_hash – содержит SHA-1 хэш DER представления Certificate, содержащего ключ корневого СА.

Заметим, что клиенты могут включать в данное расширение несколько или все ключи корневого СА, которыми они владеют, либо ни одного из них.

Также возможна ситуация, при которой хэш ключа или DN по отдельности не идентифицируют выпускающего сертификат – например, если конкретный СА имеет несколько пар ключей – однако здесь мы предполагаем, что в TLS DNs идентифицируют выпускающих сертификаты.

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

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

Урезанный НМАС

В настоящий момент набор шифрования использует в качестве МАС НМАС либо с MD5, либо с SHA-1 для аутентификации соединений уровня записи. Весь выход хэш-функции используется в качестве тега МАС. Однако может быть желательно в некоторых ограниченных окружениях обрезать выход хэш-функции до 80 битов при формировании тегов МАС.

Для того чтобы вести переговоры об использовании 80-битного урезанного МАС, клиенты могут включить расширение типа truncated_hmac в расширенный Client Hello. Поле extension_data данного расширения должно быть пустым.

При получении расширенного Hello, содержащего расширение truncated_hmac, сервер может согласиться использовать урезанный МАС путем включения расширения типа truncated_hmac с пустым extension_data в расширенный Server Hello.

Заметим, что если добавлен новый набор алгоритмов шифрования, который не использует НМАС, и при переговорах выбран один из этих наборов, то данное расширение ни на что не влияет. Рекомендуется, чтобы все новые наборы алгоритмов шифрования, использующие другие МАСs, рассматривали размер МАС как составную часть определения набора шифрования, имея в виду как безопасность, так и ограничения ширины полосы пропускания.

Если переговоры об урезанном МАС успешно завершены, клиент и сервер передают эту информацию на уровень записи в качестве параметров безопасности. Далее в данной сессии клиент и сервер должны использовать урезанный НМАС, соответствующим образом вычисляя его. Это означает, что CipherSpec.hash_size есть 10 байтов, и только первые 10 байтов выхода НМАС передаются и проверяются. Заметим, что данное расширение не влияет на вычисление PRF на часть получения ключа.

Размер урезанного МАС применяется к сессиям, в том числе возобновляемым.

Запрос статуса сертификата

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

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

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;
enum {ocsp(1), (255)} CertificateStatusType;
struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions  request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

В OCSPStatusRequest ResponderIDs указывает список отвечающих OCSP, которым доверяет клиент. Последовательность responder_id_list нулевой длины имеет специальное значение, указывающее, что отвечающие неявно известны серверу, например предварительно согласованы. Extensions являются DER-представлением расширений запроса OCSP.

Оба типа ResponderID и Extensions определены в OCSP. Extensions взято из PKI. Значение request_extension нулевой длины означает, что никаких расширений нет.

Сервер, получивший Client Hello с расширением status_request, может вернуть соответствующий статус сертификата вместе со своим сертификатом. При запросе OCSP следует использовать информацию, содержащуюся в расширении, и включать request_extensions в запрос OCSP.

Сервер возвращает ответ сертификата вместе со своим сертификатом, посылая сообщение CertificateStatus сразу после сообщения Certificate (и перед любым из сообщений ServerKeyExchange или CertificateRequest ). Если сервер вернул сообщение CertificateStatus, он должен включить расширение типа status_request с пустым extension_data в расширенный Server Hello.

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;

ocsp_response содержит полный OCSP-ответ в DER-представлении. Заметим, что может быть послан только один OCSP-ответ.

Сообщение CertificateStatus передается с использованием сообщения Рукопожатия типа certificate_status.

Заметим, что сервер может решить не посылать сообщение CertificateStatus, даже если он получил расширение status_request в сообщении Client Hello.

Наконец заметим, что сервер не должен посылать сообщение CertificateStatus, если он не получил расширение status_request в сообщении Client Hello.

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