Протокол SSL

Самый известный протокол Интернета – SSL (Secure Socket Layer). Этот протокол был разработан компанией Netscape и является составной частью всех известных Интернет-браузеров и Web-серверов (сегодня используется версия 3.0 протокола SSL). Протокол реализуется между транспортным и сеансовым уровнями эталонной модели взаимодействия открытых систем (OSI). Это, с одной стороны, означает возможность использования протокола для организации защищенной сессии между программами, работающими по различным протоколам прикладного уровня OSI (FTP, SMTP, Telnet, HTTP и т. п.), а с другой – закрытие любых данных, передаваемых в SSL-сессии, что приводит к снижению производительности протокола.

Последняя версия протокола SSL поддерживает три режима аутентификации:

– взаимную аутентификацию сторон;

– одностороннюю аутентификацию сервера (без аутентификации
клиента);

– полную анонимность.

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

В упрощенном виде процедура установления защищенного режима взаимодействия между клиентом и Web-сервером в соответствии с протоколом SSL выглядит следующим образом (рассмотрим вариант односторонней аутентификации сервера со стороны клиента).

Этап установления SSL-сессии («рукопожатие»)

1. КЛИЕНТ посылает СЕРВЕРУ запрос (Client hello) на установление защищенного соединения, в котором передает некоторые формальные параметры этого соединения:

– текущее время и дату;

– случайную последовательность (RAND_CL) длиной 28 байтов;

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

– набор поддерживаемых алгоритмов сжатия (все реализации протокола SSL должны поддерживать метод Compression Method null).

Следует отметить, что КЛИЕНТ имеет возможность в запросе указать идентификатор SSL-сессии, которая была установлена ранее или поддерживается в настоящий момент времени. В этом случае процедура согласования параметров для устанавливаемой сессии не требуется (используются параметры, согласованные для сессии с указанным в запросе идентификатором SSL‑сессии).

Кроме того, инициировать SSL-сессию может и Web-CEPBEP. Для этого СЕРВЕР может в любой момент времени направить КЛИЕНТУ сообщение Hello request, которое информирует КЛИЕНТА о том, чтобы он направил СЕРВЕРУ сообщение Client Hello.

2. СЕРВЕР обрабатывает запрос от КЛИЕНТА и в ответном сообщении (Server hello) передает ему следующий согласованный набор параметров:

– идентификатор SSL-сессии;

– конкретные криптографические алгоритмы из числа предложенных клиентом (если по какой-либо причине предложенные алгоритмы или их параметры не удовлетворяют требованиям сервера, сессия закрывается);

– сертификат сервера, заверенный цифровой подписью ЦС (в формате Х.509 v.3);

– случайную последовательность (RAND_SERV);

– цифровую подпись для перечисленных выше данных.

3. КЛИЕНТ проверяет полученный сертификат СЕРВЕРА с помощью открытого ключа ЦС, который ему известен; при положительном результате проверки КЛИЕНТ выполняет следующие действия (при отрицательном результате проверки сессия закрывается):

– генерирует случайную 48-байтную последовательность Pre_MasterSecret (часть совместного секрета, известного только СЕРВЕРУ и КЛИЕНТУ); шифрует ее на открытом ключе сервера, полученном в сертификате сервера, и посылает СЕРВЕРУ;

– с помощью согласованных хэш-алгоритмов формирует главный совместный секрет (MasterSecret), используя в качестве параметров часть совместного секрета Pre_MasterSecret, посланную СЕРВЕРУ на предыдущем шаге случайную последовательность RAND_CL и полученную от него случайную последовательность RAND_SERV;

– используя MasterSecret, вычисляет криптографические параметры
SSL-сессиии: формирует общие с сервером сеансовые секретные ключи симметричного алгоритма шифрования (для приема и для передачи) и секреты для вычисления MAC;

– переходит в режим защищенного взаимодействия.

4. СЕРВЕР расшифровывает полученный Pre_MasterSecret с помощью своего секретного ключа и выполняет над ним те же операции, что и КЛИЕНТ:

