Разработка программы для передачи данных по сети на основе протокола TLS 1. 0 (RFC2246)

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

(ГОУВПО «ВГТУ»)

КАФЕДРА СИСТЕМ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

КУРСОВАЯ РАБОТА

по дисциплине: «Безопасность вычислительных сетей»

на тему: «Разработка программы для передачи данных по сети на основе протокола TLS 1. 0 (RFC2246). «

Выполнил: Студент группы ИБ-091

Колюбанов А. А ________

Руководитель: к. т. н., доц.

Деревянко В. Н ________

Оценка:

Дата защиты:

Воронеж 2013

Оглавление

1. Общая характеристика работы

1.1 Цель работы

1.2 Задачи работы

2. Теоретическая часть

2.1 Протокол SSL. Основные положения

2.2 Протокол TLS. Основные положения

2.3 Разработка приложений на основе библиотеки OpenSSL

3. Листинг программы

4. Основные результаты работы

Список использованных информационных источников

1. Общая характеристика работы

1.1 Цель работы

Целью данной работы является разработка консольного приложения Windows для передачи данных по сети на основе протокола TLS 1. 0, в котором будет происходить обмен информацией.

1.2 Задачи работы

сервер защищённый сеанс связь

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

1. Изучить протокол TLS.

2. Создать консольное приложение сервера на основе стандартного TCP сервера Windows с использованием функций библиотеки OpenSSL.

3. Создать консольное приложение клиента на основе стандартного TCP клиента Windows с использованием функций библиотеки OpenSSL.

2. Теоретическая часть

2.1 Протокол SSL. Основные положения

