Протокол защищенных каналов SSL

    RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1];

    IS-ESCAPE = (byte[0] & 0x40) != 0;

    PADDING = byte[2];

    Заголовок рекорда определяет значение, называемое PADDING. Значение PADDING специфицирует число  байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра, если применен блочный шифр.

    Отправитель "заполненного" рекорда добавляет  заполнитель после имеющихся  данных, а затем шифрует все  это, благо длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема субполя PADDING.

    Получатель  этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данные удаляется.

              * Формат информационных записей SSL

    Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном  ниже порядке):

MAC-DATA[MAC-SIZE] 
ACTUAL-DATA[N] 
PADDING-DATA[PADDING]

    ACTUAL-DATA представляет собой реальные  переданные данные (поле данных  сообщения). PADDING-DATA – это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).

    Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

    MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]

    Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый  код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - "big endian").

    MAC-SIZE является функцией используемого  алгоритма вычисления дайджеста.  Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

    Значение SECRET зависит оттого, кто из партнеров  посылает сообщение. Если сообщение  посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).

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

    Получатель  сообщения использует ожидаемое  значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

    Окончательная проверка соответствия выполняется, когда  используется блочный шифр и соответствующий  протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным  размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).

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

    Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для  трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.

    Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO. 

    1.3. Спецификация протокола  диалога SSL

              * Протокол диалога  SSL

    Протокол  диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.

    Фаза 1

    Первая  фаза является фазой инициализации  соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

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

    Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров, и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

    Здесь следует заметить, что каждая оконечная  точка SSL использует пару шифров для  каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

    Наконец, после того как мастерный ключ определен, сервер посылает клиенту  сообщение SERVER-VERIFY. Этот заключительный шаг аутентифицирует сервер, так как только сервер, который имеет соответствующий общедоступный ключ, может знать мастерный ключ.

    Фаза 2

    Вторая  фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь  осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

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

              * Типовой протокол обмена сообщениями

    В несколько упрощенном варианте диалог SSL представлен на рис.1. 

    

    Рис.1. Алгоритм работы SSL

    Ниже  представлено несколько вариантов  обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Запись вида "{X}key" означает, что “X” зашифровано с помощью ключа "key". 

    Табл.1. Обмен сообщениями  при отсутствии идентификатора сессии

    Табл.2. Обмен сообщениями  в случае, когда  идентификатор сессии найден клиентом и  сервером

 

    Табл.3. Обмен сообщениями  при использовании  идентификатора сессии и аутентификации клиента

 

    В последнем обмене, response_data является функцией auth_type.  

              * Обработка ошибок

    Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента  и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки:

    NO-CIPHER-ERROR

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

    NO-CERTIFICATE-ERROR

    Когда послано сообщение REQUEST-CERTIFICATE, эта  ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.

    BAD-CERTIFICATE-ERROR

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