Протокол SSL

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 для генерации сертификатов.

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

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

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

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

SSLServerSocket serverSocket = (SSLServerSocket)

ssfa.createServerSocket(localPort); //