Что такое SSL?

Число

Все данные, представляемые в протоколе записываются в прямом порядке байт. То есть

value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... | byte[n-1];

Вектор

Запись вида

T T'[n];

означает определение нового типа T', который является вектором значений типа T фиксированной длины n. При этом n - количество байт, занимаемых новым типом T'.

Пример:

opaque Datum[3]; /* Три байта, не интерпретируемые протоколом */
Datum Data[9]; /* 9-байтный вектор значений типа Datum.*/

/*
На C эта запись выглядела бы так:

typedef opaque[3] Datum;
Datum Data[3];
*/

Существует такое понятие как вектор переменной длины. Определение нового типа T' - вектор переменной длины от K до N байт, содержащий значения типа T.

T T'<K..N>

При кодировании таких векторов дополнительно приписывается его текущая длина. Записывается она в виде числа из M байт, где M - число байт, достаточных для хранения числа, отражающего максимальную длину вектора в байтах. Например:

opaque mandatory<300..400>;
 /* вектор не менее 300, но не более 400 байт. Длина записывается числом в 2 байта (достаточно для
 хранения числа 400.*/
uint16 longer<0..800>
 /* вектор чисел типа uint16 с максимальной длиной в 800 байт (то есть может содержать не более
 400 элементов типа uint16. Может быть пустым. Длина записывается числом в 2 байта.*/

Базовый тип данных - uint8. Определены также

uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];

В случае представления целого числа в виде вектора байт он представляется как без знаковое целое без лидирующего ноля.

Перечисление

Аналогично языку си:

enum { e1(v1), e2(v2), ..., en(vn) [[, (k)]] } Te;

Соответственно объем, занимаемый одним значением типа "перечисление", равен числу байт, необходимых для хранения максимального значения перечисления.

Пример:

enum { red(3), green(23), blue(1) } Color;

Color color = Color.blue;
Color color = blue;

Для перечислений, которые никогда не интерпретируются своими значениями последние можно опустить. Например:

enum{ low, medium, high } Amount;

Структура

Аналогично языку си:

struct {
        T1 t1;
        T2 t2;
        ...
        Tn tn;
} [[T]];

Вариант

Поля структуры могут варьироваться в соответствии с каким-либо перечислимым типом.

enum { e1, e2, ..., ek } E;
struct P
        T1 t1;
        T2 t2;
        ...
        Tn tn;
        select (E) {
                case e1: Te1;
                case e2: Te2;
                case e3: case e4: Te3;
                ...
                case en: Ten;
        } [[fv]];
} [[Tv]];

Например, мы можем определить структуру транспорт с полями "скорость движения" и "количество мест". Если это автомобиль, то структура будет содержать поле "объем двигателя", а для велосипеда определим "количество скоростей".

enum { auto, bicycle } TransportType;

struct Transport {
        int16 speed;
        int8  seats;
        select (TransportType) {
                case auto:
                        int8 engine_capacity;
                case bicycle:
                        int8 gears_count;
        }
}

Цифровая подпись

struct {
        SignatureAndHashAlgorithm algorithm;
        opaque signature<0..2^16-1>;
} DigitallySigned;

Пустой или стандартный потоковый шифр

