Москва 2011

Государственное образовательное учреждение

Высшего профессионального образования

Московский государственный институт электроники и математики

(Технический университет)

Кафедра Информационной

Безопасности

Защита данных, передаваемых по сети 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

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

2. Совместимость: SSL является универсальным средством для обмена криптографическими параметрами и данными между различными программами.

3. Расширяемость: новые открытые ключи и методы шифрования могут быть включены для использования в протоколе по мере необходимости.

4. Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине Протокол установления соединения SSL был включен в необязательную сессию схемы кэширования для уменьшения числа соединений, которые необходимо устанавливать с нуля.

3. Применение SSL

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

2. SSL может использоваться с NAT (Network Address Translation) и прозрачен для интернет-провайдеров.

3. Работает с TCP и не работает с UDP.

4. Защищает только содержимое пакета, но не адреса отправителя и получателя.

5. Используется в основном в протоколе HTTPS (Hypertext Transfer Protocol Secure). В уникальном идентификаторе ресурсов (URI) сочетание HTTP/TLS обозначается как "https": https://www.example.com/home.html. Обычно после анализа URI клиент узнает имя хоста, на котором функционирует сервер. Это имя должно быть сопоставлено с тем, которое фигурирует в сертификате сервера. Если сервер задан IP-адресом, тот же адрес должен присутствовать в сертификате и подвергаться проверке. Помимо этого SSL получил широкое применение в электронной почте и для организации VPN. Также спецификация SSL позволяет применять этот протокол и другим приложениям, в том числе TELNET и FTP.

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 часов.

После того как сессия установлена, сервер и клиент имеют следующую общую информацию:

1. Идентификатор сессии – случайное 16-байтовое число, выбранное сервером. Служит для идентификации активной или возобновляемой сессии. Если между сервером и клиентом создается невозобнавляемая сессия, то идентификатор сессии остается нулевым.

2. Сертификаты каждой из сторон – сертификаты сервера и клиента. В зависимости от используемого алгоритма распределения ключей в Протоколе установления соединения могут отсутствовать;

3. Метод сжатия – алгоритм сжатия данных перед их шифрованием;

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

5. Главный секретный ключ – секретный ключ длины 48 байт, известный серверу и клиенту;

6. Флаг, указывающий может ли данная сессия использоваться для инициализации новых соединений.

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

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

В процессе создания соединения устанавливаются следующие параметры:

1. Случайные числа, выбранные клиентом и сервером для данного соединения;

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

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

4. Секретный ключ сервера для шифрования данных.

5. Секретный ключ клиента для шифрования данных.

6. Вектор инициализации – вектор инициализации для алгоритма шифрования в режиме сцепления блоков шифротекста. Данное значение изначально заполняется в процессе Протокола установления соединения.

7. Порядковый номер. Каждая сторона в отдельности сохраняет порядковый номер переданных и полученных сообщений для каждого соединения. Когда участник обмена получает либо отправляет сообщение Change_cipher_spec данное значение обнуляется.

6. Используемые криптографические алгоритмы

6.1 Алгоритмы шифрования передаваемых данных

SSL может шифровать данные по следующим алгоритмам:

1. Без шифрования;

2. Поточное шифрование по алгоритму RC4:

· RC4 на ключе длины 40 бит

· RC4 на ключе длины 128 бит;

3. Блочное шифрование RC2 в режиме сцепления блоков шифротекста на ключе длины 40 бит;

4. Блочное шифрование DES:

· DES в режиме сцепления блоков шифротекста на ключе длины 56 бит;

· DES в режиме сцепления блоков шифротекста на ключе длины 40 бит;

· Тройной DES в режиме сцепления блоков шифротекста на ключе длины 168 бит;

5. Блочное шифрование IDEA в режиме сцепления блоков шифротекста на ключе длины 128 бит;

6. Блочное шифрование Fortezza в режиме сцепления блоков шифротекста на ключе длины 96 бит.

Все эти алгоритмы шифрования используют 8-байтовый вектор инициализации (IV), кроме Fortezza, который применяет 20 байтный вектор инициализации.

6.2 Алгоритмы вычисления хэш-функции

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

1. MD5;

2. SHA-1.

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 может использовать следующие алгоритмы:

1. Диффи-Хеллман (Anonymous Diffie-Hellman),

2. кратковременный Диффи-Хеллман (Ephemeral Diffie-Hellman),

3. фиксированный Диффи-Хеллман (Fixed Diffie-Hellman)