– с помощью согласованных хэш-алгоритмов формирует главный совместный секрет (MasterSecret), используя в качестве параметров Pre_MasterSecret посланную КЛИЕНТУ на предыдущем шаге случайную последовательность RAND_SERV и полученную от него случайную последовательность RAND_CL;

– используя MasterSecret, вычисляет криптографические параметры
SSL-сессии: формирует общие с клиентом сеансовые секретные ключи одноключевого алгоритма шифрования и секрет для вычисления MAC;

– переходит в режим защищенного взаимодействия.

Поскольку при формировании параметров SSL-сессии КЛИЕНТ и СЕРВЕР пользовались одними и теми же исходными данными (согласованными алгоритмами, общим секретом Pre_MasterSecret и случайными последовательностями RAND_CL и RAND_SERV), то очевидно, что в результате описанных выше действий они выработали одинаковые сеансовые секретные ключи шифрования и секреты, используемые для защиты целостности передаваемых сообщений.

5. Для проверки идентичности параметров SSL-сессии КЛИЕНТ и СЕРВЕР посылают друг другу тестовые сообщения, содержание которых известно каждой из сторон:

– КЛИЕНТ формирует сообщение из собственных посылок в адрес СЕРВЕРА на этапе 1 и посылок, полученных от СЕРВЕРА на этапе 1, внося элемент случайности в виде последовательности MasterSecret, уникальной для данной сессии; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет СЕРВЕРУ;

– СЕРВЕР, в свою очередь, формирует сообщение из собственных посылок в адрес СЕРВЕРА на этапе 1, посылок, полученных от КЛИЕНТА на этапе 1, и последовательности MasterSecret; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет КЛИЕНТУ;

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

Этап защищенного взаимодействия с установленными
криптографическими параметрами SSL-сессии

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

2. Каждая сторона при приеме сообщения расшифровывает его и проверяет на целостность (вычисляется MAC и сверяется с кодом проверки целостности, полученным вместе с сообщением); в случае обнаружения нарушения целостности сообщения SSL-сессия закрывается.

Описанная процедура установления SSL-сессии, безусловно, не обладает полнотой изложения, однако дает представление о возможностях
протокола SSL.

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

Для защиты трафика в Интернете помимо протокола SSL используется протокол S-HTTP (Secure HTTP). Этот протокол обеспечивает целостность и защиту документов, передаваемых по протоколу HTTP. В отличие от протокола SSL, расположенного между транспортным уровнем (TCP) и протоколами сеансового уровня, протокол S-HTTP находится на прикладном уровне OSI, что позволяет с его помощью защищать не транспортное соединение, а данные, передаваемые по соединению. Это повышает производительность протокола защиты информации, но ценой ограничения применимости механизма защиты только приложением HTTP.

Достоинства протокола:

1. Широкое распространение протокола SSL, которое объясняется в первую очередь тем, что он является составной частью всех известных Интернет-браузеров и Web-серверов. Это означает, что фактически любой владелец карты, пользуясь стандартными средствами доступа к Интернету, получает возможность провести транзакцию с использованием SSL;

2. Простота протокола для понимания всех участников ЭК;

3. Хорошие операционные показатели (скорость реализации транзакции). Последнее достоинство связано с тем, что протокол в процессе передачи данных использует только симметричные протоколы шифрования.

Недостатками протокола SSL в приложении к ЭК являются:

1. Отсутствие аутентификации клиента Интернет-магазином, поскольку сертификаты клиента в протоколе почти не используются. Использование «классических» сертификатов клиентами в схемах SSL является делом практически бесполезным. Такой «классический» сертификат, полученный клиентом в одном из известных центров сертификации, содержит только имя клиента и, что крайне редко, его сетевой адрес.

2. Протокол SSL не позволяет аутентифицировать клиента обслуживающим банком.

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

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

5. При использовании SSL не обеспечивается конфиденциальность данных о реквизитах карты для ТП.