Анализ защищенности протокола SSL/TLS при использовании криптопримитивов

ДИПЛОМНАЯ РАБОТА

Анализ защищенности протокола SSL/TLS при использовании криптопримитивов

сеть протокол атака защита

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ СИМВОЛОВ, ЕДИНИЦ, СОКРАЩЕНИЙ И ТЕРМИНОВ

ВВЕДЕНИЕ

1. МОДЕЛЬ УГРОЗ ДЛЯ WEB-ТРАНЗАКЦИИ

1.1 Методы защиты Web-транзакции

1.2 Введение в протоколы

1.3 Существующие угрозы для протоколов

1.4 Архитектура «клиент-сервер»

1.5 Роль протоколов TLS и SSL в обеспечении защищенного взаимодействия через открытые сети

1.5.1 Цели протокола SSL/TLS

1.6 Обзор протокола SSL

1.6.1 Структура протокола SSL

1.6.1.1 Формат заголовка записи SSL

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

1.6.1.3 Обработка ошибок в протоколе SSL

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

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

1.6.1.6 Принцип предоставления прав клиенту

1.7 Работа с протоколом SSL средствами OpenSSL

1.8 Совместимость протоколов TLS и SSL

1.9 Выводы по разделу

2 АНАЛИЗ ЗАЩИЩЕННОСТИ ПРОТОКОЛА SSL/TLS

2.1 Модель угроз протокола SSL

2.1.1 Атака открытого текста

2.1.1.1 Методы предотвращения атаки на открытый текст

2.1.2 Использование «закладок» для атаки раскрытия выбранного открытого текста

2.1.2.1 Методы борьбы с «закладками»

2.1.3 Атака раскрытия шифров

2.1.4 Ошибка в программном продукте

2.1.5 Организация атаки в Outlook

2.1.6 Атака отклика

2.1.7 Атака «посредника»

2.1.7.1 Настройка Apache на использование клиентских сертификатов

2.1.7.2 Создание клиентских сертификатов

2.1.8 Пример атаки на IDS

2.1.9 Туннелирование атак посредством протокола SSL

2.1.10 Схема высокоуровневой атаки

2.1.11 Атака, основанная на уязвимости RSA

2.1.11.1 Планирование и распространение атаки Bleichenbacher

2.1.11.2 Атаки на протокол TLS методом понижения версии

2.1.12.1 Избегание атак понижения версии посредником

2.2 Моделирование Dos-атаки на протокол SSL

3. БЕЗОПАСНОСТЬ ЖИЗНИ И ДЕЯТЕЛЬНОСТИ ЧЕЛОВЕКА

3.1 Анализ условий труда

3.2 Техника безопасности

3.3 Производственная санитария и гигиена труда

3.4 Пожарная профилактика

4. ТЕХНИКО-КОММЕРЧЕСКОЕ ОБОСНОВАНИЕ

4.1 Расчет расходов на маркетинг

4.2 Расчет затрат на сбыт и коммерческую поддержку

4.3 Расчет затрат на разработку

4.4 Расчет затрат на тиражирование

4.5 Расчет полных затрат

4.6 Планирование пассива баланса

4.7 Планирование необходимой чистой прибыли и ожидаемого изменения актива

4.8 Расчет цены товара и финансового результата

4.9 Расчет операционных показателей

4.10 Расчет конкурентоспособности

4.11 Выводы по расчетам ВЫВОДЫ ПЕРЕЧЕНЬ CCЫЛОК Приложение, А Приложение Б

Приложение В

Приложение Г

Приложение Д

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ, СОКРАЩЕНИЙ И ТЕРМИНОВ

DES — стандарт шифрования данных (Data Encryption Standard);

RSA — стандарт шифрования, назван в честь создателей — Ривеста (Rivest), Шамира (Shamir) и Эдлмана (Adleman);

DSA — алгоритм цифровой подписи, используется как часть стандарта цифровой подписи (Digital Signature Algorithm);

BVO — плохая версия (Bad version Oracle);

MAC — сообщение проверки целостности (Message Autentification Code).

В последнее время современный человек очень часто сталкивается с таким понятием, как Web-транзакция. В этот термин вкладывается большой смысл, Web-транзакции — это поток данных в глобальной среде Internet.