4. шифрование RSA,

5. шифрование и ЭЦП RSA,

6. Fortezza.

Далее подробно рассматривается каждый алгоритм в отдельности, кроме Fortezza, так как данный алгоритм довольно сложен и начиная с TLS v1.0 не поддерживается.

6.4.1 Диффи-Хеллман

Используется классический алгоритм распределения ключей Диффи-Хеллмана.

Рассмотрим преобразование , где - поле из q элементов.

Обозначим a – примитивный элемент . Пусть .

1. Клиент выбирает случайное число и отправляет серверу значение и значения параметров a, q.

2. Сервер выбирает случайное число и отправляет серверу значение и значения параметров a, q.

3. Клиент вычисляет секретный ключ pre_master_secret по формуле .

4. Сервер вычисляет секретный ключ pre_master_secret по формуле .

Минусом использования данного алгоритма является то, что он подвержен атаке "человек посередине" (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 известная только серверу (закрытый ключ) такие, что , где – функция Эйлера.

1. Клиент случайным образом вырабатывает предварительный главный секретный ключ длины 48 байт.

2. Клиент направляет серверу значение .

3. Сервер вычисляет значение .

6.4.5 Шифрование и ЭЦП RSA

Обозначим e – открытый ключ RSA, известный серверу и клиенту, d – секретный ключ RSA, известный серверу.

1. Сервер генерирует временную пару открытый - секретный ключ RSA , .

2. Север вычисляет значение ЭЦП для временного открытого ключа и направляет клиенту значения , .

3. Клиент проверяет подлинность полученного временного открытого ключа сервера путем проверки соотношения .

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

5. Сервер вычисляет значение .

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

7. Детальное описание SSL

7.1 Протокол установления соединения

Шаг 1. Установка настроек безопасности. На данном шаге определяется версия используемого протокола SSL, алгоритмы шифрования и сжатия, ID сессии и начальные случайные числа клиента и сервера.

1. Клиент посылает сообщение Client_hello, указывая последнюю версию поддерживаемого SSL протокола, случайное число ClientHellow.random и список поддерживаемых криптографических алгоритмов и методов сжатия, содержат списки предлагаемых клиентом алгоритмов сжатия и криптографии (в порядке убывания приоритетов). Они должны быть построены так, чтобы согласие между клиентом и сервером было заведомо возможным. В частности, в списке алгоритмов сжатия должен фигурировать пустой метод. Также он может указать session_id для возобновления предыдущей сессии (ход установления соединения в таком случае описан в следующем разделе).

2. Сервер отвечает сообщением Server _h ello, содержащим: выбранную сервером версию протокола, случайное число ServerHellow.random, выбранные сервером алгоритмы шифрования и сжатия из списка предоставленного клиентом и идентификатор сессии session_id.

Шаг 2. Аутентификация сервера и передача ключей. Работа на данном шаге отличается в зависимости от используемого алгоритма распределения ключей (см. п.6.4)

1. Если используется один из (2)-(5) алгоритмов, сервер отправляет сообщение Certificate.

Для алгоритмов (2), (4), (5) в сообщении направляется цепочка сертификатов в формате стандарта X.509.

Для алгоритма (3) - открытые параметры сервера для алгоритма Диффи-Хеллмана, подписанные ЭЦП.

2. Если используется один из (1), (2), (5) алгоритмов, сервер отправляет сообщение Server_key_exchange.

Для алгоритма (1) оно содержит открытые параметры сервера для алгоритма Диффи-Хеллмана.

Для алгоритма (2) оно содержит открытые параметры сервера для алгоритма Диффи-Хеллмана, подписанные ЭЦП.

Для алгоритма (5) оно содержит временный открытый ключ сервера для алгоритма RSA, подписанный ЭЦП.

3. Если требуется провести двустороннюю аутентификацию, то сервер направляет сообщение Certificate_request (кроме алгоритма (1)).

4. Сервер направляет сообщение Server_hello_done.

Шаг 3. Аутентификация клиента и передача ключей. Работа на данном шаге отличается в зависимости от используемого алгоритма распределения ключей (см. п.6.4)

1. Если сервер направлял сообщение Certificate_request, то клиент в ответ направляет сообщение Certificate, аналогичное описанному в п. 1 шага 2.

2. Если используется один из (1), (2), (4), (5) алгоритмов, клиент отправляет сообщение Client_key_exchange.

Для алгоритма (1) оно содержит открытые параметры клиента для алгоритма Диффи-Хеллмана.

Для алгоритма (2) оно содержит открытые параметры клиента для алгоритма Диффи-Хеллмана, подписанные ЭЦП.

Для алгоритмов (4), (5) оно содержит предварительный главный секретный ключ, зашифрованный на открытом ключе сервера по алгоритму RSA (для (4) – на постоянном ключе RSA, для (5) – на временном ключе RSA).

3. Если используется один из (1), (2), (4), (5) алгоритмов, клиент отправляет сообщение Certificate_verify. Используется для доказательства клиентом, что он имеет секретный ключ связанный с сертификатом. Содержит значение хэш-функции от предыдущих сообщений, подписанное ЭЦП.

На рисунке представлены варианты взаимодействия на 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.

4. Клиент отправляет сообщение Change_cipher_spec, которое означает инициализацию использования установленных параметров безопасности.

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

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 - все предыдущие сообщения процедуры установки соединения, кроме данного.

6. Сервер направляет сообщение Change_cipher_spec.

7. Сервер направляет зашифрованное сообщение Finished и клиент в свою очередь тоже выполняет расшифровку и проверку.

Целью проведения шага 4 является противодействия двум атакам:

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

2. Злоумышленник может закрыть нижележащее соединение отправив TCP сообщение, что в SSL v.2 завершало SSL сессию с ошибкой.

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 Протокол оповещения

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

Ошибки протокола SSL:

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

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

3. Bad_Certificate_Error: такая ошибка возникает, когда принимающая сторона получила некорректный сертификат. Ошибка устранима (только для аутентификации клиента).

4. No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.

8 Атаки на SSL

На протоколы SSL/TLS могут проводиться следующие типы атак:

1. Атаки перебора ключей, используемых для шифрования данных. Проведение данной атаки онлайн возможно только, если применяется алгоритм шифрования с коротким ключом (например, 40 бит), однако в версии TLS v1.2 такие алгоритмы не используются. Поэтому для реализации данной атаки злоумышленник обычно сохраняет всю сессию и потом на протяжении долгого периода времени подбирает ключ, что делает проведение данной атаки довольно долгим и дорогим процессом.

2. Атаки на основе словаря для известного открытого текста. Многие сообщения могут содержать легко предсказуемый открытый текст, такой как команда HTTP GET. Злоумышленник составляет словарь из всевозможных вариантов шифрованных текстов для известного открытого текста. Когда злоумышленник перехватывает зашифрованное сообщение, он берет фрагмент текста, содержащий текста, для которого у него составлен словарь, в зашифрованном виде и ищет в словаре. Найдя совпадение, он определяет ключ, на котором текст был зашифрован. Если найдено несколько совпадений, то каждый ключ может быть опробован для расшифрования, чтобы определить единственно верный. Данная атака эффективна против шифров с коротким ключом (например, 40 бит), однако в версии TLS v1.2 такие алгоритмы не используются.

3. Атака на Протокол установления соединения. Злоумышленник может направить поддельное сообщение на этапе согласования используемых криптографических алгоритмов таким образом, что стороны выберут для использования слабые алгоритмы. Однако начиная с SSL v3.0 по завершении Протокола установления соединения стороны направляют друг другу сообщения Finished, в которых содержится хэш от всех предыдущих направляемых сообщениях в Протоколе установления соединения. Так как стороны не примут эти сообщения, сессия не будет установлена.

4. Атака повторной отправки. Злоумышленник записывает сообщения, идущие между сервером и клиентом и, после завершения сессии, может повторно направить сообщения Протокола установления соединения. Однако при установлении соединения сервер определяет уникальный идентификатор сессии, который является случайным числом и заранее злоумышленник не может предугадать его значение. Теоретически злоумышленник может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello (идентификатор сессии). Данный код имеет длину 128 бит, а значит, злоумышленнику необходимо записать 2¹²⁷ сессий с различными идентификаторами, чтобы получить вероятность угадывания 50 %, поэтому данная атака сложно реализуема.

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

6. Перехват пароля. Злоумышленник может перехватывать пароли в HTTP и других приложениях.

7. IP Spoofing. Злоумышленник может подделать IP адрес пользователя, чтобы узел принял поддельные данные.

8. IP Hijacking. Активное аутентифицированное соединение между двумя хостами разрывается и злоумышленник занимает место одного из хостов.

9. SYN Flooding. Злоумышленник отправляет TCP сообщение SYN, чтобы запросить соединение, но не отвечает на финальное сообщение, чтобы окончательно установить соединение. Атакованный TCP модуль обычно оставляет "наполовину открытое" соединение примерно на несколько минут. Повторная отправка сообщений SYN может забить TCP модуль.

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)

1. Добавлена защита от атак на схему шифрования в режиме сцепления блоков шифротекста: использование implicit вектора инициализации (IV) заменено на explicit IV.

2. При возникновении ошибок имитовставок используется оповещение bad_record_mac вместо decryption_failed.

3. Добавлены информационные сообщения для различных новых атак на TLS.

4. Возможно использование TLS с алгоритмом шифрования AES в режиме сцепления блоков шифротекста (с длиной ключа 128 бит или 256 бит), описанное в отдельном RFC 3268.

5. Возможно использование TLS с алгоритмом Kerberos, описанное в отдельном RFC 2712.

6. Преждевременное закрытие соединения больше не делает сессию невозобновляемой.

9.3 Основные отличия TLS v1.2 (RFC 5246)

1. Комбинация использования хэш-функций MD5/SHA-1 заменена на использование одной хэш-функции.2. Изменен алгоритм вычисления псевдослучайной функции PRF. Использование комбинации хэш-функций MD5/SHA-1 заменено на SHA256. PRF вычисляется по следующей формуле:

PRF(secret, label, seed) = P_<hash>(secret, label || seed),

где в качестве P_<hash> используется функция P_SHA256, описанная в п.2 раздела 9.1, где в качестве хэш-функции используется SHA-256.

3. Более быстрое вычисление ключей.

