| Назва: | Протокол SSL |
| Тип: | Реферати |
| Мова: | Українська |
| Розмiр: | 840,86 KB |
| Скачувань: | 25 |
Разработанные приложения для защиты доступа к веб-серверу, обеспечения аутентификации и шифрования позволили расширить возможности сервера 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, который я применял и для создания веб-сервера.
Защищенные сети и 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, который я применял и для создания веб-сервера.