stream-ciphered struct {
        opaque Content[TLSCompressed.length];
        opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;

Имитовставка генерируется следующим образом:

  MAC(MAC_write_key, seq_num
          + TLSCompressed.type
          + TLSCompressed.version
          + TLSCompressed.length
          + TLSCompressed.fragment
  );

"+" - это конкатенация

Блочное шифрование

struct {
        /*** вектор инициализации ***/
        opaque IV(SecurityParameters.record_iv_length];
        block-ciphered struct {
                opaque content[TLSCompressed.length];
                opaque MAC[SecurityParameters.mac_length];
                uint8 padding[GenericBlockCipher.padding_length];
                uint8 padding_length;
        };
} GenericBlockCipher;

0x## 0x06 0x06 0x06 0x06 0x06 0x06 0x06

0x## - последний байт имитовставки

AEAD шифры

Аутентифицирующее шифрование (см. RFC-5116 Authenticated Encryption with Associated Data) - форма шифрования при которой в дополнение к обеспечению конфиденциальности открытого текста, предоставляется возможность проверки целостности и подлинности. Authenticated Encryption with Associated Data (AEAD) шифрование предоставляет возможность проверки целостности и подлинности некоторых дополнительных данных (также называемых дополнительные подлинные данные), которые не зашифрованы.

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

struct {
        opaque nonce_explicit[SecurityParameters.record_iv_length];
        aead-ciphered struct {
                opaque content[TLSCompressed.length];
        };
} GenericAEADCipher;

дополнительные подлинные данные определяются следующим образом:

additional_data = seq_num + TLSCompressed.type + TLSCompressed.version +
                TLSCompressed.length;

"+" - это конкатенация

Протокол изменения параметров шифрования

Протокол состоит из одного сообщения, которое шифруется и сжимается по текущему (не ожидаемому, а текущему) состоянию. Сообщение состоит из одного байта 0x01.

struct {
        enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

Сообщение ChangeCipherSpec посылается как клиентом, так и сервером. Получатель данного сообщения должен заменить текущее состояние чтения ожидаемым состоянием чтения, а отправитель заменяет ожидаемое состояние записи текущим состоянием записи.

Сообщение ChangeCipherSpec посылается в процессе установления соединения после того как параметры безопасности согласованы, но до посылки подтверждающего сообщения Finished.

Протокол тревоги

Одним из типов содержимого является тип тревоги. Сообщение тревоги содержит важность сообщения и описание. Сообщение важности fatal незамедлительно прерывает соединение. В данном случае может происходить какое-то общение между узлами, но идентификатор сессии становится недействительным. Таким образом, сессия не может использоваться для установления новых соединений. Сообщение тревоги шифруется и сжимается, как и остальные.

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
        close_notify(0),
        unexpected_message(10),
        bad_record_mac(20),
        decryption_failed_RESERVED(21),
        record_overflow(22),
        decompression_failure(30),
        handshake_failure(40),
        no_certificate_RESERVED(41),
        bad_certificate(42),
        unsupported_certificate(43),
        certificate_revoked(44),
        certificate_expired(45),
        certificate_unknown(46),
        illegal_parameter(47),
        unknown_ca(48),
        access_denied(49),
        decode_error(50),
        decrypt_error(51),
        export_restriction_RESERVED(60),
        protocol_version(70),
        insufficient_security(71),
        internal_error(80),
        user_canceled(90),
        no_renegotiation(100),
        unsupported_extension(110),
        (255)
} AlertDescription;

struct {
        AlertLevel level;
        AlertDescription description;
} Alert;

Закрывающие сообщения тревоги

Любая сторона может завершить соединение. Для этого она должна послать close_notify. Сообщение close_notify говорит о том, что отправитель больше не будет посылать сообщений. Перед закрытием соединения (если не происходило каких-то критических ошибок) закрывающая сторона в обязательном порядке должна послать close_notify, получив close_notify необходимо послать его в ответ, хотя закрывающая сторона вовсе не должна его дожидаться.

При получении сообщения тревоги с критической ошибкой соединение закрывается. При получении сообщений типа warning соединение не должно закрываться. Если всё-таки его необходимо по какой-лдибо причине закрыть, необходимо послать сообщение о критической ошибке. Таким образом сообщения warning - не очень-то полезная штука и редко посылаются.

Определены следующие сообщения об ошибках:

TODO:

• unexpected_message

  An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.

• bad_record_mac

  This alert is returned if a record is received with an incorrect MAC. This alert also MUST be returned if an alert is sent because a TLSCiphertext decrypted in an invalid way: either it wasn’t an even multiple of the block length, or its padding values, when checked, weren’t correct. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

• decryption_failed_RESERVED

  This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode [CBCATT]. It MUST NOT be sent by compliant implementations.

• record_overflow

  A TLSCiphertext record was received that had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

• decompression_failure

  The decompression function received improper input (e.g., data that would expand to excessive length). This message is always fatal and should never be observed in communication between proper implementations.

• handshake_failure

  Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a

• no_certificate_RESERVED

  This alert was used in SSLv3 but not any version of TLS. NOT be sent by compliant implementations. It MUST NOT be sent by compliant implementations.

• bad_certificate

  A certificate was corrupt, contained signatures that did not verify correctly, etc.

• unsupported_certificate

  A certificate was of an unsupported type.

• certificate_revoked

  A certificate was revoked by its signer.

• certificate_expired

  A certificate has expired or is not currently valid.

• certificate_unknown

  Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. illegal_parameter A field in the handshake was out of range or inconsistent with other fields. This message is always fatal.

• unknown_ca

  A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn’t be matched with a known, trusted CA. This message is always fatal.

• access_denied

  A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal.

• decode_error

  A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

• decrypt_error

  A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal.

• export_restriction_RESERVED

  This alert was used in some earlier versions of TLS. be sent by compliant implementations. It MUST NOT be sent by compliant implementations.

• protocol_version

  The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal.

• insufficient_security

  Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal.

• internal_error

  An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue. This message is always fatal.

• user_canceled

  This handshake is being canceled for some reason unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning.

• no_renegotiation

  Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert. At that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate is where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup, and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.

• unsupported_extension

  sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello. This message is always fatal.

Добавление новых ошибок производится через IANA.

HelloRequest

Сообщение HelloRequest может быть послано сервером в любой момент. Клиент не обязан отвечать, (а может ответить и no_renegatiation сообщением тревоги), но сервер в таком случае в праве разорвать соединение. Послав HelloRequest сервер должен дождаться какого-то результата процедуры установления соединения.

Структура сообщения:

struct {} HelloRequest;

ClientHello

Структура сообщения:

struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        CipherSuite cipher_suites<2..2^16-2>;
        CompressionMethod compression_methods<1..2^8-1>;
        select (extensions_present) {
                case false:
                        struct {};
                case true:
                        Extension extensions<0..2^16-1>;
        };
} ClientHello;