4. Описание поддержки алгоритмов шифрования AES в режиме сцепления блоков шифротекста (с длиной ключа 128 бит или 256 бит) включено в текст RFC 5246.

5. Возможность подключения собственного алгоритма шифрования помимо включенных по умолчанию.

6. Включен алгоритм кода аутентификации HMAC на основе хэш-функции SHA-256 HMAC-SHA256.7. Алгоритм вычисления хэш-функции SHA-256 используется по умочанию.8. Если получено сообщение Certificate_request и нет ни одного доступного сертификата, то теперь необходимо направить пустой список сертификатов.9. Из RFC 5246 исключены слабые алгоритмы шифрования IDEA, RC2, RC4 на 40 битном ключе и DES (тройное DES поддерживается), их использование не рекомендовано.

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.

1. На данном шаге Абоненты А и Б должны настроить свои почтовые клиенты для работы с почтовыми ящиками с использованием SSL.

Зайдите Сервис – Учетные записи – кнопка Добавить – Почта. Заполните информацию о почтовом ящике. В настройках сервера электронной почты необходимо указать сервер входящих сообщений IMAP.

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

Зайдите в Параметры - Безопасность и установите галочки "Шифровать содержимое и вложения всех исходящих сообщений", "Подписывать все отправляемые сообщения". Нажмите Дополнительно и укажите настройки как на рис 10.

Рис. 10. Настройка дополнительных параметров безопасности в Outlook Express

Абоненту Б необходимо также поставить галочку «Добавлять мой сертификат при отправлении сообщений с подписью».

2. На данном шаге Абонент А должен получить сертификат для своего почтового ящика, заверенный центром сертификации, и настроить работу почтового клиента с ним.

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

Зайдите на сайте https://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. Перечень личных сертификатов в почтовом клиенте

Теперь зайдите в Сервис – Учетные записи – Свойства учетной записи электронной почты – Безопасность. В полях Сертификат выберете ваш сертификат электронной почты.

3. На данном шаге Абонент А отправляет Абоненту Б письмо, подписанное ЭЦП.

При отправке сообщения Абонентом А выводится сообщение, что невозможно зашифровать письмо, так как у Абонента А нет сертификата с открытым ключом Абонента Б. Жмем "Не шифровать" и отправляем письмо.

При получении письма Абонентом Б ему выводится сообщение, что входящее письмо содержит ЭЦП, однако при нажатии кнопки Продолжить выводится предупреждение, что имеются проблемы с безопасностью и невозможно проверить ЭЦП (рис. 12).

Рис. 12. Сообщение о невозможности проверки ЭЦП во входящем электронном письме

