На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Библиотека исходных текстов SSLREF

SSLRef- это исходный текст написанной на языке програм­мирования С программы Netscape Communications. Его можно использовать в текстах программ поддержки протокола SSL. Компания Netscape предоставляет файлы SSLRef, для того чтобы помочь разработчикам внедрить средства безопасности SSL в протокол это программ, написанных на ANSI С, которые можно компилировать при помощи любого подходящего компилятора. Однако если вы не занимаетесь разработкой продуктов, под­держивающих SSL, а используете программы клиента и сервера (или другой SSL-продукт), то эта библиотека вряд ли вам понадобится. Например, если вы хотите создать свой собственный Web-сайт, то для использования в SSL достаточно сконфигурировать его на использование процесса HTTP со средствами безопасности (HTTPS). (SSL прослушивается на ТСР-порте 443.);. После этого можно указать, какие из страниц должны использовать метод доступа SSL. Если вам нужно более глубокое использование протокола SSL, то можно воспользоваться подпрограммами Gi (common-gateway interface). Для внедрения SSL в приложения эти подпрограммы будут использовать ваш "специальным образом настроенный процесс HTTPS. (О сценариях CGI бу­дет подробно рассказано в главе 20.)
Если описанные выше методы не подходят, или вы разрабатываете приложе­ние, не предназначенное для Web,       скорее это шее решение. При этом подразумевается, что вы достаточно хорошо ете языком программирования С.
Если же вы не программист, то вряд ли вам понадобится эта. Однако если    все-таки решили воспользоваться SSLRef, то этот продукт
расположен    Web-сайте компании Netscape по адресу http://www.netscape.com/
Разрешено использовать SSLRefдля некоммерческих целей, если при не нарушаются какие-либо законы. Этот продукт реализует мощные методы шифрования, поэтому правительство США запрещает экспорт библиотеки SSLRef.
SSLD— ДЕМОН SSL
Вы узнаете о том, что демон — это программа, обрабатывающая сообщения и регистрацию транзакций серверов Unix. Большинство поддержи­вающих SSL Unix-серверов содержат демонов SSL - SSLD. Основное предна­значение SSLD — представлять обычные (не работающие с SSL) TCP-приложе­ния. SSLD позволяет установить безопасное соединение между SSL-сервером и обычным клиентом. 1 показано, как демон работает в качестве сервера-посредника между SSL-сервером и обычным клиентом.
Кроме того, если SSLD выполняется на сетевом сервере, то он может обеспечить безопасное соединение между SSL-клиентом и обычным сервером. На самом
деле для создания безопасного соединения между двумя обычными (не безопас­ными) процессами можно воспользоваться двумя SSLD-процессами.
Чтобы лучше разобраться с работой SSL-сервера, вам не помешает рассмотреть синтаксис простейшей команды SSLD и файл конфигурации SSLD. Например, синтаксис команды SSLD выглядит так:
SSLD-*  [-i]   [-D]   1-й keydir]   [-с conffile]  [-С chxootdir]
В таблице 8.2 приведено полное описание параметров команды SSLD. Обратите внимание: они являются чувствительными к регистру.
Параметр,
-D
Описание