struct {
        uint32 gmt_unix_time;
        opaque random_bytes[28];
} Random;

opaque SessionID<0..32>;

uint8 CipherSuite[2];

CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };

CipherSuite   TLS_RSA_WITH_NULL_MD5                ={  0x00, 0x01  };
CipherSuite   TLS_RSA_WITH_NULL_SHA                ={  0x00, 0x02  };
CipherSuite   TLS_RSA_WITH_NULL_SHA256             ={  0x00, 0x3B  };
CipherSuite   TLS_RSA_WITH_RC4_128_MD5             ={  0x00, 0x04  };
CipherSuite   TLS_RSA_WITH_RC4_128_SHA             ={  0x00, 0x05  };
CipherSuite   TLS_RSA_WITH_3DES_EDE_CBC_SHA        ={  0x00, 0x0A  };
CipherSuite   TLS_RSA_WITH_AES_128_CBC_SHA         ={  0x00, 0x2F  };
CipherSuite   TLS_RSA_WITH_AES_256_CBC_SHA         ={  0x00, 0x35  };
CipherSuite   TLS_RSA_WITH_AES_128_CBC_SHA256      ={  0x00, 0x3C  };
CipherSuite   TLS_RSA_WITH_AES_256_CBC_SHA256      ={  0x00, 0x3D  };

CipherSuite   TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA     ={   0x00, 0x0D   };
CipherSuite   TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA     ={   0x00, 0x10   };
CipherSuite   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA    ={   0x00, 0x13   };
CipherSuite   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA    ={   0x00, 0x16   };
CipherSuite   TLS_DH_DSS_WITH_AES_128_CBC_SHA      ={   0x00, 0x30   };
CipherSuite   TLS_DH_RSA_WITH_AES_128_CBC_SHA      ={   0x00, 0x31   };
CipherSuite   TLS_DHE_DSS_WITH_AES_128_CBC_SHA     ={   0x00, 0x32   };
CipherSuite   TLS_DHE_RSA_WITH_AES_128_CBC_SHA     ={   0x00, 0x33   };
CipherSuite   TLS_DH_DSS_WITH_AES_256_CBC_SHA      ={   0x00, 0x36   };
CipherSuite   TLS_DH_RSA_WITH_AES_256_CBC_SHA      ={   0x00, 0x37   };
CipherSuite   TLS_DHE_DSS_WITH_AES_256_CBC_SHA     ={   0x00, 0x38   };
CipherSuite   TLS_DHE_RSA_WITH_AES_256_CBC_SHA     ={   0x00, 0x39   };
CipherSuite   TLS_DH_DSS_WITH_AES_128_CBC_SHA256   ={   0x00, 0x3E   };
CipherSuite   TLS_DH_RSA_WITH_AES_128_CBC_SHA256   ={   0x00, 0x3F   };
CipherSuite   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256  ={   0x00, 0x40   };
CipherSuite   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256  ={   0x00, 0x67   };
CipherSuite   TLS_DH_DSS_WITH_AES_256_CBC_SHA256   ={   0x00, 0x68   };
CipherSuite   TLS_DH_RSA_WITH_AES_256_CBC_SHA256   ={   0x00, 0x69   };
CipherSuite   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256  ={   0x00, 0x6A   };
CipherSuite   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256  ={   0x00, 0x6B   };

CipherSuite  TLS_DH_anon_WITH_RC4_128_MD5         =  {  0x00, 0x18  };
CipherSuite  TLS_DH_anon_WITH_3DES_EDE_CBC_SHA    =  {  0x00, 0x1B  };
CipherSuite  TLS_DH_anon_WITH_AES_128_CBC_SHA     =  {  0x00, 0x34  };
CipherSuite  TLS_DH_anon_WITH_AES_256_CBC_SHA     =  {  0x00, 0x3A  };
CipherSuite  TLS_DH_anon_WITH_AES_128_CBC_SHA256  =  {  0x00, 0x6C  };
CipherSuite  TLS_DH_anon_WITH_AES_256_CBC_SHA256  =  {  0x00, 0x6D  };

enum { null(0), (255) } CompressionMethod;

ServerHello

struct {
        ProtocolVersion server_version;
        Random random;
        SessionID session_id;
        CipherSuite cipher_suite;
        CompressionMethod compression_mehtod;
        select (extensions_present ) {
                case false:
                        struct {};
                case true:
                        Extension extemsions<0..2^16-1>;
        };
} ServerHello;

В принципе, понятно как заполняется указанная структура. Некоторые замечания:

• session_id

  Если сервер вернёт нулевой session_id, это будет означать, что сессия не может быть продолжена.

• cipher_suite, compression_mehtod

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