SSL (англ. Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол, который обеспечивает безопасность связи. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко используется для обмена мгновенными сообщениями и передачи голоса через IP ((англ. Voice over IP - VoIP), в таких приложениях, как электронная почта, Интернет-факс и др.

SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии, на основании протокола SSL 3. 0 был разработан и принят стандарт RFC, получивший имя TLS.

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

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

Протокол SSL был изначально разработан компанией Netscape Communications. Версия 1. 0 никогда не была обнародована. Версии 2. 0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL версии 3. 0. SSL версии 3. 0, выпущенная в 1996 году, послужила основой для создания протокола TLS 1. 0, стандарт протокола Internet Engineering Task Force (IETF), который впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.

При проектировании приложений SSL обычно реализуется поверх любого другого протокола транспортного уровня, инкапсулируя в себе протоколы уровня приложений, такие как HTTP, FTP, SMTP, NNTP и XMPP. Исторически SSL был использован в первую очередь с надежными транспортными протоколами, такими как Transmission Control Protocol (TCP). Тем не менее, он также был реализован с датаграммным транспортным протоколом, таким как User Datagram Protocol (UDP) и Datagram Control Protocol (DCCP), использование которого было стандартизировано, что привело к использованию термина Datagram Transport Layer Security (DTLS).

SSL поддерживает 3 типа аутентификации:

аутентификация обеих сторон (клиент - сервер),

аутентификация сервера с неаутентифицированным клиентом,

полная анонимность.

Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами - это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

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

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

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

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

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

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

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

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

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

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

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

2.2 Протокол TLS. Основные положения

TLS (англ. Transport Layer Security - безопасность транспортного уровня, как и его предшественник SSL (англ. Secure Socket Layers - уровень защищённых сокетов) - криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет. TLS и SSL используют асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как Веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP)

TLS-протокол основан на спецификации протокола SSL версии 3. 0, разработанной компанией Netscape Communications. Сейчас развитием стандарта TLS занимается IETF. Последнее обновление протокола было в RFC 5246

TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, чтобы предотвратить прослушивание и несанкционированный доступ.

Так как большинство протоколов связи могут быть использованы как с, так и без TLS (или SSL), при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного номера порта, по которому соединение всегда устанавливается с использованием TLS (как например порт 443 для HTTPS), либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола (как например STARTTLS для протоколов электронной почты). Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищённое соединение. Это делается с помощью процедуры подтверждения связи ([3]). Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.

Основные шаги процедуры создания защищённого сеанса связи:

клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;

клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;

сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;

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

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

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

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

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

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

TLS имеет множество мер безопасности:

Защита от понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;

Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC) ;

Использование ключа в идентификаторе сообщения (только владелец ключа может проверить код аутентификации сообщения). Хеш-код идентификации сообщений (HMAC), используемый в большинстве шифров из набора шифров TLS был определён в RFC 2104;

Сообщение, которым заканчивается подтверждение связи («Finished»), содержит в себе хэш всех сообщений, которыми обменялись стороны в процессе подтверждения связи;

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

Уязвимость протокола TLS 1. 0, которая считалась теоретической, была продемонстрирована на конференции Ekoparty в сентябре 2011 года. Демонстрация включала в себя дешифрование cookies, использованных для аутентификации пользователя.

Уязвимость в фазе возобновления соединения, обнаруженная в августе 2009 года, позволяла криптоаналитику, способному взломать https-соединение, добавлять собственные запросы в сообщения, отправленные от клиента к серверу. Так как криптоаналитик не может дешифровать переписку сервера и клиента, этот тип атаки отличается от стандартной атаки, типа человек посередине. В случае, если пользователь не обращает внимания на индикацию браузера о том, что сессия является безопасной (обычно значок замка), уязвимость может быть использована для атаки типа человек посередине.. Для устранения этой уязвимости было предложено как на стороне клиента, так и на стороне сервера добавлять информацию о предыдущем соединении и осуществлять проверку при возобновлении соединения. Это было представлено в стандарте RFC 5746, а также реализовано в последних версиях OpenSSL и других библиотеках.

Также существуют варианты атак, основанные непосредственно на программной реализации протокола, а не на его алгоритме.

Процедура подтверждения связи в TLS в деталях

Согласно протоколу TLS приложения обмениваются записями, инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована MAC (код аутентификации сообщения) в зависимости от текущего состояния соединения (состояния протокола). Каждая запись в TLS содержит следующие поля: content type (определяет тип содержимого записи), поле, указывающее длину пакета, и поле, указывающее версию протокола TLS.

Когда соединение только устанавливается, взаимодействие идёт по протоколу TLS handshake, content type которого 22.

Простое подтверждение связи в TLS

Далее показан простой пример установления соединения, при котором сервер (но не клиент) проходит аутентификацию по его сертификату.

Фаза переговоров:

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

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

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

Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание подтверждения связи;

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

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

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

Клиент посылает сообщение Finished, которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;

Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано;

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

С этого момента подтверждение связи считается завершённым, протокол установленным. Всё последующее содержимое пакетов идет с типом 23, а все данные будут зашифрованы.

Подтверждение связи с аутентификацией клиента

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

Фаза переговоров:

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

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

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

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

[Не хватает пункта получения и проверки сертификата клиента];

Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание подтверждения связи;

Клиент отвечает сообщением ClientKeyExchange, которое содержит открытый ключ PreMasterSecret или ничего (опять же зависит от алгоритма шифрования) ;

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

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

Клиент посылает сообщение Finished, которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;

Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано.

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

С этого момента подтверждение связи считается завершённым, протокол установленным. Всё последующее содержимое пакетов идёт с типом 23, а все данные будут зашифрованы.

Возобновление TLS-соединения

Алгоритмы асимметричного шифрования, использующиеся при генерации сеансового ключа, обычно являются дорогими с точки зрения вычислительных мощностей. Для того чтобы избежать их повторения при возобновлении соединения, TLS создаёт специальный ярлык при подтверждении связи, использующийся для возобновления соединения. При этом при обычном подтверждении связи клиент добавляет в сообщениеClientHello идентификатор предыдущей сессии session id. Клиент связывает идентификатор session id с IP-адресом сервера и TCP-портом так, чтобы при соединении к серверу можно было использовать все параметры предыдущего соединения. Сервер сопоставляет идентификатор предыдущей сессии session id c параметрами соединения, такими как использованный алгоритм шифрования и master secret. Обе стороны должны иметь одинаковый master secret, иначе соединение не будет установлено. Это предотвращает использование session id криптоаналитиком для получения несанкцианированного доступа. Случайные цифровые последовательности в сообщениях ClientHello и ServerHello позволяют гарантировать, что сгенерированный сеансовый ключ будет отличаться от сеансового ключа при предыдущем соединении. В RFC такой тип подтверждения связи называется сокращённым.

Фаза переговоров:

Клиент посылает сообщение ClientHello, указывая последнюю версию поддерживаемого TLS протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS; Также в сообщение добавляется идентификатор предыдущего соединения session id.

Сервер отвечает сообщением ServerHello, содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом. Если сервер узнал идентификатор сессии session id, то он добавляет в сообщение ServerHello тот же самый идентификатор session id. Это является сигналом для клиента о том, что можно использовать возобновление предыдущей сессии. Если сервер не узнал идентификатор сессии session id, то он добавляет в сообщение ServerHelloдругое значение вместо session id. Для клиента это означает, что использовать возобновлённое соединение нельзя. Таким образом, сервер и клиент должны иметь одинаковый master secret и случайные числа для генерации сеансового ключа;

Клиент посылает сообщение ChangeCipherSpec, которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи общим секретным ключом. Это сообщения уровня записей и поэтому имеет тип 20, а не 22;

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

Клиент посылает сообщение Finished, которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;

Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано;

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

С этого момента подтверждение связи считается завершённым, протокол установленным. Всё последующее содержимое пакетов идёт с типом 23, а все данные будут зашифрованы.

Кроме преимуществ с точки зрения производительности, алгоритм возобновления соединения может быть использован для реализации единого входа, поскольку гарантируется, что исходной сессия, как и любая возобновлённая сессия, инициирована тем же самым клиентом (RFC 5077). Это имеет особенно важное значение для реализации FTPS протокола, который в противном случае был бы уязвим к атаке типа человек посередине, при которой злоумышленник мог бы перехватить содержание данных при установлении повторного соединения.

Алгоритмы, использующиеся в TLS

В данной текущей версии протокола доступны следующие алгоритмы:

Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи), ECDSA;

