6.5. Протокол SSL. Безопасный уровень соединителей

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. http://www.netscape.com/eng/security/SSL_2.html). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).

Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения, такие как HTTP, FTP, TELNET и т.д. могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того как приложение примет или передаст первый байт данных. Все протокольные прикладные данные передаются зашифрованными с гарантией конфиденциальности.

Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:

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

• Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.

• Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

6.5.1. Спецификация протокола записей SSL 6.5.1.1. Формат заголовка записи SSL

В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола).

Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация):

RECORLENGTH = ((byte[0] & 0x7F << 8)) | byte[1];

Где byte[0] представляет собой первый полученный байт, а byte[1] - второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом:

RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) != 0;
PADDING = byte[2];

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

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

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

6.5.1.2. Формат информационных записей 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.

6.5.2. Спецификация протокола диалога SSL 6.5.2.1. Протокол диалога 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 закончил свою работу. С этого момента начинает работать прикладной протокол.

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

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

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

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

6.5.2.2.1. При отсутствии идентификатора сессии

Client-hello	C ® S:	challenge, cipher_specs
server-hello	S ® C:	connection-id,server_certificate,cipher_specs
client-master-key	C ® S:	{master_key}server_public_key
client-finish	C ® S:	{connection-id}client_write_key
server-verify	S ® C:	{challenge}server_write_key
server-finish	S ® C:	{new_session_id}server_write_key

6.5.2.2.2. Идентификатор сессии найден клиентом и сервером

сlient-hello	C ® S:	challenge, session_id, cipher_specs
server-hello	S ® C:	connection-id, session_id_hit
client-finish	C ® S:	{connection-id}client_write_key
server-verify	S ® C:	{challenge}server_write_key
server-finish	S ® C:	{session_id}server_write_key

6.5.2.2.3. Использован идентификатор сессии и аутентификация клиента

сlient-hello	C ® S:	challenge, session_id, cipher_specs
server-hello	S ® C:	connection-id, session_id_hit
client-finish	C ® S:	{connection-id}client_write_key
server-verify	S ® C:	{challenge}server_write_key
request-certificate	S ® C:	{auth_type,challenge'}server_write_key
client-certificate	C ® S:	{cert_type,client_cert, response_data}client_write_key
server-finish	S ® C:	{session_id}server_write_key

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

6.5.2.3. Ошибки

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

NO-CIPHER-ERROR

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

NO-CERTIFICATE-ERROR

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

BAD-CERTIFICATE-ERROR

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

UNSUPPORTED-CERTIFICATE-TYPE-ERROR

Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента).

6.5.2.4. Сообщения протокола диалога SSL

Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит, после того как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:

char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA[(MSB<<8)|LSB];
...

Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует порядку перечисления.

Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах.

6.5.2.5. Протокольные сообщения клиента

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

CLIENT-HELLO (Фаза 1; посылается открыто)

char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]

Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.

Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA.

Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов).

Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.

Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем і 16 и Ј 32.

Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо.

CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)

char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]

Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается.

Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.

Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [5]. Информационная часть блока имеет следующий формат:

char SECRET-KEY-DATA[SECRET-LENGTH]

SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.

Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.

Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:

SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]

Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.

Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID.

Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).

SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]

Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEY-ARG-DATA.

SSL_CK_DES_192_EDE3_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]

Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).

Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32).

Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.

Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт.

Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.

CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]

Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATE-TYPE является одним из:

SSL_X509_CERTIFICATE
CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988) [3].

RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.

Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):

• KEY-MATERIAL-0

• KEY-MATERIAL-1 (только если определено типом шифра)

• KEY-MATERIAL-2 (только если определено типом шифра)

• CERTIFICATE-CHALLENGE-DATA (из сообщения REQUEST-CERTIFICATE)

• Сертификат, подписанный сервером (из сообщения SERVER-HELLO).

Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.

Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.

CLIENT-FINISHED (Фаза 2; посылается шифрованным)

char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]

Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.

"N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка.

Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY.

6.5.2.6. Протокольные сообщения сервера

Существует несколько сообщений, которые генерируются только серверами.

SERVER-HELLO (Фаза 1; посылается открыто)

char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]

Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль.

Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE).

Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY.

Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID. SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY:

SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY

Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY).

CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.

CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:

char CIPHER-KIND-0
char CIPHER-KIND-1
char CIPHER-KIND-2
Где CIPHER-KIND равен одному из:

• SSL_CK_RC4_128_WITH_MD5

• SSL_CK_RC4_128_EXPORT40_WITH_MD5

• SSL_CK_RC2_128_CBC_WITH_MD5

• SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

• SSL_CK_IDEA_128_CBC_WITH_MD5