В представленной дипломной работе рассмотрены модель угроз и методы защиты для Web-транзакции. К данным методам относятся стандартные протоколы TLSSSL. Целью данной дипломной работы является проанализировать существующие атаки на протокол SSL/TLS и предложить методы борьбы с данными атаками. По статистике компании Microsoft через Интернет передаётся более 10 Тб информации в месяц, из них большая часть передаётся посредством SSL/TLS-протокола. И сегодня можно с уверенностью сказать, что тема данной дипломной работы вплотную связана с человеком XXI века, поскольку с этим термином мы сталкиваемся довольно часто, поэтому в этот термин вкладывается большой смысл.

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

Для решения поставленной цели в дипломной работе решаются следующие задачи:

— проанализировать известные методы обеспечения безопасности Web-транзакций и выделить наиболее эффективные;

— изучить протокола SSL/TLS, как эффективный метод обеспечения защищенности Web-транзакций;

— проанализировать стойкость протокола SSL/TLS, изучить наиболее эффективные атаки на данный протокол;

— моделирование наиболее эффективной атаки на протокол SSL/TLS;

— предложить методы предотвращения приведенных атак.

1.МОДЕЛЬ УГРОЗ ДЛЯ WEB-ТРАНЗАКЦИЙ Для того, чтобы рассматривать в дальнейшем вопросы безопасности в Internet, необходимо напомнить основные понятия, которыми оперирует теория компьютерной безопасности. Вообще говоря, их всего три: это угрозы, уязвимости и атаки.

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

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

Наконец, атака на компьютерную систему — это действие, предпринимаемое злоумышленником, которое заключается в поиске и использовании той или иной уязвимости.

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

Удаленные атаки можно классифицировать по следующим признакам:

— По характеру воздействия:

· пассивное (класс 1.1);

· активное (класс 1.2).

— По цели воздействия:

· нарушение конфиденциальности информации либо ресурсов системы;

· нарушение целостности информации;

· нарушение работоспособности (доступности) системы.

— По условию начала осуществления воздействия;

— По наличию обратной связи с атакуемым объектом:

· с обратной связью;

· без обратной связи (однонаправленная атака);

— По расположению субъекта атаки относительно атакуемого объекта:

· внутрисегментное;

· межсегментное.

— По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие:

· физический;

· канальный;

· сетевой;

· транспортный;

· сеансовый;

· представительный;

· прикладной.

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

На рисунке 1.1 представлена модель угроз.

Рисунок 1.1 Модель угроз

1. Пользователь 1

2. Устройство Аутентификации П1

3. Криптоаналитик (злоумышленник)

4. Телекоммуникационные системы

5. Источник ключей

6. Устройство Аутентификации П2

7. Пользователь 2

1.1 Методы защиты Web-транзакции

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

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

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

— DES

— RSA

— DSA.

Метод цифровой подписи — активно продвигается Американской ассоциацией банкиров (American Bankers Association). Компания Microsoft анонсировала свой собственный проект развития средств цифровой подписи.

При обеспечении безопасности электронной коммерции, сетевым администраторам следует выделить следующие механизмы безопасности:

— шифрование;

— цифровая подпись;

— механизм управления доступом;

— механизмы контроля целостности данных;

— механизмы аутентификации;

— механизмы дополнения трафика;

— механизмы управления маршрутизацией;

— автоматическое протоколирование и аудит.

Самым надежным методом защиты информации на данный момент являются протоколы, именно этой теме и посвящена данная дипломная работа.

1.2 Введение в протоколы

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

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

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

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

Протоколы с посредником. Посредник — это незаинтересованная третья сторона, которой доверено завершение протокола. Незаинтересованность означает, что у посредника нет заинтересованности в результате работы протокола и склонности к одной из сторон. Следовательно, все участники протокола принимают все, что скажет посредник за истину, все его действия — как правильные.

Арбитражные протоколы. Используемый из-за высокой стоимости найма посредников, арбитражный протокол может быть разбит на два подпротокола нижнего уровня. Первый представляет собой протокол без посредника, используемый при желании сторон выполнить протокол. Другой представляет собой протокол с посредником. Соответствующий специальный посредник называется арбитром. В отличие от посредника он непосредственно не принимает участия в каждой отдельной реализации протокола и приглашается только для проверки честности выполнения протокола сторонами. По такому принципу действует протокол SSL/TLS.

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

1.3 Существующие угрозы для протоколов

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

Люди могут использовать множество способов взломать протокол. Некоторые, не являясь участниками протокола, могут «подслушивать» какую-то часть или весь протокол. Это называется пассивным вскрытием, так как взломщик не воздействует на протокол. Все, что он может сделать — это проследить за протоколом и попытаться добыть информацию. Этот тип вскрытия соответствует вскрытию с использованием только шифротекста. Так как пассивные вскрытия трудно обнаружить, протоколы стремятся предотвращать, а не обнаруживать их. В другом случае взломщик может попытаться изменить протокол для собственной выгоды. Он может выдать себя за другого, ввести новые сообщения в протокол, заменить одно сообщение другим, повторно передать старые сообщения, разорвать канал связи или изменить хранящуюся в компьютере информацию. Такие действия называются активным вскрытием, так как они требуют активного вмешательства. Эти формы вскрытия зависят от вида сети.

Далее приведены существующие угрозы вскрытия:

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

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

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

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

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

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

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

— Вскрытие с использованием цифровой подписи. Даже если открытые ключи хранятся в надежной базе данных, злоумышленник может подменить их при передаче. Чтобы воспрепятствовать этому, посредник должен подписывать каждый открытый ключ, используя свой собственный закрытый ключ. Посредник, который действует подобным образом, часто называют Органом сертификации ключей или Центром распределения ключей (Key Distribution Center, KDC). На практике KDC подписывает сложное сообщение, состоящее из имени пользователя, его открытого ключа и другой информации о пользователе. Это подписанное сложное сообщение и хранится в базе данных KDC. Когда получатель получает ключ отправителя, он проверяет подпись KDC, удостоверяясь в правильности ключа. Получатель же должен откуда-то получить открытый ключ KDC. Злоумышленнику нужно подменить этот ключ своим открытым ключом, испортить базу данных и заменить правильные ключи своими (подписанными его закрытым ключом, как если бы он и был KDC), и его дело сделано. Но, даже подписи на бумаге могут быть подделаны, если злоумышленник всерьез возьмется за дело.

1.4 Архитектура «клиент-сервер»

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

По праву, на технологии «клиент-сервер» держится современный мир компьютерных сетей. Но те задачи, для решения которых она была разработана, постепенно уходят в прошлое, и на сцену выходят новые задачи и технологии, требующие переосмысления принципов клиент — серверных систем. Одна из таких технологий — World Wide Web.

Одним из перспективных способов решения этой проблемы являются многоуровневые архитектуры «клиент-сервер». Чтобы понять их преимущества, рассмотрим подробнее обычную клиент — серверную систему (см. Рисунок 1.2).

Рисунок 1.2 — «Клиент — сервер»

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

Выделяются три подхода, каждый из которых реализован в соответствующей модели:

— модель доступа к удаленным данным (Remote Date Access — RDA);

— модель сервера базы данных (DateBase Server — DBS);

— модель сервера приложений (Application Server — AS).

Архитектура «клиент-сервер» лежит в основе всех протоколов, не исключением является протокол SSL/TLS.

1.5 Роль протоколов TLS и SSL в обеспечении защищенного взаимодействия через открытые сети

Один из подходов к решению проблемы безопасности в Интернете был предложен компанией Netscape Communications. Ею был разработан протокол SSL (Secure Sockets Layer) защищенного обмена информацией между клиентом и сервером. SSL требует применения надежного транспортного протокола (например, TCP).

Фирма Netscape начала заниматься защитой Web-транзакций с тех пор, как появились первые браузеры. Используя предыдущий опыт в данной области, Netscape разработала протокол SSL 1.0 (secure socket layer). На рисунке 1.1 изображен процесс развития SSL, начиная с ноября 1993 года, когда был разработан первый Web-браузер. Спустя 5 месяцев был разработан протокол SSL 2.0. Позднее технологии, примененные в предыдущих 2-х версиях, вместил в себя протокол SSL 3.0. В мае 1996 г. разработкой SSL занялась IETF, которая занималась разработкой различных стандартов протоколов для Интернет, например TCP/IP. [6, 7] Чтобы избежать разногласий с другими компаниями IETF переименовало SSL в Transport Layer Security (TLS). Впервые официальная версия TLS вышла в январе 1999 г. Но между TLS 1.0 и SSL 3.0 не было особых различий.

Теперь несколько слов о реализации SSL. Наиболее распространенным пакетом программ для поддержки SSL является SSLeay. Последняя версия (SSLeay v. 0.9.8) поддерживает SSLv3. Эта версия доступна в исходных текстах. Этот пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Эта библиотека необходима, например, для модуля SSL в распространенном HTTP сервере Apache.

