Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Государственное образовательное учреждение
высшего профессионального образования
Московский государственный институт электроники и математики
(Технический университет)
Кафедра Информационной
безопасности
Защита данных, передаваемых по сети Internet,
с использованием протокола SSL
Методические указания по курсу
"Криптографические протоколы"
Москва 2011
Составители: Т.А. Билык
канд. техн. наук А.Б. Лось
канд. физ.-мат. наук М.И. Рожков
УДК 681.327
М82
Защита данных, передаваемых по сети Internet, с использованием протокола
SSL (Secure Sockets Layer): Метод. указания по курсу «Криптографические протоколы» / Моск. гос. ин-т электроники и математики; Сост.: Т.А. Билык, А.Б. Лось, М.И. Рожков, М., 2011. - 29 с.
Методические указания содержат описание протокола SSL. Рассмотрены возможности использования различных механизмов криптографической защиты данных, предоставляемые данным протоколом. В указаниях содержится описание и порядок выполнения лабораторной работы по использованию протокола SSL для безопасного соединения.
Для студентов старших курсов ФПМ, изучающих методы защиты информации.
ISBN 978-5-94506-284-9
1. Введение
Протокол SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) был разработан компанией Netscape Communications в 1994 году для защиты данных, передаваемых по сети Internet. Версия протокола 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые в конечном счете привели к созданию версии 3.0, выпущенной в 1996 году. Впоследствии версия SSL 3.0 послужила основой для создания протокола TLS 1.0. Стандарт протокола TLS 1.0 впервые был определен в RFC 2246 в январе 1999 года. В настоящее время существует протокол TLS v. 1.2, описанный в RFC 5246. Далее в тексте термин «SSL» будет относиться к версии 3. В конце приводятся основные отличия последующих версий протокола TLS.
2. Цели использования SSL
3. Применение SSL
4. Общее описание протокола SSL
SSL имеет двухуровневую организацию. На первом (нижнем) уровне, опирающемся на транспортный сервис, который предоставляет TCP, располагается Протокол передачи данных (SSL Record Protocol), на втором (верхнем) - Протокол установления соединения (SSL Handshake Protocol), Протокол смены параметров безопасности (change cipher spec protocol) и Протокол оповещения (alert protocol) (рис. 2).
Протокол установления соединения предоставляет Протоколу передачи данных параметры безопасности, такие как используемые алгоритмы шифрования, кода аутентификации сообщения, секретные ключи. Он также подтверждает, если необходимо, подлинность сервера клиенту и/или подлинность клиента серверу. SSL поддерживает три типа аутентификации: аутентификация обеих сторон (клиент — сервер), аутентификация только сервера и полная анонимность. Анонимный сервер не может аутентифицировать клиент. Если аутентификация обеих сторон не проводится, то такая схема уязвима к атаке "человек посередине". Для аутентификации одной из стороны, она должна предоставить другой стороне сертификат, подписанный цепочкой сертификатов, ведущей к доверенному центру сертификации.
Протокол смены параметров безопасности используется, чтобы передавать сигналы для подготовки к защищенному обмену данными с использованием новых параметров.
После установления соединения SSL предоставляет клиенту и серверу канал для передачи данных по Протоколу передачи данных, обеспечивающему их конфиденциальность и целостность.
Протокол оповещения необходим для информирования об ошибках.
5. Понятие сессии и соединения
SSL отличает соединение от сессии. Сессия - связь между клиентом и сервером. Сессия создается по Протоколу установления соединения и определяет множество параметров безопасности, которые могут использоваться в рамках нескольких соединений. Цель создания сессии – уменьшить объем вычислений параметров безопасности для каждого соединения. После установления SSL сессии между клиентом и сервером информация об этом соединении заносится в кэш в защищенной памяти для ускорения последующих процедур согласования протокола SSL. При этом несколько соединений между клиентом и сервером могут использовать одну сессию, что уменьшает объем вычислений. При возобновлении соединения SSL клиент и сервер проверяют наличие доступа к уникальной информации по укрощенному Протоколу установления соединения без применения секретного и открытого ключей. Если обе системы предоставят доказательства наличия доступа к этой информации, будут созданы новые симметричные ключи и соединение SSL возобновится. Кэшированная информация соединений TLS версии 1.0 и SSL версии 3.0 будет удалена из защищенной памяти по истечении 24 часов.
После того как сессия установлена, сервер и клиент имеют следующую общую информацию:
Для сервера и клиента, чтобы начать обмен данными, установление сессии необходимо, но не достаточно, они должны создать между собой соединение. Для этого они обмениваются двумя случайными числами и создают, используя главный секретный ключ, ключи и параметры, необходимые для обмена сообщениями, включая установление их подлинности и обеспечение конфиденциальности. Таким образом, соединение – является транспортом (по модели OSI), предоставляющим необходимый набор сервисов.
В сессии одна сторона играет роль клиента, а другая - роль сервера. При соединении обе стороны имеют равные роли, они равны по уровню. Сессия может состоять из нескольких соединений. Соединение может быть завершено и восстановлено в пределах одной и той же сессии. Когда соединение завершено, обменивающиеся стороны могут также закончить сессию, но необязательно. Сессия может быть приостановлена и продолжена снова.
В процессе создания соединения устанавливаются следующие параметры:
6. Используемые криптографические алгоритмы
6.1 Алгоритмы шифрования передаваемых данных
SSL может шифровать данные по следующим алгоритмам:
Все эти алгоритмы шифрования используют 8-байтовый вектор инициализации (IV), кроме Fortezza, который применяет 20 байтный вектор инициализации.
6.2 Алгоритмы вычисления хэш-функции
SSL может работать с использованием следующих алгоритмов вычисления хэш-функции:
6.3 Алгоритмы кода аутентификации сообщения
Алгоритм кода аутентификации сообщения получает на вход текст и секретный ключ и на выходе выдает имитовставку фиксированной длины. Отправитель направляет сообщение и его имитовставку, получатель заново вычисляет имитовставку для полученного сообщения и сверяет с полученной от отправителя. Если значения совпали, то проверка прошла успешно. Так как имитовставка зависит от секретного неизвестного злоумышленнику ключа, код аутентификации сообщения гарантирует не только целостность передаваемых данных, как обычная хэш-функция, но и подтверждает подлинность этих данных, т.е. защищает как от случайных искажений данных, так и от преднамеренных внесений изменений или подмен.
В SSL используется следующий алгоритм кода аутентификации сообщения:
hash(MAC_key || pad_2 ||
hash(MAC_key || pad_1|| seq_num ||SSL Compressed.type ||
SSLCompressed.length || SSLCompressed.fragment)),
где MAC_key – секретный ключ кода аутентификации сообщения;
hash – алгоритм вычисления хэш-функции (MD5 или SHA-1);
pad_1 – строка байт 0x36=0011 0110. Для MD5 – длины 48 байт, для SHA-1 – 40 байт;
pad_2 – строка байт 0x5C=0101 1100. Для MD5 – длины 48 байт, для SHA-1 – 40 байт;
seq_num – порядковый номер сообщения;
SSLCompressed.type – используемый протокол сжатия;
SSLCompressed.length – длина текста после сжатия;
SSLCompressed.fragment – текст после сжатия (если сжатие не используется, то сам текст).
Данный алгоритм весьма схож с алгоритмом HMAC (The Keyed–Hash Message Authentication Code), стандартизированным NIST (National Institute of Standards). Основное различие состоит в том, что в данном алгоритме (для SSLv3) байтовые строки pad_1 и pad_2 соединяются с секретным ключом MAC_key операцией конкатенация, вместо этого в HMAC используется операция XOR для сложения по модулю 2 секретным ключа MAC_key с байтовыми строками pad_1 и pad_2. Дело все в том, что в SSL используется изначальный проект стандарта HMAC, где использовалась операция конкатенация. Конечная же версия алгоритма HMAC, описанная в RFC 2104, использует XOR.
6.4 Алгоритм распределения ключей
Как будет показано далее для обеспечения подлинности и конфиденциальности передаваемых между клиентом и сервером данных необходимо четыре ключа и два вектора инициализации. Однако чтобы создать их, между клиентом и сервером должен быть установлен один предварительный главный секретный ключ (pre-master_secret). Для выработки это ключа SSL может использовать следующие алгоритмы:
Далее подробно рассматривается каждый алгоритм в отдельности, кроме Fortezza, так как данный алгоритм довольно сложен и начиная с TLS v1.0 не поддерживается.
6.4.1 Диффи-Хеллман
Используется классический алгоритм распределения ключей Диффи-Хеллмана.
Рассмотрим преобразование , где - поле из q элементов.
Обозначим a – примитивный элемент. Пусть .
Минусом использования данного алгоритма является то, что он подвержен атаке "человек посередине" (man-in-the-middle).
В связи с тем, что на шагах 1 и 2 отправляемые значения не аутентифицируются, злоумышленник может перехватить направляемые клиентом и сервером значения и , сгенерировать поддельный ключи клиента и сервера и и направить значения и серверу и клиенту соответственно. Таким образом, злоумышленник сможет перехватывать и расшифровывать все сообщения идущие от клиента (используя ключ ) и от сервера (используя ключ ).
6.4.2 Кратковременный Диффи-Хеллман
Открытые параметры алгоритма Диффи-Хеллмана меняются (например, новые параметры могут выбираться для каждой новой сессии). Это делает алгоритм более устойчивым к атакам полного перебора.
Отправляемые значения и подписываются ЭЦП на секретном ключе отправителя по алгоритму RSA, благодаря чему данный алгоритмы распределения ключей стоек к атаке "человек посередине".
Минусом данного алгоритма является необходимость распределения сертификатов открытых ключей для проверки ЭЦП.
6.4.3 Фиксированный Диффи-Хеллман
Клиент и сервер выбирают фиксированные значения a, p, заранее вычисляют и и помещают результат в сертификаты, заверенные Центром сертификации. Далее обмен осуществляется этими сертификатами. При таком обмене сообщения смены ключей не передаются, а происходит только обмен сертификатами.
Данная схема стойка к атаке "человек посередине", но требует создания и распределения сертификатов открытых ключей.
6.4.4 Шифрование RSA
Рассмотрим кольцо вычетов по модулю n, , где p, q - различные большие числа.
Обозначим e – экспонента зашифрования RSA известная клиенту и серверу (открытый ключ), d – экспонента расшифрования RSA известная только серверу (закрытый ключ) такие, что , где – функция Эйлера.
6.4.5 Шифрование и ЭЦП RSA
Обозначим e – открытый ключ RSA, известный серверу и клиенту, d – секретный ключ RSA, известный серверу.
Для реализации данного и предыдущего алгоритмов необходимо для сервера выработать пару открытый - секретный ключ и направить клиенту сертификат с открытым ключом сервера.
7. Детальное описание SSL
7.1 Протокол установления соединения
Шаг 1. Установка настроек безопасности. На данном шаге определяется версия используемого протокола SSL, алгоритмы шифрования и сжатия, ID сессии и начальные случайные числа клиента и сервера.
Шаг 2. Аутентификация сервера и передача ключей. Работа на данном шаге отличается в зависимости от используемого алгоритма распределения ключей (см. п.6.4)
Для алгоритмов (2), (4), (5) в сообщении направляется цепочка сертификатов в формате стандарта X.509.
Для алгоритма (3) - открытые параметры сервера для алгоритма Диффи-Хеллмана, подписанные ЭЦП.
Для алгоритма (1) оно содержит открытые параметры сервера для алгоритма Диффи-Хеллмана.
Для алгоритма (2) оно содержит открытые параметры сервера для алгоритма Диффи-Хеллмана, подписанные ЭЦП.
Для алгоритма (5) оно содержит временный открытый ключ сервера для алгоритма RSA, подписанный ЭЦП.
Шаг 3. Аутентификация клиента и передача ключей. Работа на данном шаге отличается в зависимости от используемого алгоритма распределения ключей (см. п.6.4)
Для алгоритма (1) оно содержит открытые параметры клиента для алгоритма Диффи-Хеллмана.
Для алгоритма (2) оно содержит открытые параметры клиента для алгоритма Диффи-Хеллмана, подписанные ЭЦП.
Для алгоритмов (4), (5) оно содержит предварительный главный секретный ключ, зашифрованный на открытом ключе сервера по алгоритму RSA (для (4) – на постоянном ключе RSA, для (5) – на временном ключе RSA).
На рисунке представлены варианты взаимодействия на 2 и 3 шагах алгоритма установления соединения при использовании различных алгоритмов установления соединения.
По завершении шага 3 клиент и сервер получают/вычисляют предварительный главный секретный ключ pre_master_secret, с помощью которого вычисляется главный секретный ключ длины 48 байт по формуле
master_secret = MD5(pre_master_secret || SHA('A' || pre_master_secret || ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHA('BB' || pre_Master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHA('CCC' || pre_Master_secret ||
ClientHello.random || ServerHello.random)).
Из главного секретного ключа вычисляется последовательность для получения шести ключей различной длины (секретный ключ для вычисления MAC для отправляемых сервером данных, секретный ключ для вычисления MAC для отправляемых клиентом данных, секретный ключ и начальный вектор инициализации IV для шифрования на стороне сервера, секретный ключ и начальный вектор инициализации IV для шифрования на стороне клиента) по следующему алгоритму:
key_block = MD5(pre_master_secret || SHA('A' || pre_master_secret ||
ServerHello.random || ClientHello.Random)) ||
MD5(pre_master_secret || SHA('BB' || pre_Master_secret ||
ServerHello.random || ClientHello.Random)) ||
MD5(pre_master_secret || SHA('CCC' || pre_Master_secret ||
ServerHello.random || ClientHello.Random)) || …
Далее из полученной последовательности извлекаются ключи и начальные векторы как показано на рис. 3.
Шаг 4. Смена параметров шифрования и завершение процедуры установки соединения. Фактически на данном шаге реализуется Протокол смены параметров безопасности, который детально обсуждается в п. 7.3.
MD5(master_secret || pad_2 || MD5(handshake_messages || Sender || master_secret || pad_1)) ||
SHA(master_secret || pad_2 || SHA(handshake_messages || Sender || master_secret || pad_1)),
где Sender - идентификационный код клиента, handshake_messages - все предыдущие сообщения процедуры установки соединения, кроме данного.
Целью проведения шага 4 является противодействия двум атакам:
7.2 Протокол установления соединения на основе существующей сессии
Процедура установления соединения на основе существующей сессии показана на рис. 4. Обычно новые сеансы и соединения формируются по инициативе клиента, но и сервер может указать клиенту на желательность подобного действия (если, например, пришло время смены криптографических параметров), послав запрос приветственного сообщения HelloRequest.
Как видно из рисунка процедура идентична первому и последнему шагам полного протокола установления соединения. Она более простая и требует проведения гораздо меньше числа вычислений.
При отправке клиентом сообщения Client_hello в нем указывается идентификатор сессии, которую необходимо возобновить.
Сервер ищет его в своем кэше и при возможности возобновляет сеанс, формируя на его основе по сокращенному варианту новое соединение.
7.3 Протокол смены параметров безопасности
В ходе процедуры установления соединения между клиентом и сервером формируются криптографические параметры, в том числе секретные ключи клиента и сервера, однако данные параметры не могут использоваться пока обе стороны не передали и не получили сообщение ChangeCipherSpec. Поэтому у сервера и клиента есть два состояния криптографических параметров – ожидание, когда параметры сохраняются, но не используются, и активное состояние, когда эти параметры используются для шифрования/расшифрования и подписания/проверки подписи передаваемых данных. Кроме того, каждое состояние имеет два множества значений: одно – для входящих данных, другое – для исходящих. Протокол ChangeCipherSpec определяет процесс перемещения значений между состоянием ожидания и активным состоянием.
Когда клиент направляет сообщение ChangeCipherSpec, его криптографические параметры для исходящих данных перемещаются из состояния ожидания в активное. После этого он может использовать эти параметры для шифрования и подписания отправляемых им данных.
После получения сообщения ChangeCipherSpec, сервер помещает криптографические параметры для входящих данных из состояния ожидания в активное, что позволяет ему расшифровывать и проверять на подлинность полученные от клиента данные. Таким образом, сообщение Finished, направляемое клиентом на последнем шаге протокола установления соединения, может быть расшифровано сервером и проверено на подлинность.
После получения от клиента сообщения Finished сервер передает сообщение ChangeCipherSpec и перемещает криптографические параметры для исходящих данных в активное состояние, что позволяет серверу подписывать и шифровать исходящие сообщения.
Клиент, получив от сервера сообщение ChangeCipherSpec, перемещает криптографические параметры для входящих данных в активное состояние, что позволяет ему проверять подлинность и расшифровывать входящие от сервера сообщения. После обмена сообщениями Finished обе стороны могут работать в обоих направлениях, используя активные параметры для чтения/записи.
7.4 Протокол передачи данных
После завершения протокола установления соединения протокол SSL предоставляет серверу и клиенту сервисы для обмена данными и гарантирующие их конфиденциальность и целостность.
Работа протокола передачи данных представлена на рисунке 5. Каждое отправляемое сообщение разбивается на блоки. Каждый блок сжимается и дополняется имитовставкой (длины 0, 16 или 20 байт), вычисленной по алгоритму кода аутентификации сообщения. Результат шифруется и дополняется заголовком SSL.
Заголовок содержит следующие поля:
Тип содержимого (8 бит) – тип вышележащего протокола, используемого для обработки защищаемого фрагмента;
Старшая версия протокола (8 бит) – указывает на старшую используемую версию протокола (для SSLv3 значение равно 3);
Младшая версия протокола (8 бит) – указывает на младшую используемую версию протокола (для SSLv3 значение равно 0);
Длина фрагмента текста после сжатия (если сжатие используется). Максимальное значение 21412048.
7.5 Протокол оповещения
8 Атаки на SSL
На протоколы SSL/TLS могут проводиться следующие типы атак:
9 Различия между SSL и TLS
9.1 Основные отличия TLS v1.0 (RFC 2246)
1. В качестве алгоритма кода аутентификации сообщения используется алгоритм HMAC, описанный RFC 2104, который является более стойким, чем используемый в SSL v.3 (фактически в SSL v.3 в качестве кода аутентификации сообщения используется первый проект алгоритма HMAC, который позже претерпел изменения).
MAC = hash [ ( MAC_key XOR pad_2 ) ||
hash [ ( MAC_key XOR pad_1 ) ||
seq_num || TLS Compressed.type || TLS Compressed.version ||
TLS Compressed.length || TLS Compressed.fragment ]
],
где MAC – имитовставка;
hash – алгоритм вычисления хэш-функции (MD5 или SHA-1);
MAC_key – секретный ключ кода аутентификации сообщения, дополненный нулями до длины входного блока хэш-функции;
pad_1 – строка байт 0x36=0011 0110, повторенных 64 раза (64 байта);
pad_2 – строка байт 0x5C=0101 1100, повторенных 64 раза (64 байта);
seq_num – порядковый номер сообщения;
TLS Compressed.type – используемый протокол сжатия;
TLS Compressed.version – версия используемого протокола сжатия;
TLS Compressed.length – длина текста после сжатия;
TLS Compressed.fragment – текст после сжатия (если сжатие не используется, то сам текст).
Таким образом, вместо операции конкатенации для секретного ключа используется операция XOR, также в число параметров, от которых вычисляется хэш, добавлена версия используемого алгоритма сжатия.
2. Используется улучшенная псевдослучайная функция (PRF) для разворачивания секрета в выход любой длины. Функция на вход получает секрет (secret), некотрый текст (seed) и идентификационную метку и выдает выход любой длины. В PRF применяет два алгоритма хеширования, обеспечивающих ее защиту. Для начала рассмотрим функцию P_hash разворачивания секрета в последовательность любой длины (рис. 6):
P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) ||
HMAC_hash(secret, A(2) || seed) ||
HMAC_hash(secret, A(3) || seed) || ...,
где A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
HMAC_hash – алгоритм вычисления хэша, используемый в HMAC.
Рис. 6. Вычисление функции P_hash
Для вычисления PRF секрет разделяется на две половины одинаковой длины S1 и S2: первая используется для вычисления значения функции P_MD5, а вторая –P_SHA-1, далее результаты складываются операцией XOR. Если длина секрета нечетная, то последний байт S1 будет равен первому байту S2, то есть длина S1и S2 равна длине секрета, поделенного на 2 и округленного в большую сторону.
PRF тогда вычисляется следующим образом:
PRF(secret, label, seed) = P_MD5(S1, label || seed) XOR
P_SHA-1(S2, label || seed);
Обратите внимание, что в связи с тем, что алгоритм MD5 на выходе выдает хэш длины 16 байт, а SHA-1 – 20 байт, число вычислений для них будет различно: чтобы сгенерировать 80 байтовый выход для P_MD5 мы должны будем провести вычисления вплоть до A(5), а для P_SHA-1 только до A(4).
3. TLS поддерживает все алгоритмы распределения ключей, определенные в SSL v3, кроме Fortezza.
4. TLS поддерживает все алгоритмы шифрования, определенные в SSL v3, кроме Fortezza.
5. TLS поддерживает следующие типы сертификатов, запрашиваемых в сообщении Cretefecate_request: rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh. Помимо данных типов, SSL v3 также поддерживает rsa_ephemeral_dh, dss_ephemeral_ dh, fortezza_kea. В сертификатах rsa_ephemeral_dh, dss_ephemeral_ dh в SSL v3 передается информация об открытых параметрах Диффи-Хеллмана, подписанная ЭЦП. В TLS для этого используются сертификаты rsa_sign, dss_sign. Снятие с поддержки сертификатов типа fortezza_kea обусловлено тем, что в TLS v1.0 алгоритм распределения ключей Fortezza не используется.
6. В TLS в сообщении Certificate_verify используется вычисления хэш-функций MD5 и SHA-1 только для сообщений, направляемых при процедуре установления соединения (handshake_messages). В SSL v3 хэш вычислялся также от главного секретного ключа и констант. Данные дополнительные поля были опущены, так как они не повышали защищенность протокола.
7. В TLS используется более сильный алгоритм вычисления завершающего процедуру установления соединения сообщения, чем в SSL v3. В TLS вычисление сообщения Finished основано на хэше от главного секретного ключа (master_secret), предыдущих сообщений, направляемых при установлении соединения, и идентифицирующей метки, определяющей клиента или сервер:
PRF(master_secret, finished_label, MD5(handshake_messages) ||
SHA-1(handshake_messages)),
где finished_label – строка "client finished" для клиента или "server finished" для сервера.
8. В TLS и SSL v3 применяются различные алгоритмы вычисления рабочих ключей и главного секретного ключа (при этом предварительный главный секретный ключ pre_master_secret вычисляется одинаково). В TLS для вычисления используется описанная ранее функция PRF:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random || ServerHello.random)
Для вычисления ключевого материала, из которого берутся ключи шифрования и вычисления MAC и векторы инициализации используется следующее соотношение, пока не будет получен выход достаточной длины:
key_block = PRF(master_secret, "key expansion",
SecurityParameters.server_random ||SecurityParameters.client_random)
9. В SSL перед шифрованием вход (входной текст, дополненный имитовставкой) дополняется минимально необходимым количеством байт, так чтобы длина результата была кратна длине входного блока используемого алгоритма шифрования. В TLS дополнение может быть любой длины до 255 байт, при этом длина результата должна быть кратна длине входного блока используемого алгоритма шифрования. Это сделано для того, чтобы противодействовать атакам, в основе которых лежит анализ длины передаваемых сообщений.
10. TLS поддерживает все сообщения об ошибках, определенные в SSL v3, за исключением no_certificate. Также для него определен дополнительный набор сообщений, которых нет в SSL v3.
9.2 Основные отличия TLS v1.1 (RFC 4346)
9.3 Основные отличия TLS v1.2 (RFC 5246)
PRF(secret, label, seed) = P_<hash>(secret, label || seed),
где в качестве P_<hash> используется функция P_SHA256, описанная в п.2 раздела 9.1, где в качестве хэш-функции используется SHA-256.
10 Лабораторная работа
10.1 Лабораторная 1
Протокол SSL широко применяется в сети Интернет для защиты данных передаваемых между web-сервером и браузером клиента. Для аутентификации сервера иcпользуется сертификат X.509. В данной лабораторной мы рассмотрим реализацию такого взаимодействия.
Задание 1. Обратитесь на сайт Ситибанка (www.citibank.ru), в раздел "Мой банк", предназначенный для ведения банковских операций через Интернет.
Префикс https в строке адреса и изображение закрытого замка справа от строки указывают, что установлено защищенное соединение. Если щелкнуть мышью по изображению замка, то увидим сообщение о том, что подлинность узла с помощью сертификата подтверждает центр сертификации VeriSign. Значит, мы на самом деле обратились на сайт Ситибанка (а не подделанный злоумышленником сайт) и можем безопасно вводить логин и пароль.
Выбрав "Просмотр сертификата" можно узнать подробности о получателе и издателе и другие параметры сертификата (рис. 7).
Рис. 7. Информация о сертификате
Задание 2. Посмотрите параметры сертификата сайта "электронной сберкассы" Сбербанка - https://esk.sbrf.ru. Опишите, кем, на какой срок и для какого субъекта сертификат был выдан.
Задание 3. Зайдите на сайт https://www.pgpru.com/. Браузер выдаст ошибку "Ошибка в сертификате безопасности этого веб-узла". Нажмите на ссылку "Продолжить открытие этого web-узла" и просмотрите сертификат и описание ошибки, в котором сказано, что ошибка возникла, так как сертификат данного веб-узла не был выпущен доверенным центром сертификации. Браузер сообщает о невозможности удостовериться в подлинности узла из-за того, что данный центр сертификации отсутствует в списке доверенных, а проверить его подлинность с помощью "вышестоящего" по иерархии центра не представляется возможным (т.к. вышестоящего центра нет) (рис. 8).
Рис. 8. Информация о сертификате, который не удалось проверить
Задание 4. Операционная система Windows обеспечивает защищенное хранилище ключей и сертификатов. Работать с хранилищем можно используя консоль управления MMC "Сертификаты".
Из меню Пуск – Выполнить запустите консоль командой mmc. В меню Консоль выберите Добавить или удалить оснастку, а в списке оснасток выберите Сертификаты. Если будет предложен выбор (а это произойдет, если Вы работаете с правами администратора), выберите пункт "Моей учетной записи".
Таким образом, мы можем просматривать сертификаты текущего пользователя. Если ранее сертификаты не запрашивались, то в разделе "Личные сертификаты" элементов не будет.
В разделе "Доверенные корневые центры сертификации" представлен достаточно обширный список центров, чьи сертификаты поставляются вместе с операционной системой (рис. 9).
Рис. 9. Перечень доверенных корневых сертификатов в консоли Сертификаты
Найдите в списке сертификаты, на которых были подписаны сертификаты сайтов Ситибанка и Сбербанка. Благодаря тому, что эти сертификаты уже были установлены, в рассмотренных в начале работы примерах браузер мог подтвердить подлинность этих узлов.
Теперь перейдем к разделу "Сертификаты, к которым нет доверия". Там находятся отозванные сертификаты. Как минимум, там будут находиться два сертификата, которые по ошибке или злому умыслу кто-то получил от имени корпорации Microsoft в центре сертификации VeriSing в 2001 году. Когда это выяснилось, сертификаты отозвали.
10.2 Лабораторная 2
Для выполнения этой лабораторной необходимо разбиться на группы по два или более человек. Далее условно участников будем называть Абонент А и Абонент Б. Цель выполнения лабораторной – наладить безопасный обмен почтовыми сообщениями между Абонентами А и Б с использованием шифрования и ЭЦП. Для выполнения задания необходимо использовать почтовый клиент, поддерживающий SSL, например Outlook Express, Outlook или TheBat!. Далее в качестве примера приводится описание настроек для Outlook Express.
Зайдите Сервис – Учетные записи – кнопка Добавить – Почта. Заполните информацию о почтовом ящике. В настройках сервера электронной почты необходимо указать сервер входящих сообщений IMAP.
В свойствах учетной записи на вкладке Дополнительно поставьте везде галочки "Подключаться через безопасное соединение (SSL)" и укажите номера портов для входящей и исходящей почты (определяются поставщиком услуг электронной почты). На вкладке Серверы поставьте галочку "Проверка подлинности пользователя".
Зайдите в Параметры - Безопасность и установите галочки "Шифровать содержимое и вложения всех исходящих сообщений", "Подписывать все отправляемые сообщения". Нажмите Дополнительно и укажите настройки как на рис 10.
Рис. 10. Настройка дополнительных параметров безопасности в Outlook Express
Абоненту Б необходимо также поставить галочку «Добавлять мой сертификат при отправлении сообщений с подписью».
В интернете существует множество организаций, выдающих сертификаты для электронной почты, заверенные центрами сертификации, включенными в список доверенных в ОС. Некоторые из них выдают такие сертификаты на определенный период бесплатно. Например, такие услуги предоставляет компания Comodo.
Зайдите на сайте http://www.comodo.com. Выберете раздел Products - Free products - Free email Certificate, нажмите Free download, заполните анкету (укажите корректный e-mail, для которого необходимо сформировать сертификат). После регистрации на указанный e-mail будет выслано письмо. В письме нажмите Click & Install Comodo Email Certificate, в браузере откроется окно с запросом на инсталляцию новых пользовательских сертификатов. Нажмите Install.
После этого в браузере в списке личных сертификатов появится новый сертификат для вашего почтового ящика. Теперь этот сертификат необходимо сохранить в формате PKCS#12 (в файле будет содержаться также секретная часть сертификата), и импортировать его в оснастке Сертификаты (Личные сертификаты - Импорт).
Зайдите в почтовом клиенте Параметры - Безопасность - Сертификаты. В окне Личные вы увидете свой сертификат для электронной почты (рис. 11).
Рис. 11. Перечень личных сертификатов в почтовом клиенте
Теперь зайдите в Сервис – Учетные записи – Свойства учетной записи электронной почты – Безопасность. В полях Сертификат выберете ваш сертификат электронной почты.
При отправке сообщения Абонентом А выводится сообщение, что невозможно зашифровать письмо, так как у Абонента А нет сертификата с открытым ключом Абонента Б. Жмем "Не шифровать" и отправляем письмо.
При получении письма Абонентом Б ему выводится сообщение, что входящее письмо содержит ЭЦП, однако при нажатии кнопки Продолжить выводится предупреждение, что имеются проблемы с безопасностью и невозможно проверить ЭЦП (рис. 12).
Рис. 12. Сообщение о невозможности проверки ЭЦП во входящем электронном письме
Несмотря на то, что в перечне доверенных корневых центров сертификации есть центр сертификации UTN-USERFirst-Client Authentication and Email (см. консоль Сертификаты, Доверенные корневые центры сертификации – Сертификаты), заверивший сертификат Абонента А, у Абонента Б выводится сообщение об ошибке о невозможности проверки ЭЦП, так как сертификат отправителя не был включен в состав отправляемого письма и у получателя его нет.
Зайдите Параметры – Безопасность, нажмите кнопку Дополнительно, поставьте галочку "Добавлять моей сертификат при отправлении сообщений с подписью" и повторно отправьте письмо Абоненту Б.
При открытии письма Абонентом Б в поле Безопасность выводится сообщение "Подписано (подпись достоверна)", что говорит о том, что ЭЦП верна и полученное сообщение целостно и подлинно (рис. 13).
Рис. 13. Информация о входящем электронном письме, подписанном ЭЦП (ЭЦП верна)
Просмотрите информацию о сертификате, на котором подписано письмо (сертификат Абонента А).
Теперь зайдите в Параметры - Безопасность - Другие пользователи, где вы увидете сертификат Абонента А. Он был автоматически включен в список, так как в настройках почтового клиента Абонента Б указано "Автоматически добавлять сертификат отправителя в адресную книгу".
По завершении настройки в почтовом клиенте в списке личных сертификатов должен быть сертификат электронной почты Абонента Б (Параметры – Безопасность – Личные), а в списке других сертификатов – сертификат с открытым ключом Абонента А (Параметры – Безопасность – Другие сертификаты) (рис. 14).
Рис. 14. Перечень сертификатов (личных и других пользователей) в почтовом клиенте
При получении письма абонентом А в поле Безопасность будет выведено "Подписано (подпись достоверна); Зашифровано", что говорит о том, что сообщение целостно и подлинно (рис. 15).
Рис. 15. Информация о входящем электронном письме, зашифрованном и подписанном ЭЦП
При нажатии кнопки Продолжить Абоненту А корректно выводится расшифрованное содержимое письма Абонента Б.
При этом сертификат Абонента Б автоматически включается в список сертификатов и Абонент А теперь может направлять Абоненту Б шифрованные письма (зайдите Параметры – Безопасность – Другие сертификаты).
Таким образом, по завершении данного шага Абоненты А и Б могут обмениваться защищенными сообщениями по электронной почте (подписанные ЭЦП и зашифрованные на секретном ключе отправителя и открытом ключе получателя).
7. Абонент А направляет Абоненту Б зашифрованное сообщение, подписанное ЭЦП.
11. Список литературы