Для симметричного шифрования: RC4, IDEA, Triple DES, SEED, Camellia или AES;

Для хеш-функций: MD5, SHA, SHA-256/384.

Алгоритмы могут дополняться в зависимости от версии протокола. До последней версии протокола TLS 1. 2 были доступны также следующие алгоритмы симметричного шифрования, но они были убраны как небезопасные: RC2, IDEA, DES.

Сравнение с аналогами

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

TLS/SSL

Преимущества:

Невидим для протоколов более высокого уровня;

Популярность использования в Интернет-соединениях и приложениях электронной коммерции;

Отсутствие постоянного соединения между сервером и клиентом;

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

Недостатки:

Невозможность использования с протоколами UDP и ICMP;

Необходимость отслеживания состояния соединения;

Наличие дополнительные требований к программному обеспечению о поддержке TLS.

IPsec

Преимущества:

Безопасность и надёжность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;

Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.

Недостатки:

Сложность реализации;

Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.) ;

Существует много различных реализаций, не всегда корректно взаимодействующих друг с другом.

SSH

Преимущества:

Позволяет создать туннель для приложений, использующих TCP/IP, таких как электронная почта, инструменты программирования и т. д. ;

Слой безопасности невидим для пользователя.

Недостатки:

Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры;

Большая нагрузка на внутрисетевой трафик;

Невозможность использования с протоколами UDP и ICMP.

Не имеет PKI (PKI, основанная на secure DNS, малораспространена).

2.3 Разработка приложений на основе библиотеки OpenSSL

Работу как серверного, так и клиентского приложения можно описать блок-схемой (рис. 1)

Рисунок 1. Блок-схема взаимодействия сокетов.

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

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

После этого устанавливается TCP соединение и конфигурируются потоки ввода/вывода. Далее следует процедура рукопожатия инициируемая клиентом. Если процедура рукопожатия проходит успешно, происходит выбор наилучшего алгоритма шифрования, доступного и клиенту, и серверу.

Затем происходит обмен данными, после окончания которого закрывается SSL-соединение и TCP-соединение.

Для сервера требуется вызывать функции bind, listen и accept, а для клиента - функции connect и SSL_do_handshake.

3. Листинг программы

Файл серверного приложения serv. cpp

#include <openssl/ssl. h>

#include <openssl/err. h>

#define CERTF «cert. pem»

#define KEYF «key. pem»

#define CERTCA «server. crt»

#define CHK_NULL (x) if ((x) ==NULL) exit (1)

#define CHK_ERR (err, s) if ((err) ==-1) { perror (s) ; exit (1) ; }

#define CHK_SSL (err) if ((err) ==-1) { ERR_print_errors_fp (stderr) ; exit (2) ; }

#pragma comment (lib, «libeay32. lib»)

#pragma comment (lib, «ssleay32. lib»)

#pragma comment (lib, «Ws2_32. lib»)

void main ()