• SSL_CK_DES_64_CBC_WITH_MD5

• SSL_CK_DES_192_EDE3_CBC_WITH_MD5

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

Таблица 6.5.1

Набор	Уровень безопасности	Описание
DES-CBC3-MD5	Очень высокий	Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии
DES-CBC3-SHA	Очень высокий	Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии
RC4-MD5	Высокий	RC4, хэш MD5, 128-битный ключ
RC4-SHA	Высокий	RC4, хэш SHA, 128-битный ключ
RC2-CBC-MD5	Высокий	RC2 в режиме CBC, хэш MD5, 128-битный ключ
DES-CBC-MD5	Средний	DES в режиме CBC, хэш MD5, 56-битный ключ
DES-CBC-SHA	Средний	DES в режиме CBC, хэш SHA, 56-битный ключ
EXP-DES-CBC-SHA	Низкий	DES в режиме CBC, хэш SHA, 40-битный ключ
EXP-RC4-MD5	Низкий	Экспортное качество RC4, хэш MD5, 40-битный ключ
EXP-RC2-CBC-MD5	Низкий	Экспортное качество RC2, хэш MD5, 40-битный ключ
NULL-MD5	-	Без шифрования, хэш MD5, только аутентификация
NULL-SHA	-	Без шифрования, хэш SHA, только аутентификация

Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.

Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.

Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).

Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY.

SERVER-VERIFY (Фаза 1; посылается шифрованным)

char MSG-SERVER-VERIFY
char CHALLENGE-DATA[N-1]

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

"N" равен числу байт в сообщении, которое было послано, таким образом, "N-1" соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка.

Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, который соответствует общедоступному ключу, содержащемуся в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY). Наконец, только сервер, который выполнил корректно извлечение и дешифрование может правильно зашифровать CHALLENGE-DATA. Это, по существу, "доказывает", что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера.

Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает.

Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю) или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED.

SERVER-FINISHED (Фаза 2; посылается зашифрованным)
char MSG-SERVER-FINISHED
char SESSION-ID-DATA[N-1]

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

Здесь "N" имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVER-VERIFY.

REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]

Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной і 16 байт и Ј 32 байтам), которую клиент использует для отклика на этот запрос.

Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:

• SSL_AT_MD5_WITH_RSA_ENCRYPTION

Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE.

Это сообщение может быть послано после сообщения SERVER-VERIFY и до сообщения SERVER-FINISHED.

6.5.2.7. Протокольные сообщения Клиент/Сервер

Эти сообщения генерируются как клиентом, так и сервером.

ERROR (посылается открыто или зашифровано)

char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB

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

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

Приложение A. ASN.1 синтаксис сертификатов

Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [1]):

X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }

CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,

serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }

Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }

SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }

AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL }
Для целей SSL наложены ограничения на некоторые значения полей X.509:

• Поля X.509-Certificate::signatureAlgorithm и CertificateInfo::signature должны иметь идентичные значения.

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

Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется.

Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.

Приложение B. Идентификаторы объектов и типов атрибутов

SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.

B.1. Выбранные типы атрибутов

commonName { attributeType 3 }	Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата.
countryName { attributeType 6 }	Название страны.
localityName { attributeType 7 }	Название местоположения.
stateOrProvinceName { attributeType 8 }	Название штата или провинции.
organizationName { attributeType 10}	Название организации.
organizationalUnitName { attributeType 11 }	Название подразделения.

B.2. Идентификаторы объекта