Рисунок 1.1 — История развития TLS и SSL

1.5.1 Цели протокола SSL/TLS

Целями протокола SSL/TLS в порядке приоритетности являются:

— Криптографическая безопасность. SSL/TLS должен использоваться для установления безопасного соединения между двумя партнерами;

— Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие SSL/TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга;

— Расширяемость. SSL/TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность;

— Относительная эффективность. Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине, протокол SSL/TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность [6,7].

Протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape [6,7]. Различие между этим протоколом и SSL 3.0 не значительны, TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0.

1.6 Обзор протокола SSL

Протокол SSL (secure socket layer) был разработан фирмой Netscape, как протокол, обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т. д.) и транспортными протоколами (TCP/IP) (см. Рисунок 1.2.). Часто для него используется аббревиатура HTTPS.

Рисунок 1.2 — Взаимодействие SSL с другими протоколами Протокол SSL предоставляет «безопасный канал», который имеет три основные свойства:

— канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа. Для шифрования применяются: RC4₁₂₈, RC4₄₀, RC2₁₂₈, RC2₄₀, DES40 и др.;

— канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется;

— канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением Message Autentification Code MAC, вычисляемых с помощью с помощью хэш-функций MD5).

Не секрет, что можно без особых технических усилий просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого — sniffer. А в связи с увеличением объема использования Интернета в коммерческих целях, неизбежно вставал вопрос о защите передаваемых данных. И пользователи не очень были бы рады, если номер их кредитной карточки, был бы перехвачен, каким-нибудь предприимчивым хакером по дороге к виртуальному магазину. И, в общем, появление такого протокола как SSL было вполне закономерным явлением. С одной стороны остаются все возможности сервисных протоколов (для программ-серверов), плюс к этому все данные передаются в зашифрованном виде. И декодировать их довольно трудно. Следует отметить, что SSL не только обеспечивает защиту данных в Интернете, но так же производит опознание сервера и клиента (server/client authentication). Протокол SSL принят W3 консорциумом (W3 Consortium), как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.

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

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

Рисунок 1.3 — Использование SSL

Протокол SSL реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову «транспортный», не трудно догадаться, что TCP берет на себя функции «несущей», и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является протокол записей SSL (Record Protocol). Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур. В качестве одной из таких структур, используется протокол согласования SSL (Handshake Protocol) — позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.

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

Вы начинаете использовать SSL в тот момент, когда вводите в адресной строке браузера URL начинающийся с аббревиатуры HTTPS. В результате, вы подключаетесь к порту за номером 443, который для SSL обычно используется по умолчанию; для стандартного HTTP соединения, чаще всего используется порт 80. В процессе подключения, браузер пользователя (в дальнейшем клиент), посылает серверу сообщение согласования (hello message). В свою очередь сервер, также должен посылать клиенту свое приветственное сообщение. Сообщения согласования, являются первичными, инициализирующими сообщениями и содержат информацию, используемую при дальнейшей настройке открываемого секретного канала. В общем случае, приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа. Сервер и клиент генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.

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

На практике, процесс обмена ключами и сертификатами, иногда может занимать относительно много времени. С этой целью, часто предусматривается возможность повторного использования одних и тех же идентификационных данных. Бывают ситуации, когда после установления соединения с SSL-сервером, у пользователя появляется желание открыть еще одно окно браузера, и через него, осуществить еще одно подключение к тому же SSL-серверу. В этом случае, чтобы не повторять весь цикл предварительных обменных операций, браузер может отправить серверу идентификатор сессии предыдущего соединения, и если сервер примет этот идентификатор, весь набор шифровочных и компрессионных параметров, будет взят от предыдущего соединения. Браузеры от Netscape, также могут осуществлять и так называемый «keep alive» запрос. При этом по завершению передачи шифрованных данных, установленное SSL-соединение закрывается не сразу, а лишь по истечении некоторого времени.

Теперь рассмотрим, каким образом все-таки работает SSL. Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена — Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом: Алиса отправляет Бобу случайное сообщение. Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе. Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с уже посланным сообщением, может убедиться в том, что его действительно послал Боб. Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о которой Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа — цифровой подписью (digital signature).

Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма — сертификат (certificate). Сертификат состоит из следующих частей: имя человека/организации выпускающего сертификат/для кого был выпущен данный сертификат (субъект сертификата)/публичный ключ субъекта/некоторые временные параметры (срок действия сертификата и т. п.). Сертификат подписывается приватным ключом человека (или организации), который выпускает сертификаты. Организации, которые производят подобные операции, называются Certificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые подписывают сертификаты.