{

int err;

SOCKET listen_sd;

SOCKET sd;

sockaddr_in sa_serv;

sockaddr_in sa_cli;

int client_len;

SSL_CTX* ctx;

SSL* ssl;

X509* client_cert;

char* str;

char buf [4096];

const SSL_METHOD *meth;

/* SSL preliminaries. We keep the certificate and key with the context. */

/*!! initialization */

SSL_library_init () ;

SSL_load_error_strings () ;

/*!! create ssl_method */

meth = TLSv1_server_method () ;

/*!! initialization */

OpenSSL_add_all_algorithms () ;

OpenSSL_add_all_ciphers () ;

SSLeay_add_ssl_algorithms () ;

/*!! create ssl_ctx */

ctx = SSL_CTX_new (meth) ;

if (! ctx) {

ERR_print_errors_fp (stderr) ;

exit (2) ;

}

/*!! configure ssl_ctx */

if (SSL_CTX_use_certificate_file (ctx, CERTF, SSL_FILETYPE_PEM) <= 0) {

ERR_print_errors_fp (stderr) ;

exit (3) ;

}

if (SSL_CTX_use_PrivateKey_file (ctx, KEYF, SSL_FILETYPE_PEM) <= 0) {

ERR_print_errors_fp (stderr) ;

exit (4) ;

}

if (! SSL_CTX_check_private_key (ctx)) {

fprintf (stderr, «Private key does not match the certificate public key\n») ;

exit (5) ;

}

SSL_CTX_load_verify_locations (ctx, CERTCA, NULL) ;

/* ----------------------------------------------- */

/* Prepare TCP socket for receiving connections */

/*!! set up tcp/ip socket */

WORD wVersionRequested;

WSADATA wsaData;

/* Use the MAKEWORD (lowbyte, highbyte) macro declared in Windef. h */

wVersionRequested = MAKEWORD (2, 2) ;

err = WSAStartup (wVersionRequested, &wsaData) ;

if (err! = 0)

exit (0) ;

listen_sd = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP) ;

CHK_ERR (listen_sd, «socket») ;

memset (&sa_serv, '\0', sizeof (sa_serv)) ;

sa_serv. sin_family = AF_INET;

sa_serv. sin_addr. s_addr = inet_addr («127. 0. 0. 1») ;

sa_serv. sin_port = 443; /* Server Port number */

err = bind (listen_sd, (sockaddr*) &sa_serv,

sizeof (sa_serv)) ; CHK_ERR (err, «bind») ;

/* Receive a TCP connection. */

err = listen (listen_sd, 5) ; CHK_ERR (err, «listen») ;

client_len = sizeof (sa_cli) ;

sd = accept (listen_sd, (sockaddr*) &sa_cli, &client_len) ;

CHK_ERR (sd, «accept») ;

closesocket (listen_sd) ;

printf («Connection from% lx, port% x\n»,

sa_cli. sin_addr. s_addr, sa_cli. sin_port) ;

/* ----------------------------------------------- */

/* TCP connection is ready. Do server side SSL. */

/*!! create_ssl */

ssl = SSL_new (ctx) ; CHK_NULL (ssl) ;

/*!! create and configure BIO (input and output) */

SSL_set_fd (ssl, sd) ;

/*!! here client: ssl_do_handshake */

err = SSL_accept (ssl) ; CHK_SSL (err) ;

/* Get the cipher - opt */

/*!! ssl_communication */

printf («SSL connection using% s\n», SSL_get_cipher (ssl)) ;

/* Get client's certificate (note: beware of dynamic allocation) - opt */

client_cert = SSL_get_peer_certificate (ssl) ;

if (client_cert! = NULL) {

printf («Client certificate: \n») ;

str = X509_NAME_oneline (X509_get_subject_name (client_cert), 0, 0) ;

CHK_NULL (str) ;

printf («\t subject: % s\n», str) ;

OPENSSL_free (str) ;

str = X509_NAME_oneline (X509_get_issuer_name (client_cert), 0, 0) ;

CHK_NULL (str) ;

printf («\t issuer: % s\n», str) ;

OPENSSL_free (str) ;

/* We could do all sorts of certificate verification stuff here before

deallocating the certificate. */

X509_free (client_cert) ;

} else

printf («Client does not have certificate. \n») ;

/* DATA EXCHANGE - Receive message and send reply. */

err = SSL_read (ssl, buf, sizeof (buf) - 1) ; CHK_SSL (err) ;

buf[err] = '\0';

printf («Got% d chars: '% s'\n», err, buf) ;

char wrt_buf[50];

scanf («% s», wrt_buf) ;

err = SSL_write (ssl, wrt_buf, strlen (wrt_buf)) ; CHK_SSL (err) ;

/*!! Clean up. */

closesocket (sd) ;

WSACleanup () ;

SSL_free (ssl) ;

SSL_CTX_free (ctx) ;

system («pause») ;

}

Файл клиентского приложения cli. cpp

#include <stdio. h>

#include <stdlib. h>

#include <winsock2. h>

#include <openssl/rsa. h> /* SSLeay stuff */

#include <openssl/crypto. h>

#include <openssl/x509. h>

#include <openssl/pem. h>

#include <openssl/ssl. h>

#include <openssl/err. h>

#define CERTF «cert. pem»

#define KEYF «key. pem»

#define CHK_NULL (x) if ((x) ==NULL) exit (1)

#define CHK_ERR (err, s) if ((err) ==-1) { perror (s) ; exit (1) ; }

#define CHK_SSL (err) if ((err) ==-1) { ERR_print_errors_fp (stderr) ; exit (2) ; }

#pragma comment (lib, «libeay32. lib»)

#pragma comment (lib, «ssleay32. lib»)

#pragma comment (lib, «Ws2_32. lib»)

void main ()

{

int err = 0;

SOCKET sd;

struct sockaddr_in sa;

SSL_CTX* ctx;

SSL* ssl;

X509* server_cert;

char* str;

char buf [4096];

const SSL_METHOD *meth;

/*!! initialization */

SSL_library_init () ;

SSL_load_error_strings () ;

/*!! create ssl_method */

meth = TLSv1_client_method () ;

/*!! initialization */

OpenSSL_add_all_algorithms () ;

OpenSSL_add_all_ciphers () ;

SSLeay_add_ssl_algorithms () ;

/*!! create ssl_ctx */

ctx = SSL_CTX_new (meth) ; CHK_NULL (ctx) ;

CHK_SSL (err) ;

/* ----------------------------------------------- */

/* Create a socket and connect to server using normal socket calls. */

/*!! set up tcp/ip socket */

WORD wVersionRequested;

WSADATA wsaData;

/* Use the MAKEWORD (lowbyte, highbyte) macro declared in Windef. h */

wVersionRequested = MAKEWORD (2, 2) ;

err = WSAStartup (wVersionRequested, &wsaData) ;

if (err! = 0)

exit (0) ;

sd = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP) ; CHK_ERR (sd, «socket») ;

memset (&sa, '\0', sizeof (sa)) ;

sa. sin_family = AF_INET;

sa. sin_addr. s_addr = inet_addr («127. 0. 0. 1») ; /* Server IP */

sa. sin_port = 443; /* Server Port number */

err = connect (sd, (struct sockaddr*) &sa,

sizeof (sa)) ;

int error = WSAGetLastError () ;

CHK_ERR (err, «connect») ;

/* ----------------------------------------------- */

/* Now we have TCP connection. Start SSL negotiation. */

/*!! create ssl */

ssl = SSL_new (ctx) ; CHK_NULL (ssl) ;

/*!! create and configure BIO (input and output) */

SSL_set_fd (ssl, sd) ;

/*!! ssl_do_handshake */

SSL_do_handshake (ssl) ;

err = SSL_connect (ssl) ;

CHK_SSL (err) ;

/*!! ssl data communication */

printf («SSL connection using% s\n», SSL_get_cipher (ssl)) ;

/* Get server's certificate (note: beware of dynamic allocation) - opt */

server_cert = SSL_get_peer_certificate (ssl) ; CHK_NULL (server_cert) ;

printf («Server certificate: \n») ;

str = X509_NAME_oneline (X509_get_subject_name (server_cert), 0, 0) ;

CHK_NULL (str) ;

printf («\t subject: % s\n», str) ;

OPENSSL_free (str) ;

str = X509_NAME_oneline (X509_get_issuer_name (server_cert), 0, 0) ;

CHK_NULL (str) ;

printf («\t issuer: % s\n», str) ;

OPENSSL_free (str) ;

/* We could do all sorts of certificate verification stuff here before

deallocating the certificate. */

X509_free (server_cert) ;

/* --------------------------------------------------- */

/* DATA EXCHANGE - Send a message and receive a reply. */

char wrt_buf[50];

scanf («% s», wrt_buf) ;

err = SSL_write (ssl, wrt_buf, strlen (wrt_buf)) ; CHK_SSL (err) ;

err = SSL_read (ssl, buf, sizeof (buf) - 1) ; CHK_SSL (err) ;

buf[err] = '\0';

printf («Got% d chars: '% s'\n», err, buf) ;

SSL_shutdown (ssl) ; /* send SSL/TLS close_notify */

/*!! Clean up. */

closesocket (sd) ;

WSACleanup () ;

SSL_free (ssl) ;

SSL_CTX_free (ctx) ;

system («pause») ;

}

4. Основные результаты работы

В данной работе были созданы клиентская и серверная программы для обмена данными на основе протокола SSL 3. 0 с помощью библиотеки OpenSSL. Программы имеют следующий вид:

Рисунок 2. Внешний вид программы.

Пример сервера

Пример клиента

Список использованных информационных источников

1. Источник в сети интернет http://ru.wikipedia.org/wiki/SSL

2. Источник в сети интернет http://slproweb.com/products/Win32OpenSSL.html

3. Источник в сети интернет http://stackoverflow.com/

Размещено на Allbest.ru