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

Общие механизмы расширений

Рассмотрим общие механизмы расширений для сообщений Рукопожатия Client Hello и Server Hello.

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

Сначала опишем формат расширенного сообщения Client Hello, затем формат расширенного сообщения Server Hello и формат реально используемого расширения.

Расширенный Client Hello

Клиент может запросить расширенную функциональность от сервера, посылая расширенный формат сообщения Client Hello вместо обычного формата сообщения Client Hello. Расширенный формат сообщения Client Hello следующий:

struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-1>;
    CompressionMethod 
      compression_methods<1..2^8-1>;
    Extension 
      client_hello_extension_list<0..2^16-1>;
} ClientHello;

Здесь новое поле client_hello_extension_list содержит список расширений.

Если клиент запросил дополнительную функциональность, используя расширенный Client Hello, и данная функциональность не поддерживается сервером, клиент может прервать Рукопожатие.

Заметим, что TLS допускает дополнительную информацию в сообщении Client Hello. Таким образом, использование расширенного Client Hello не должно приводить к разрыву соединения с существующими серверами TLS.

Сервер, который поддерживает механизм расширений, должен принимать как исходный формат, так и расширенный формат Client Hello, и (как и для всех остальных сообщений) проверять, соответствует ли количество данных в сообщении одному из этих форматов; если это не так, он должен послать фатальный Alert decode_error.

Расширенный Server Hello

Расширенный формат сообщения Server Hello может быть послан вместо сообщения Server Hello, когда клиент запросил дополнительную функциональность с помощью расширенного сообщения Server Hello. Расширенный формат сообщения Server Hello следующий:

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
    Extension 
      server_hello_extension_list<0..2^16-1>;
} ServerHello;

Здесь новое поле server_hello_extension_list содержит список расширений. Реальный формат расширения будет определен ниже.

Заметим, что расширенное сообщение Server Hello посылается только в ответ на расширенное сообщение Client Hello. Это позволит избежать ситуации, при которой расширенное сообщение Server Hello не даст установить соединение с существующими клиентами TLS 1.0.

Расширения Hello

Формат расширения для Client Hello и Server Hello следующий:

struct {
    ExtensionType extension_type;
    opaque extension_data<0..2^16-1>;
} Extension;

Где:

• extension_type определяет конкретный тип расширения;
• extension_data содержит информацию, относящуюся к конкретному типу расширения. Определены следующие типы расширений:

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), 
    trusted_ca_keys(3), truncated_hmac(4), 
    status_request(5), (65535)
} ExtensionType;

Заметим, что для всех типов расширений (включая и те, которые будут определены в дальнейшем) тип расширения не должен появляться в расширенном Server Hello, пока не появится в соответствующем Client Hello. Таким образом, клиенты должны прерывать Рукопожатия, если получили расширенный тип в расширенном Server Hello, который не был запрошен в соответствующем Client Hello.

Расширения, инициируемые сервером (server initiated), могут присутствовать в будущем в рамках данного протокола, при этом требуется, чтобы клиент первым посылал пустое расширение, указывая тем самым, что он готов принимать подобное расширение.

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

Наконец, заметим, что все расширения, определенные в настоящий момент, относятся только к инициализации сессии. Однако клиент, который послал запрос на возобновление сессии, не знает, будет ли принят данный запрос, и, следовательно, должен послать расширенный Client Hello, если это необходимо для новой сессии. Если запрос на возобновление отвергнут, будут вестись переговоры о новом множестве расширений. Если, с другой стороны, старая сессия возобновляется, то сервер должен игнорировать расширения, появившиеся в Client Hello, и послать Server Hello, не содержащий расширений. В этом случае используется расширение, о котором участники договорились при инициализации исходной сессии, возобновлением которой является данная сессия.

Расширения в протоколе Рукопожатия

Поддерживается использование двух новых сообщений Рукопожатия: CertificateURL и CertificateStatus. Новая структура сообщения рукопожатия:

enum {
    hello_request(0), client_hello(1), 
    server_hello(2), certificate(11), 
    server_key_exchange (12),
    certificate_request(13), 
    server_hello_done(14),
    certificate_verify(15), 
    client_key_exchange(16),
    finished(20), certificate_url(21), 
    certificate_status(22), (255)
} HandshakeType;
struct {
    HandshakeType msg_type; 
        /* handshake type */
    uint24 length;          
        /* bytes in message */
    select (HandshakeType) {
      case hello_request: HelloRequest;
      case client_hello: ClientHello;
      case server_hello: ServerHello;
      case certificate: Certificate;
      case server_key_exchange: ServerKeyExchange;
      case certificate_request: CertificateRequest;
      case server_hello_done: ServerHelloDone;
      case certificate_verify: CertificateVerify;
      case client_key_exchange: ClientKeyExchange;
      case finished: Finished;
      case certificate_url: CertificateURL;
      case certificate_status: CertificateStatus;
    } body;
} Handshake;