Несмотря на то, что в перечне доверенных корневых центров сертификации есть центр сертификации UTN-USERFirst-Client Authentication and Email (см. консоль Сертификаты, Доверенные корневые центры сертификации – Сертификаты), заверивший сертификат Абонента А, у Абонента Б выводится сообщение об ошибке о невозможности проверки ЭЦП, так как сертификат отправителя не был включен в состав отправляемого письма и у получателя его нет.

4. На данном шаге Абонент А должен в настройках почтового клиента указать настройку включать сертификат в состав отправляемого письма.

Зайдите Параметры – Безопасность, нажмите кнопку Дополнительно, поставьте галочку "Добавлять моей сертификат при отправлении сообщений с подписью" и повторно отправьте письмо Абоненту Б.

При открытии письма Абонентом Б в поле Безопасность выводится сообщение "Подписано (подпись достоверна)", что говорит о том, что ЭЦП верна и полученное сообщение целостно и подлинно (рис. 13).

Рис. 13. Информация о входящем электронном письме, подписанном ЭЦП (ЭЦП верна)

Просмотрите информацию о сертификате, на котором подписано письмо (сертификат Абонента А).

Теперь зайдите в Параметры - Безопасность - Другие пользователи, где вы увидете сертификат Абонента А. Он был автоматически включен в список, так как в настройках почтового клиента Абонента Б указано "Автоматически добавлять сертификат отправителя в адресную книгу".

5. На данном шаге Абонент Б должен получить сертификат для своего почтового ящика, заверенный центром сертификации, и настроить работу почтового клиента с ним по аналогии с п. 2.

По завершении настройки в почтовом клиенте в списке личных сертификатов должен быть сертификат электронной почты Абонента Б (Параметры – Безопасность – Личные), а в списке других сертификатов – сертификат с открытым ключом Абонента А (Параметры – Безопасность – Другие сертификаты) (рис. 14).

Рис. 14. Перечень сертификатов (личных и других пользователей) в почтовом клиенте

6. На данном шаге Абонент Б должен направить письмо, зашифрованное и подписанное ЭЦП, Абоненту Б. При этом шифрование будет осуществляться на открытом ключе Абонента А и закрытом ключе Абонента Б, а установка ЭЦП на закрытом ключе Абонента Б. Абонент А должен корректно расшифровать письмо Абонента Б и проверить ЭЦП.

При получении письма абонентом А в поле Безопасность будет выведено "Подписано (подпись достоверна); Зашифровано", что говорит о том, что сообщение целостно и подлинно (рис. 15).

Рис. 15. Информация о входящем электронном письме, зашифрованном и подписанном ЭЦП

При нажатии кнопки Продолжить Абоненту А корректно выводится расшифрованное содержимое письма Абонента Б.

При этом сертификат Абонента Б автоматически включается в список сертификатов и Абонент А теперь может направлять Абоненту Б шифрованные письма (зайдите Параметры – Безопасность – Другие сертификаты).

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

7. Абонент А направляет Абоненту Б зашифрованное сообщение, подписанное ЭЦП.

11. Список литературы

1. Нестеров С.А., Анализ и управление рисками в информационных системах на базе операционных систем Microsoft, https://www.intuit.ru/department/itmngt/riskanms/5/.

2. Фороузан Б.А., перевод Берлин А.Н., Управление ключами шифрования и безопасность сети, https://www.intuit.ru/department/security/manencryptk/7/.

3. Bodo Moeller, "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures", 2002, https://www.openssl.org/~bodo/tls-cbc.txt.

4. Tim Dierks and Christopher Allen, "The TLS Protocol Version 1.0", January 1999, https://www.ietf.org/rfc/rfc2246.txt.

5. Tim Dierks and Eric Rescorla, "The TLS Protocol Version 1.1", Match 2006, https://www.ietf.org/rfc/rfc4346.txt.

6. Alan Freier, Philip Karlton and Paul Kocher, "The SSL Protocol Version 3.0", November 1996, https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00.

7. Chown P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. https://www.ietf.org/rfc/rfc3268.txt

8. Medvinsky A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. https://www.ietf.org/rfc/rfc2712.txt

9. Mark Dermot Ryan, Network Security lecture notes, https://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/tls/tls.html

10. Vlastimil Klíma, Ondřej Pokorný and Tomáš Rosa, "Attacking RSA-based Sessions in SSL/TLS", 2003, https://eprint.iacr.org/2003/052.pdf

11. Bleichenbacher D., "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1", https://www.springerlink.com/content/j5758n240017h867/.

12. Moeller B., "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures", https://www.openssl.org/~bodo/tls-cbc.txt.