Звездочка указывает на то, что используется версия программы для США, а х определяет одну из экспортных версий.
Указывает SSLD выполняться в интерактивном режиме.
Указывает SSLD принимать сообщения отладки. Так же как и параметр     этот параметр включает
интерактивный режим.
Указывает SSLD считывать файлы ключа и серти­фиката из каталога, указанного в командной строке. Если не указать каталог keydir, то данные будут прочитаны из каталога, установленного по умолча­нию, - /usr/etc/SSL. SSLD присвоит зашифрованной базе данных ключей имя key.db, а базе данных сертификатов - cert.db.
Указывает SSLD использовать файл, указанный в параметре conffile, как файл конфигурации.
Если пропустить этот параметр, то SSLD считает данные из файла, установленного по умолчанию, -SSLD.conf.
Указывает SSLD изменить корневой каталог
на каталог chrootdir. При этом используется „системный вызов chroot(2),_
Параметры командной строки SSLD.
ФАЙЛ КОНФИГУРАЦИИ SSLD
Работа большинства демонов зависит от файлов конфигурации. SSLD не являет­ся исключением из этого правила. Конфигурационный файл этой программы содержит по строке для каждого прослушиваемого SSL. По умолчанию
конфигурационному файлу присваивается имя SSLD.conf. Каждый элемент это­го файла состоит из шести компонентов: port, mode, ad, keyname, certname и action. В таблице 8.3 приведено описание каждого из компонентов.
Компонент
Описание
port
mode
acl
keyname
certname
action
Указывает номер порта или имя службы, прослуши­ваемой SSLD. Все последующие параметры относятся к этому порту.
Указывает SSLD, как работать с соединением, связанным с определенным в строке port портом. Возможны четыре значения: client, server, auth-cltent и auth-server. В таблице 8.4 приведено подробное описание каждого из этих значений.
В этом поле указывается имя файла, содержащего список управления доступом к порту. Если вместо имени файла указан дефис       то это значит, что доступ к порту запрещен. Список управления доступом действителен только в режиме (4). В этом списке расположены имена (каждое новое имя стоит в отдельной строке). Как минимум одно имя должно соответствовать общемуполю имен в сертификате клиента. Если же работа происходит в режиме auth-server, и SSLD определил, что сертификат клиента не соответствует ни одному элементу из списка управления идентификацией, то соединение будет разорвано.
В этом поле содержится псевдоним (текстовая строка) ключа, к которому имеет доступ SSLD. Ключ хранится в базе данных key.db. Местоположение файла key.db указывается в переменной окружения SSL DIR (параметр -d).
Содержит псевдоним или имя цифрового сертификата, расположенного в базе данных cert.db. Файл cert.db всегда располагается в том же каталоге, что и key.db.
Состоит из ключевого слова и последующего списка аргументов. В качестве ключевого слова можно _использовать значения forward и exec (5).
Компоненты файла конфигурации SSLD.
В таблице 8.4 приведено описание значений, используемых в элементе mode.
Значение
Описание
client
SSLD сбрасывает поступающее соединение, а последующее использует SSL. В этом случае SSLD проводит квитирование как клиент.
Возможные значения аргумента mode (продолжение таблицы на следующей странице).
Значение_
auth-client
Описание
auth-server
Это значение отличается от предыдущего тем, что квитирование включает идентификацию клиента, производимую при помощи сертификата SSLD.
Поступающее соединение использует SSL. SSLD передает данные в следующее место назначения или выполняемому демону. SSLD проводит квитирование как сервер.
Это значение отличается от предыдущего тем, что во время квитирования клиент должен идентифици­ровать себя. SSLD сверяет идентификацию (обычно это цифровой сертификат) с информацией, хранимой .в файле со списком управления доступом._
Возможные значения аргумента mode (окончание).
В таблице 8.5 приведен список возможных значений аргумента action.
server
Значение_Описание_
forward Аргумент команды forward выглядит так: хост:порт, где хост — это имя хоста или IP-адрес, а порт — это номер порта или имя службы. Получив команду forward, SSLD устанавливает соединение с указанным в строке После этого все поступающие от текущего соединения данные передаются на него. При этом SSLD преобразует данные так, как указано в параметре mode.
exec   Аргументами команды являются путь к выполняемой программе, имя программы и набор аргументов _командной строки._
Возможные значения аргумента action.
ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ о БЕЗОПАСНОСТИ SSLD
Аккуратно конфигурируйте SSLD. Плохая конфигурация может привести к се­рьезным пробелам в системе безопасности сервера. Далее приводятся два про­стых правила, следуя которым можно избежать массы неприятностей.
•   Хорошенько защитите все порты режима auth-client. Эти порты позволяют любому человеку производить от имени и использовать ваш SSLD-сертификат. Обязательно проверьте, что доступом к такому порту обладают только определенные люди. Чтобы добиться это­го, нужно правильно сконфигурировать брандмауэр или воспользоваться другими средствами. Избегайте использования порта auth-client, если можно обойтись и без него.
Тщательно защитите все порты режима client. С помощью такого порта любой желающий может передавать данные остальным машинам так, как будто они передаются вашей машиной. Поэтому другие хосты сети, ис­пользующие механизм идентификации (т. е. они проверят ваш сертифи­кат), могут позволить посторонним людям, использующим клиентский порт вашей машины, получить доступ к любым расположенным на серве­ре данным, а также ко всем данным, проходящим через сервер. Таким образом, все средства защиты SSL окажутся бесполезными.
SSL    И    ТУННЕЛИ БРАНДМАУЭРОВ
В плане 3 рассказывалось о том, как можно повысить безопасность сети при помощи брандмауэров. В связи с быстрым ростом рынка корпоративных сетей многие компании осознали необходимость создания «туннелей» в своих бранд­мауэрах. С помощью этих туннелей определенные пользователи могут получить доступ к ресурсам сети. Другими словами, можно заблокировать FTP-сайт для внешних пользователей (Internet). Однако при этом пользователи корпоративной сети смогут получить доступ к сайту, не выходя из своего дома. Для этого вам нужно создать туннели в брандмауэре. В настоящее время наиболее распростра­ненным является протокол безопасности SSL. Значит, этот протокол должен расширять возможности Web так, чтобы SSL-клиент мог открыть безопасный туннель при помощи сервера-посредника. показано, как с по­мощью сервера-посредника расположенные за брандмауэром клиенты могут при­соединиться к SSL-серверу.
Клиент соединяется с сервером-посредником, а затем сервер-посредник соединяется с SSL-сервером.
Можно с помощью сервера-посредника использовать протокол (На­помню, что в соединениях S-HTTP используется коннектор а в соедине­ниях SSL HTTP — коннектор А «/«.•//. )Чтобы создать транзакцию туннелирования, нужно заставить сервер-посредник начать безопасный сеанс с удаленным вером, а затем произвести HTTPS-транзакцию. Очевидно, что сервер-посредник должен включать в себя полную реализацию SSL для работы. Точно так же большинство серверов-посредников должны создать безопасные соединения с удаленными серверами. Только они смогут работать с FTP или Gopher. К сожалению, у этого метода есть два недостатка:
• Соединение между клиентом исервером-посредником не является безопас­ным. Дело в том, что в таком случае используется режим обычной транзак­ции HTTP (или FTP и т. д.). Однако если клиент и сервер-посредник расположены внутри надежной подсети (другими словами, клиент распо­ложен за брандмауэром), то можно использовать и такие соединения.
• Не существует возможности управлять SSL-туннелями без использования SSL, совместимого с современным протоколом сервера-посредника Web (как определено в спецификациях HTTP 1.1).
Однако в настоящее время не существует достаточно хорошей альтернативы SSL-туннелям. Поэтому при создании сервера-посредника придерживайтесь одного простого правила: запретите серверу-посреднику доступ к данным, переда­ваемым по соединению. Сервер-посредник должен знать только адреса источника и назначения. Кроме того, ему можно предоставить возможность запрашивать имя пользователя (если сервер обладает средствами идентификации). Квитирова­ние между клиентом и сервером-посредником создает соединение между клиентом и удаленным сервером. В целях обратной совместимости расширения нужно, чтобы и клиент, и сервер проводили квитирование в формате запроса HTTP 1.1. Серверы-посредники, которые не могут передавать данные без получения доступа к данным, должны уметь определить невозможность обработки безопасного за­проса. Поэтому они должны возвращать пользователю корректное сообщение об
ошибке.
SSL-туннели не являются особенностью протокола SSL. Наоборот, они являют­ся общим способом предоставления третьей стороне возможности установить со­единение между двумя точками. В этом случае сервер-посредник попросту пе­редает байты от одного конца к другому. Если поместить поддержку SSL-тунне­лей в исходный текст SSL-сервера, то они будут работать совместно с любым SSL-приложением.
ТУННЕЛИ SSL и МЕТОД CONNECT
Как уже говорилось, при создании туннелей в SSL-соединении клиент должен создать соединение с сервером-посредником. Чтобы лучше понять, как SSL-бро­узер с помощью сервера-посредника соединяется с SSL-сервером, вы должны узнать, как создается соединение между клиентом и сервером. Оказывается, фор­мат команд SSL очень похож на формат команд HTTP. Дело в том, что первоначаль­ной целью SSL являлась поддержка безопасной передачи данных с использованием протокола HTTP. Поэтому в командах SSL решили придерживаться тех же согла­шений о наименовании, что и в HTTP.
Соединяясь с сервером-посредником, клиент указывает при помощи метода CONNECT имя хоста и номер порта соединения. В заголовке метода CONNECT клиент должен поместить имя хоста и номер порта; между ними должно стоять двоеточие. Затем ставится пробел, а за ним указывается строка, определяющая версию протокола HTTP, и терминатор строки. Обычно для SSL-туннелей ис­пользуется протокол HTTP версии 1.1. В качестве терминатора строки можно использовать пару символов CRLF или символ перевода строки (LF). .
После терминатора строки следует несколько нулей или дополнительные строки заголовка НТТР^запроса. После них должна стоять пустая строка. Каждая стро­ка заголовка должна заканчиваться парой символов CRLF или только одним сим­волом LF. Пустая строка — это еще одна пара символов CRLF или символ LF. Если при создании соединения квитирование прошло успешно, то после пустой строки следуют передаваемые данные.
Далее приводится пример соединения с безопасным сервером Jamsa Press. Обра­тите внимание на пустую строку после строки заголовка:
('connect www.jamsa.com:443 HTTP/1.1 User-agent: Mozilla/l.lN
Позволив вставлять в метод CONNECT несколько строк заголовка, разработчи­ки создали протокол, который можно легко расширять для поддержки типов соединения или переменных, уникальных для каждой установки. Например, можно добавить строку идентификации сервера-посредника после завершения SSL-соединения:
CONNECT www. j amsa . com :443 HTTP/1.1 User-agent: Mozilla/1.1
NProxy-authorization: basic aGVsbG86d29ybGQ—
После пустой строки в запросе клиент ждет ответа от сервера-посредника, кото­рый должен просмотреть запрос, проверить его достоверность и провести иден­тификацию пользователя. Если проверка даст положительный результат, то сер­вер-посредник отправит клиенту ответ «200 Connection established*, составлен­ный по правилам протокола HTTP 1.1. Это значит, что в начале ответа должен стоять номер версии используемого протокола. Далее следует строка нулей или дополнительные строки заголовка; после каждой такой строки должна стоять пустая строка. В качестве терминатора строки используется символ CR. Далее приводится текст возможного ответа сервера:
HTTP/1.1 200 Connection established
Proxy-agent:  Hacker-Proxy/1.1
После пустой строки сервер-посредник начинает передавать данные от соедине­ния клиента к соединению с удаленным сервером и наоборот. Данные могут
приходить от обоих соединений в любой момент времени. При этом сервер-
посредник должен немедленно переслать их с одного конца на другой. Если же одна из сторон разорвет соединение, то сервер-посредник должен передать все
оставшиеся данные и разорвать соединение с противоположной стороной. Од­нако если у сервера-посредника осталось огромное количество непосланной ин­формации от отсоединившейся стороны, то он должен избавиться от нее.
SSL Plus
49%  SSL Plus Integration Suite компании Consensus Development — щ это пакет разработчика, с помощью которого опытные про­граммисты могут быстро создать серверы, совместимые с ^г*'* протоколом SSL 3.0 и соответствующими программами. Кроме того, этот пакет позволяет разрабатывать улучшенные сред­ства безопасности сетевых приложений. SSL Plus подойдет для многих це­лей. Однако наиболее часто его применяют для создания дополнительных средств, обеспечивающих безопасность приложений корпоративных сетей; сотрудники компании могут использовать их, находясь вне самой компании.
ТУННЕЛИ SSL и ВОПРОСЫ БЕЗОПАСНОСТИ
Прежде чем работать с методом CONNECT, нужно учесть некоторые вопросы безопасности. Дело в том, что этот метод работает с более низким уровнем, чем остальные методы HTTP. Таким образом достигается большая степень контроля над ходом обработки информации сервера-посредника. Например, при помощи метода CONNECT можно заставить сервер-посредник не участвовать в транзак­ции, а просто передавать данные. Серверу-посреднику абсолютно не обязатель­но знать полный URL, с которым хочет соединиться клиент. На самом деле ему достаточно знать имя хоста и номер порта. Сервер-посредник не может проверить, является ли используемый протокол протоколом SSL. Поэтому его конфигурация должна ограничивать возможные соединения: должны использоваться только хорошо известные порты SSL. Такими портами являются порт 443 для HTTPS и порт 563 для SNEWS.
Количество необходимой для работы сервера-посредника информации зависит от нескольких условий. Как уже говорилось, необходимо свести это количе­ство до минимума. Во-первых, соединения всегда должны проходить по широко используемым SSL-портам. Для этого следует включить номер порта в URL — только так можно добиться того, чтобы использовались только безопасные ка­налы. Например, для соединения с безопасным сервером издательства Jamsa Press, введите указанный ниже URL:
http: //vfww.jamsa.com:443/
ТУННЕЛИ SSL   и РАСШИРЯЕМОСТЬ
Напомню, что с помощью заголовков HTTP 1.1 можно свободно расширить процедуру квитирования при создании туннеля SSL. Например, чтобы сервер-посредник мог идентифицировать клиента, он должен воспользоваться кодом статуса 407 и заголовком ответа Proxy-authenticate (описанного в спецификациях HTTP 1.1). С их помощью сервер-посредник может запросить клиента послать
информацию о себе. Далее приводится пример подобного запроса:
нттр/1.1 407 Proxy authentication required
Proxy-authenticate: . . •
Получив такой запрос, клиент пошлет серверу-посреднику информацию о себе. Эта информация должна размещаться в заголовке Proxy-authorization, как пока­зано далее:
CONNECT com: 1
User-agent:   ... Proxy-autorization:  ...
И наконец, для соединения двух серверов-посредников также можно воспользо­ваться методами создания туннелей. Например, такие ситуации могут возник­нуть, если соединение включает использование двух брандмауэров (один — в отделе, а другой — на сервере Internet). В этом случае протокол SSL рассматри­вает внутренний сервер-посредник (отдел продаж) в качестве клиента внешнего
сервера-посредника (сервер-посредник, работающий в рамках всей компании),

SSLava
SSLava Toolkit - это пакет, обеспечивающий разработчиков блоками plug-and-play, при помощи которых можно легко со­здать безопасные, совместимые с протоколом SSL 3.0 прило- -:жения клиент-сервер. В качестве языка программирования используется Java, Как будет рассказано в главе 13, Java — это язык программирования, разработанный для выполнения программ на различных платформах. Таким образом, созданные на Java апплеты могут., выполняться под управлением любого броузера, содержащего виртуальную машину Java. При этом не нужно беспокоиться о проблемах переноса с од­ной платформы на другую и перекомпилировать программу. Построенные при помощи SSLava апплеты обеспечивают бинаправленные коммуникации по безопасным сокетам, проводимые прямо в Web-броузере. Поэтому пакет будет очень полезен для создания безопасных апплетов и приложений, рабо­тающих в корпоративных сетях или Internet. В пакете SSLava Toolkit реали­зована поддержка следующих особенностей:
Полный протокол SSL 3.0, включая возобновляемые сеансы идинами-ческое повторное согласование параметров
• Идентификация клиента сервера
• Алгоритмы шифрования DES, Triple DES и RC4
• Обмен ключами при помощи алгоритмов Диффи-Хеллмана и RSA Алгоритмы создания смешанного значения        и SHA
• Crypto-Security Toolkit для шифрования с симметричным иасимметрич-ным
• Пакет шифрования/расшифровки ASN.1
• Сертификатах 509
В пакет SSLava ГооЩгвходит удобный подключаемый (plug-and-play) API и не зависимый от платформы процессор. SSLava полностью основан на Java (т. е. в нем не используются зависимые от платформы вызовы функций или методы). Кроме того, в этом продукте предусмотрены возможности расшире­ния. При помощи SSLava можно создать безопасные интерактивные аппле­ты, которые можно загружать и выполнять в броузере. Этот программный продукт полностью совместим со всеми серверами и броузерами, поддержи­вающими протокол SSL 3.0 (включая Lntemet Explorer и Netscape Navigator): Кроме того, он совместим и с пакетом разработчика Java 1.1. Для получе­ния более подробной информации посетите Web-сайт компании Phaos Technologies, расположенный по адресу http://www.phaos.com/solutions.html.
S/MIME
В главе 6 рассказывалось о том, что для передачи данных в HTTP используется стандарт MIME. Недавно компания RSA Data Security разработала новый стан­дарт передачи данных — S/MIME (Secure MIME). С его помощью клиенты сооб­щений Web (например, Messenger компании Netscape или Outlook компании Microsoft) могут зашифровывать данные и идентифицировать полученные сооб­щения. Серверы и клиенты SSL также используют S/MIME для передачи по
сети зашифрованных пакетов. Этот стандарт предоставляет простейшие возмож­ности шифрования и идентификации сообщения для большинства современных
броузеров. В S/MIME включены следующие основные средства:
• Шифрование для защиты данных
• Идентификация отправителя при помощи цифровых подписей
• Проверка целостности данных
• Возможность взаимодействия с другими программами, поддерживающи­ми стандарт S/MIME
• Бесшовная интеграция в Netscape Messenger и другие пакеты
• Пересылка сообщений между разными платформами
Шифрование S/MIME помогает сохранять секретность пересылаемых данных. В этом стандарте предусмотрена идентификация отправителя при помощи циф­ровых подписей. Кроме того, используя эти подписи, можно проверить целост­ность данных. Стоит отметить, что S/MIME — это открытый стандарт. Таким
образом, он может взаимодействовать с любыми совместимыми с ним клиента­ми. Благодаря поддержке сертификатов Х.509 пользователи могут посылать и
отправлять зашифрованные сообщения с цифровыми подписями как внутри пред­приятия, так и за его пределами. Например, пользователь из отдела продаж
может послать при помощи Messenger зашифрованное сообщение представителю
компании, выехавшему по делам в другую страну. Получатель может прочитать это сообщение при помощи Internet Explorer. При этом ему не придется проде­лывать какие-либо дополнительные действия. Как видите, это очень непохоже на работу с PGP.
S/MIME может быть бесшовно интегрирован в любую программу. Таким обра­зом, эта программа приобретет возможности шифрования и создания цифровых подписей. А совместимость с экспортными запретами США — это обычное и знакомое всем пользователям свойство стандарта.
S/MIME очень важен для броузеров и серверов SSL потому, что оба конца со­единения используют S/MIME, а не старый стандарт MIME. Например, пользо­ватель, отправляющий при помощи броузера информацию на SSL-сервер, пере­дает ее в форме пакетов S/MIME с заголовком S/MIME (14).
пакет S/MIME
,-г==\
заголовок S/MIME
зашифрованное содержание
  Сравнение пакетов стандартов мiмi и S/m1me.
NETSCAPE  OBJECT SIGNING
С ростом использования SSL возросли и запросы клиентов на информацию о загружаемых файлах. Как уже упоминалось в главе 5, в ответ на эти запросы компания Microsoft разработала технологию Authenticode. В это же самое время компания Netscape создала Netscape Object Signing (NOS) — протокол, совместно
используемый с SSL и позволяющий разработчикам создавать приложения, спо­собные запросить доступ к ресурсам системы пользователя. В этом случае толь-
пакет MIME -v
заголовок MIME содержание
ко пользователь может решить, предоставить ли приложению такие ррава. NOS обеспечивает следующие основные средства:
• Идентификация
• Совместимость на основе Java
• Детектирование постороннего вмешательства
• Возможность создания цифровых подписей объектов.
• Открытая поддержка стандартов
• Возможность использования на разных платформах
Netscape Navigator использует протокол NOS для идентификации загружаемых объектов (с подписями). Во время загрузки такого объекта броузер отображает
на экране диалоговое окно с сообщением о том, кто (или что) создал этот объект, и какие возможности (доступ к записи-чтению и т. д.) ему нужны. После этого пользователь может воспользоваться информацией сертификата вместе с запросом о том, предоставлять ли объекту требуемые возможности. Кроме того, при помощи подписей объектов можно обнаружить произведенные во время пере­дачи изменения в объекте так называемую целостность объекта.
Благодаря N OS разработчики могут создавать цифровые подписи для любых ти­пов объектов, включая Java, программные расширения и документы. Дело в том, что этот стандарт позволяет запечатывать подписи прямо в объект. Таким образом, с его помощью можно создавать подписи для объектов любых форматов. Запечатывание объектов - это основное отличие NOS от Authenticode. (В Authenticode используется внедрение подписей.)
Благодаря поддержке сертификатов Х.509 пользователи могут идентифицировать подписи авторов программ, использующих сертификаты, выданные совмести­мыми с Х.509 ведомствами сертификатов. Разработчики могут создавать подпи­си объектов в операционных системах Windows, Macintosh и Unix. Кроме того, пользователи могут загружать объекты с подписями на любой компьютер при помощи броузера Netscape Navigator 4.0 или более поздней версии. На рисун­ке 8.15 показан стандартный сертификат NOS.
NETSCAPE   SECURITY API
SSL — это открытый стандарт, поддерживаемый различными типами програм­много обеспечения серверов. Одним из наиболее распространенных и наиболее популярных SSL-серверов является Commerce Server компании Netscape. Как и большинство приложений, эта программа содержит расширяемый API (application programming interface). При помощи этого интерфейса разработчики могут рас­ширить возможности Commerce Server. Несмотря на то что API специфичен для Commerce Server, многие компании включают его в свои продукты. Часть интер­фейса Security очень тесно связана с SSL.
Архитектура Netscape Security API позволяет решить большинство проблем департа­ментов IS и Internet. Для этого в интерфейс встроена поддержка разработки но­вых проектов и интеграции легальных систем безопасности. При помощи Netscape SecurityAPI можно разрабатывать любые приложения сервера. Кроме того, интер­фейс Security значительно расширяет архитектуру SSL (16).
коммерческий сервер %
безопаусрноьвхенсьокетов
Security API значительно расширяет архитектуру SSL. Netscape Security API включает в себя следующие возможности:
• Поддержка нескольких платформ
• Модульный дизайн, облегчающий повторное использование
• Простота
• Безопасность программ
• Поддержка языков программирования С и Java
За более подробной информацией о Netscape Security API обратитесь на Web-сайт компании Netscape, расположенный по адресу http://home.netscape.com/.
ПОДРОБНОСТИ ПРОТОКОЛА SSL
В этой главе вы узнали об основах SSL о том, как различ­ные установки могут использовать протокол. За более под­робной информацией обратитесь к документации SSL-серве­ра. Кроме того, можно загрузить полную версию Internet Draft, расположенную по адресу http://alter.colossus.net/SSL.html.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика