Реферати українською
Протокол SSL - Комп'ютерні науки -



своей работе.

Среди других, эту задачу сумела решить компания "Крипто-Про", разработавшая и внедрившая криптографические средства, реализующие в соответствии со стандартом Microsoft CSP российские криптографические алгоритмы. Их разработки (криптопровайдер "КриптоПРО CSP" и модуль поддержки сетевой аутентификации "КриптоПро TLS") полностью соответствуют требованиям Microsoft и работают под различными операционными системами Windows. К стандартным приложениям, которые теперь могут использовать российские алгоритмы электронной цифровой подписи и шифрования, относятся:

Microsoft CryptoAPI 2.0.

Microsoft Certification Authority.

Microsoft Outlook Express и Microsoft Outlook.

Microsoft Authenticode.

Криптопровайдер "КриптоПРО CSP" был также перенесен и под операционную систему Sun Solaris, а к концу года должна появиться версия и для Linux. Но только сам криптопровайдер. А модули, аналогичные "КриптоПро TLS" и реализующие функции сетевой аутентификации, создания защищенных соединений для веб-серверов, работающих под этими операционными системами, разработала компания Digt. Разработанный ею продукт Digt Trusted TLS является криптографическим инструментом для веб-сервера Apache, используемого в различных серверах приложений (например, Oracle9iAS). Продукт может использоваться в качестве замены имеющегося крипто-модуля веб-сервера и применяться для построения систем, использующих сертифицированные по российским стандартам средства криптозащиты информации (СКЗИ).

Digt Trusted TLS работает через протоколы TLS/SSL с помощью набора инструментов OpenSSL. Он поставляется как динамически загружаемая библиотека, в состав которой входит еще один продукт фирмы - Digt Trusted Crypto Toolkit. Он в свою очередь представляет собой набор библиотек, разработанных для поддержки кросс-платформенных серверных приложений, обеспечивающих их безопасность. Приложения, построенные на основе Digt Trusted Crypto Toolkit, могут поддерживать протоколы TLS/SSL, сертификаты X.509 и другие стандарты безопасности.

Модуль Digt Trusted TLS встраивается взамен имеющегося модуля mod_ssl веб-сервера Apache, работающего под операционными системами Linux, Solaris, Windows. Без использования криптопровайдера "КриптоПРО CSP" модуль полностью обеспечивает все функции аутентификации и криптографии с использованием RSA и Diffie-Hellman шифров. Установка криптопровайдера позволяет применять и сертифицированные алгоритмы шифрования. Таким образом, у интернет-провайдеров появляется возможность расширения оказываемых услуг за счет предоставления сертифицированных российских средств аутентификации и защиты информации.

Разработанные приложения для защиты доступа к веб-серверу, обеспечения аутентификации и шифрования позволили расширить возможности сервера Apache и придали ему дополнительную функциональность. Продукт, получившийся в результате доработки Apache, был назван Digt Trusted Web Server. Он распространяется co всеми стандартными модулями, которые входят в состав сервера Apache. Digt Trusted Web Server использует 256-битное шифрование по ГОСТ 28147-89, сертифицированное ФАПСИ для бизнес-приложений. Он реализует аутентификацию, построенную на X.509 сертификатах, как для клиента, так и для сервера. Имеется возможность использовать сертифицированные ФАПСИ алгоритмы ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 для генерации сертификатов.

Криптография: зачем это нужно

[для чего нужна криптозащита]
материал подготовил: Михаил Брод
26.09.2003

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

Возможное решение - использование специального протокола для создания защищенного канала между двумя связывающимися сторонами (клиентом и сервером). К таким протоколам относятся Secure Sockets Layer protocol (SSL*) и протокол TLS. Кроме создания канала, они обеспечивают шифрование и аутентификацию в течение одного сеанса, служат промежуточным слоем между протоколом сетевого уровня (TCP/IP) и протоколом уровня приложения (к примеру, HTTP). TLS/SSL обеспечивает аутентификацию сервера и необязательную аутентификацию клиента. Эти протоколы поддерживают большое число специальных алгоритмов, используемых для криптования, создания дайджестов и подписей. Они позволяют делать выбор алгоритмов с учетом требуемой надежности, соответствия принятому законодательству и иным факторам.

Протокол SSL был разработан Netscape Communications Corporation в 1994 году

Наибольшее применение протокол TLS/SSL получил в обеспечении защиты HTTP-коммуникаций. Защищенный вариант использует адреса (URL), начинающиеся не с http, а с https, и использует иной порт (по умолчанию - это порт 443). Поскольку TLS/SSL работает на транспортном уровне, то он не зависит от используемого протокола на прикладном уровне. Поэтому не только HTTP, но и FTP, TELNET и другие протоколы приложений могут располагаться поверх TLS/SSL и использовать возможности защищенного соединения.

Протокол TLS - это дальнейшее развитие протокола SSL. Браузеры и сервера поддерживают оба протокола

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

И все было бы хорошо - поддержка TLS/SSL есть в операционных системах Windows, имеется она и у веб-сервера Apache. И функции, которые возложены на эти протоколы, встроенными средствами систем обеспечиваются. И шифрование проводится с использованием различных алгоритмов, таких как RSA, TripleDES, MD5, DSA. Защищается как работа по протоколу HTTP, так и по другим протоколам уровня приложений, включая работу с почтовыми системами. Но здесь и начинаются проблемы. Пока речь идет о защите частных электронных документов, частной переписки, особых претензий со стороны каких-либо контролирующих организаций не возникает. Но как только вопрос касается защиты финансовых, коммерческих и иных документов, мы сталкиваемся с требованиями, заложенными в Положениях и Законах РФ о цифровой подписи, электронных документах и сертификации криптографических алгоритмов.

Архитектура
криптографических функций в Windows

В защищенных сессиях применяется комбинированный способ шифрования

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

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

Если говорить об операционных системах Microsoft, то порядок взаимодействия приложений с криптографическими модулями регламентирует документ, который называется Microsoft Cryptographic Application Programming Interface. Функции, описанные в нем, поддерживаются операционными системами Windows и содержатся в определенных модулях. Но эти модули не реализуют криптографические алгоритмы, а обращаются к другим модулям, называемым Cryptographic Service Providers (CSP). Одновременно в операционной системе можно установить несколько CSP. При первом обращении к криптографическому сервису прикладная программа выбирает, с каким именно модулем CSP она будет работать (это зависит от того, какие криптографические алгоритмы ей необходимы). Но для того чтобы новый модуль CSP, реализующий сертифицированные алгоритмы, мог работать в Windows, и к нему могли обращаться прикладные программы, его необходимо заверить цифровой подписью Microsoft. А кроме того, необходимо "убедить" прикладные программы использовать этот модуль в своей работе.

MS Outlook и
КриптоПро CSP

Среди других, эту задачу сумела решить компания "Крипто-Про", разработавшая и внедрившая криптографические средства, реализующие в соответствии со стандартом Microsoft CSP российские криптографические алгоритмы. Их разработки (криптопровайдер "КриптоПРО CSP" и модуль поддержки сетевой аутентификации "КриптоПро TLS") полностью соответствуют требованиям Microsoft и работают под различными операционными системами Windows. К стандартным приложениям, которые теперь могут использовать российские алгоритмы электронной цифровой подписи и шифрования, относятся:

Microsoft CryptoAPI 2.0.

Microsoft Certification Authority.

Microsoft Outlook Express и Microsoft Outlook.

Microsoft Authenticode.

Юридическую силу имеют лишь сертифицированные по стандартам РФ алгоритмы и средства шифрования

Криптопровайдер "КриптоПРО CSP" был также перенесен и под операционную систему Sun Solaris, а к концу года должна появиться версия и для Linux. Но только сам криптопровайдер. А модули, аналогичные "КриптоПро TLS" и реализующие функции сетевой аутентификации, создания защищенных соединений для веб-серверов, работающих под этими операционными системами, разработала компания Digt. Разработанный ею продукт Digt Trusted TLS является криптографическим инструментом для веб-сервера Apache, используемого в различных серверах приложений (например, Oracle9iAS). Продукт может использоваться в качестве замены имеющегося крипто-модуля веб-сервера и применяться для построения систем, использующих сертифицированные по российским стандартам средства криптозащиты информации (СКЗИ).

Работа модуля
Digt Trusted TLS

Digt Trusted TLS работает через протоколы TLS/SSL с помощью набора инструментов OpenSSL. Он поставляется как динамически загружаемая библиотека, в состав которой входит еще один продукт фирмы - Digt Trusted Crypto Toolkit. Он в свою очередь представляет собой набор библиотек, разработанных для поддержки кросс-платформенных серверных приложений, обеспечивающих их безопасность. Приложения, построенные на основе Digt Trusted Crypto Toolkit, могут поддерживать протоколы TLS/SSL, сертификаты X.509 и другие стандарты безопасности.

Модуль Digt Trusted TLS встраивается взамен имеющегося модуля mod_ssl веб-сервера Apache, работающего под операционными системами Linux, Solaris, Windows. Без использования криптопровайдера "КриптоПРО CSP" модуль полностью обеспечивает все функции аутентификации и криптографии с использованием RSA и Diffie-Hellman шифров. Установка криптопровайдера позволяет применять и сертифицированные алгоритмы шифрования. Таким образом, у интернет-провайдеров появляется возможность расширения оказываемых услуг за счет предоставления сертифицированных российских средств аутентификации и защиты информации.

Разработанные приложения для защиты доступа к веб-серверу, обеспечения аутентификации и шифрования позволили расширить возможности сервера Apache и придали ему дополнительную функциональность. Продукт, получившийся в результате доработки Apache, был назван Digt Trusted Web Server. Он распространяется co всеми стандартными модулями, которые входят в состав сервера Apache. Digt Trusted Web Server использует 256-битное шифрование по ГОСТ 28147-89, сертифицированное ФАПСИ для бизнес-приложений. Он реализует аутентификацию, построенную на X.509 сертификатах, как для клиента, так и для сервера. Имеется возможность использовать сертифицированные ФАПСИ алгоритмы ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 для генерации сертификатов.

Защищенные сети и SSL

Есть и другой подход. Я много говорил в предыдущих статьях о SSL. Мы создали веб-сервер который общался с клиентом по протоколу HTTPS, а теперь ответьте сами себе разве существует принципиальная разница что защищать: то ли трафик HTTP, то ли любую другую информацию передаваемую по сети. Однако следует четко понимать, что раз мы находимся выше чем третий уровень, то прикладные приложения должны догадываться о нашем существовании и сотрудничать с кодом VPN.

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

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

SSLServerSocket serverSocket = (SSLServerSocket)

ssfa.createServerSocket(localPort); //

ssfa --- javax.net.ssl.SSLSocketFactory

serverSocket.setNeedClientAuth(true);

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

Пример кода. Туннель для сетевых вызовов

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

Рисунок 2.

Обратите внимание на картинку, я на ней привел пример не только среды JBuilder, но и окно браузера в котором открыт поисковик Google. Но посмотрите на адресную строку, смею вас уверить, что я работаю не в Google, и на самом деле запрос, который я послал локальной машине на порт 2088, был перенаправлен в интернет на сайт Google. Кстати, если вы внимательно посмотреть на скриншот, то можно увидеть лог пересылаемых данных по туннелю. По крайней мере, я думаю, что начало любого запроса http “GET / HTTP 1.1” увидеть можно.

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

Схема работы приложения очень проста: я создаю серверный сокет ServerSocket и жду входящих соединений на определенный порт, номер которого указывается в файле конфигурации. Затем после поступления запроса создается соответствующий клиентский сокет для чтения запросов от инициирующей связь стороны и сразу же создается сокетное соединение с тем хостом и портом на который входящий запрос должен быть перенаправлен. Дальнейшие действия просты и очевидны: необходимо каждый байт приходящий от стороны инициирующей соединение, (давайте для определенности будем называть ее сторона “A”) перенаправлять к стороне “B” (информация о ней находится в файле конфигурации)) и соответственно каждый байт который посылает нам сторона “B” должна быть направлена стороне “A”. Разумеется что данные действия должны выполняться асинхронно и независимо друг от друга, поэтому лучшего решения чем создать два класса потока, класса производных от Thread и перекрыть в нем метод run так чтобы в цикле читать байт из входного потока и писать в выходной поток. И цикл должен будет продолжаться до тех пор пока сокетное соединение не будет закрыто.

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

Давайте кратко рассмотрим основные моменты работы программы:

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

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

При вызове конструктора класса AbstractRedirector в качестве параметра передается имя файла настроек. Из данного файла читаются все элементы Route и помещаются в специальный массив. После создания объекта класса для начала непосредственно обслуживания должна быть вызвана функция synchroRun. Данная функция создает набор экземпляров безымянного класса производного от Thread в данном классе перекрыта функция run, которая в цикле читает побайтно информацию из сокета входящего запроса и отправляет его в поток вывода для сокета исходящего соединения. Данный цикл прекращается, когда сокетное соединение с любой из двух сторон будет прервано.

Как демонстрацию принципов работы данного приложения привожу следующую СЛС.

Рисунок 3.

Рисунок 4.

Код примера. Защищаем сетевой туннель.

А теперь давайте добавим возможность выполнения туннелирования через протокол SSL. Общая схема реализованного приложения практически идентична общей схеме создания VPN которую я приводил ранее. Небольшие отличия я привожу в виде следующей СЛС

Рисунок 5.

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

<SSL-section>

<Keystore-path>E:mdocskolyacbuilder_projects

httpd-sslstore</Keystore-path>

<Keystore-password>bigsecret</Keystore-password>

<Alias-password>bigsecret</Alias-password>

</SSL-section>

И, наконец, я привожу исходный код примера. Обратите внимание на то что в классе SSLRedirector порожденном от AbstractRedirector я перекрыл метод initForRun добавив в него чтение "SSL" секции файла конфигурации, теперь каждому элементу Route необходимо будет добавить как характеристику признак того следует ли выполнять защиту описываемого туннеля. И следовательно мне пришлось расширить класс Route, создав класс SSLRoute и добавив в него булевскую переменную, выполняющую роль признака надо или нет выполнять защиту туннеля. Разумеется, что изменения также затронули и ключевые методы getServerSocket и getClientSocket. Теперь эти методы способны в зависимости от настроек переданного им в качестве параметра объкта SSLRoute создать или просто ServerSocket и соответственно Socket или же если поле plainToSecret установлено в true, то будет создан SSLSocket-ы.

назад |  2 | вперед


Назад

 Это интересно
 Реклама
 Поиск рефератов
 
 Афоризм
Если правильно бросить мужа, то он обязательно вернется… как бумеранг.
 Гороскоп
Гороскопы
 Счётчики
bigmir)net TOP 100