md2withRSAEncryption { ... pkcs(1) 1 2 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата.

md5withRSAEncryption { ... pkcs(1) 1 4 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата.

rc4 { ... rsadsi(113549) 3 4 }

Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.

Приложение C. Значения протокольных констант

Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443.

C.1. Коды версии протокола

#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002

C.2. Коды протокольных сообщений

Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL.

#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
#define SSL_MT_REQUEST_CERTIFICATE 7
#define SSL_MT_CLIENT_CERTIFICATE 8

C.3. Коды сообщений об ошибках

Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR.

#define SSL_PE_NO_CIPHER 0x0001
#define SSL_PE_NO_CERTIFICATE 0x0002
#define SSL_PE_BAD_CERTIFICATE 0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006

C.4. Значения вида шифра

Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO.

#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0

C.5. Коды типа сертификата

Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE.

#define SSL_CT_X509_CERTIFICATE 0x01

C.6. Коды типов аутентификации

Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE.

#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01

C.7. Верхние/нижние ограничения

Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров.

#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767
#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383

Приложение D: Атаки

В данном разделе описываются различные атаки, которые могут быть предприняты против протокола SSL. Этот перечень не может считаться исчерпывающим. SSL показал устойчивость к этим атакам.

D.1. Раскрытие шифров

SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA [5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным.

Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.

D.2. Атака открытого текста

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

Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.

Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно время емкий процесс.

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

Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера".

D.3. Атака отклика

Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента.

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

Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 2⁶⁴ кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

D.4. Человек посередине

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

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

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

Приложение E: Термины

Прикладной протокол
Прикладным протоколом является протокол, работающий поверх TCP/IP. Например: HTTP, TELNET, FTP и SMTP.

Массовый шифр
Массовые шифры используются, когда нужно за ограниченное время зашифровать/дешифровать большой объем данных. Примерами могут служить RC2, RC4 и IDEA.

Клиент
Клиентом считается приложение субъекта, который инициирует соединение с сервером.

CLIENT-READ-KEY Ключ сессии, который использует клиент для инициализации своего шифра чтения. Этот ключ имеет то же значение, что и SERVER-WRITE-KEY.

CLIENT-WRITE-KEY
Ключ сессии, который использует клиент для инициализации своего шифра записи. Этот ключ имеет то же значение, что и SERVER-READ-KEY.

Мастерный ключ
Мастерный ключ, который используется клиентом и сервером для формирования всех ключей сессий. CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY генерируются на основе MASTER-KEY.

MD2

MD2 [8] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Эта функция является предшественницей MD5 [7] [9].

MD5

MD5 [7] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Функция имеет свойства, которые делают ее полезной при обеспечении конфиденциальности, главное из этих свойств - невозможность обратимости.

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

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

Шифрование общедоступным ключом
Шифрование общедоступным ключом представляет собой метод асимметричного шифрования. Система с общедоступным ключом использует два ключа: общедоступный и секретный, которые образуют нерасторжимую пару. Сообщения шифруются общедоступным ключом, а дешифруются секретным. И наоборот, сообщения, зашифрованные секретным ключом, могут быть дешифрованы общедоступным ключом. Шифрование общедоступным ключом требует больших вычислительных ресурсов и по этой причине мало пригодно для массового шифрования.

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

RC2, RC4
Массовые шифры, изобретенные RSA. RC2 является блочным шифром, а RC4 - поточным.

Сервер

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

Шифр сессии

Шифр сессии является массовым шифром, который пригоден для шифрования или дешифрования произвольного объема данных. Шифры сессии используются в основном по причинам их высоких эксплуатационных характеристик (прежде всего, имеется в виду быстродействие). Шифры сессии, используемые этим протоколом, симметричны. Симметричные шифры предполагают применение одного и того же ключа, как для шифрования, так и дешифрования.

Идентификатор сессии

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

Ключ сессии
Ключ шифра сессии. В SSL существует четыре ключа, которые называются ключами сессии: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY.

SERVER-READ-KEY
Ключ сессии, который используется сервером для инициализации шифра чтения сервера. Этот ключ имеет то же значение что и CLIENT-WRITE-KEY.

SERVER-WRITE-KEY
Ключ сессии, который используется сервером для инициализации шифра записи сервера. Этот ключ имеет то же значение что и CLIENT-READ-KEY.

Симметричный шифр
Симметричный шифр используется как для шифрования, так и для дешифрования. Примерами симметричных шифров могут служить: IDEA, RC2, RC4.

Ссылки

[1]	CCITT. Recommendation X.208: "Specification of Abstract Syntax Notation One (ASN.1). 1988.
[2]	CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[3]	CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.
[4]	CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988.
[5]	RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.
[6]	RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993.
[7]	R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.
[8]	R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992.
[9]	B. Schneier. Applied Cryptography: Protocols, Algorithms, и Source Code in C, Published by John Wiley & Sons, Inc. 1994.
[10]	M. Abadi и R. Needham. Prudent engineering practice for cryptographic protocols. 1994.

Патентное заявление

Эта версия протокола SSL базируется на использовании патентованной технологии шифрования с общедоступным ключом, которая служит для аутентификации и шифрования/дешифрования. Процесс стандартизации в Интернет, определенный в RFC 1310, требует письменного заявления от владельца патента, что лицензия предоставляется пользователям на определенных, приемлемых условиях, прежде чем рекомендации будет одобрены в качестве предложения, проекта или стандарта Интернет.

Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты:

Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770
Устройство и метод для криптографии с общедоступным ключом (Hellman-Merkle) No. 4,218,582
Криптографическая коммуникационная система и метод (RSA) No. 4,405,829
Устройство и метод экспоненциальной криптографии (Hellman-Pohlig) No. 4,424,414

Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля.

Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority).

Назад: 6.4.10. Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
Оглавление: Телекоммуникационные технологии
Вперёд: 6.6. Безопасное ядро (SSH)