1.6.1 Структура протокола SSL

1.6.1.1 Формат заголовка записи SSL

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

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

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

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

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

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

Часть данных рекорда SSL состоит из трех компонентов:

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

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

На рисунке 1.4 приведен принцип формирования SSL — записи.

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1.5 — Диалог SSL

1.6.1.3 Обработка ошибок в протоколе SSL

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

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

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

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

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

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

Различают следующие протокольные сообщения клиента:

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

— CLIENT-MASTER-KEY (посылается открыто);

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

— CLIENT-FINISHED (посылается шифрованным).

1.6.1.5 Протокольные сообщения сервера Существует несколько сообщений, которые генерируются только серверами. Различают следующие протокольные сообщения сервера:

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

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

— SERVER-FINISHED (посылается шифрованным);

— REQUEST-CERTIFICATE (посылается шифрованным).

1.6.1.6 Принцип предоставление прав клиенту После подтверждения подлинности сертификата сервер должен решить, какой контекст безопасности, и соответственно, какие права доступа предоставить данному клиенту. В Windows NT права доступа определяются членством клиента в определенных группах и его правами. Для получения этой информации сертификату клиента ставится в соответствие стандартная учетная запись пользователя. Это соответствие устанавливает администратор Интернет-сервера путем создания базы данных авторизации, которая в зависимости от требований конкретного предприятия может оказаться сравнительно простой или довольно сложной.

1.7 Работа с протоколом SSL средствами OpenSSL

OpenSSL — это система защиты и сертификации данных, название SSL переводится как система безопасных сокетов. OpenSSL используется практически всеми сетевыми серверами для защиты передаваемой информации. Существует API SSL, позволяющий создавать безопасные сокеты с шифрованием передаваемых данных.

OpenSSL можно вызвать через командную строку. Внутри OpenSSL существуют отдельные компоненты, отвечающие за то или иное действие. Для получения списка доступных компонентов можно вызвать openssl с параметрами list-standart commands. Можно также получить список доступных алгоритмов хэширования (list-message-digest-commands) и алгоритмов шифрования (list-ciphercommands). Итак, с помощью команд OpenSSL можно делать следующее:

— создавать и управлять ключами RSA и DSA — команды rsa, dsa, dsaparam;

— создавать сертификаты формата x509, запросы на сертификацию, восстановление — команды x509, req, verify, ca, crl, pks12, pks7;

— зашифровывать данные с помощью симметрического или асимметрического шифрования — команды enc, rsautl;

— высчитывать хэши различных типов — команда dgst;

— проверять работы серверов и клиентов ssl — команды s_client, s_server.

Существует также несколько вспомогательных утилит ssl:

— openssl speed [список_алгоритмов_хэширования_или шифрования]

в таблицах 1.1 и 1.2 показан результат работы тестов скорости на домашнем компьютере (Celeron 433), на других компьютерах значения будут другими:

Таблица 1.1 — Результаты тестов скорости алгоритмов Таблица 1.2 — Показатель скорости алгоритмов асимметричного шифрования

— openssl ciphers [-ssl2] [-ssl3] [-tls1] NAME: вывод доступных алгоритмов для обеспечения уровня безопасности NAME, где NAME — это символическое название группы алгоритмов. Обычно используются значения:

— LOW — алгоритмы низкого уровня безопасности (меньше 128 бит);

— MEDIUM — алгоритмы среднего уровня стойкости (128 бит);

— HIGH — алгоритмы высокой стойкости (больше 128 бит);

— ALL — все алгоритмы;

— NULL — алгоритмы без шифрования.

Для создания rsa ключей используется команда genrsa: openssl genrsa [-out file] [-des | - des3 | -idea] [-rand file] [bits] .

Для управления ключами dsa используется программа openssl dsa, которая абсолютно аналогична (в параметрах) утилите openssl rsa. Приведем пример генерации публичного ключа DSA:

# openssl dsain /etc/openssl/ dsakey. pemout /etc/openssl/pubdsakey.pempubout.

Теперь рассмотрим компоненты openssl, выполняющих шифрование и хэширование данных. Для выполнения симметрического шифрования используется утилита openssl enccipher или её сокращённая запись openssl cipher, где cipher — это одно из символических имён симметрических шифров. Наиболее популярными являются:

— base-64 (преобразование в текстовый вид);

— bf (blowfish — 128 бит);

— des (56 бит);

— des3 (168 бит);

— rc4 (128 бит);

— rc5 (128 бит);

— rc2 и idea (128 бит).

Им соответствуют следующие команды:

# openssl des3 -in fileout file. des3

# openssl bfa -in fileout file. bf64

# openssl bfa -din file. bf64 -out file

Для вычисления хэшей используется команда openssl dgsthashalg или краткая форма openssl hashalg. Обычное использование данной команды таково openssl hashalg [-c] file[s].

# openssl md5 -c file MD5(file)= 1: fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94

# openssl sha1 file SHA1(file) = 13f2b3abd8a7add2f3025d89593a0327a8eb83af

Среди алгоритмов хэширования могут применяться следующие:

— md2 (128 бит);

— md4 (128 бит);

— md5 (128 бит);

— mdc2 (128 бит);

— sha (160 бит);

— sha1 (160 бит);

— ripemd160 (160 бит).

Таким же образом можно конвертировать и ключи асимметрического шифрования (используя утилиты rsa или dsa).

Для создания сертификата используется инструмент openssl req:

# openssl reqnewnewkey rsa:2048 -keyout rsa_key.pemconfig cfgout certreq. pem

Создание запроса на сертификацию (-new) на основе создаваемого секретного ключа rsa (-newkey rsa:2048), который записывается в файлkeyout (и шифруется тройным DES). Запрос на сертификацию создаётся на основе конфигурационного файла — config:

# openssl reqx509 -newkey private_key.pemconfig cfgout selfcert. pemdays 365.

Создание (-new) self-signed сертификата (-x509) для использования в качестве сертификата сервера или сертификата CA. Сертификат создаётся с использованием секретного ключаkey и конфигурационного файлаconfig. Создаваемый сертификат будет действителен в течение 365 дней (-days), опцияdays не применима к запросам на сертификацию.

Для управления сертификатами x509 используется утилита openssl x509. С её помощью можно подписать сертификат или запрос на сертификацию сертификатом CA:

# openssl x509 -in cert. pemnoouttext

В openssl существует компонент управления smime сообщениями, называющийся openssl smime. Данная утилита позволяет зашифровывать, расшифровывать, управлять ЭЦП и MIME-заголовками писем:

# openssl smimesignin mail. txttextfrom Сергиенко@smtp.ruto user@mail.rusubject «Signed message» -signer mycert. peminkey private_key.pem | sendmail user@mail.ru

Подписывает сообщениеin (в текстовом виде) и подписывает (-sign) его с помощью сертификата (-signer) и секретного ключа (-inkey). Вывод идёт непосредственно к sendmail, для этого определены MIME-заголовки from, to и subject.

1.8 Совместимость протоколов TLS и SSL

По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.

Протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0).

Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии, если TLS 1.0. Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.

Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.

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

Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.

Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий.

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

Были рассмотрены существующие угрозы для протоколов. Целями данных угроз являются: криптографические алгоритмы и криптографические методы, которые применяются для реализации протоколов. Злоумышленник может осуществить пассивное вскрытие или активное вскрытие. Проанализировав оба вскрытия, можно сделать вывод, что активное вскрытие является наиболее опасным.

Также были приведены существующие угрозы вскрытия:

— с использованием только шифротекста;

— с использованием открытого текста;

— с использованием выбранного открытого текста;

— адаптивное вскрытие с использованием открытого текста;

— с использованием выбранного шифротекста;

— с использованием выбранного ключа;

— с использованием цифровой подписи.

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

SSL/TLS — одно из основных средств обеспечения защищенности информации. Поэтому особое внимание уделялось данным протоколам. Отсюда стоит выделить принцип работы данных протоколов, а именно формированию рекордов и совместимости данных протоколов с другими прикладными программами. Также стоит подчеркнуть, что протоколы SSL и TLS являются очень схожими протоколами, поэтому существующие на данный момент атаки могут быть применены к обоим протоколам. Следует выделить принцип формирования сертификатов, т. к на данный момент этот метод защиты протоколов является наиболее эффективным в борьбе с множеством атак. Хорошо владея приведенным в данной дипломной работе материалом и зная как его применить на практике, специалист по защите информации сможет применить ряд мер и, тем самым, обеспечить целостность, доступность, наблюдаемость, подлинность и надежность передаваемых данных.