Security (1027395), страница 9
Текст из файла (страница 9)
Этот протокол предоставляет клиенту и серверуодинаковые возможности (он одинаково относится к их запросам и ответам, а также к предпочтениямобеих сторон). При этом сохраняется модель транзакций и эксплуатационные характеристики HTTP.Клиенты и серверы S-HTTP допускают использование нескольких стандартных форматов криптографических сообщений. Клиенты, поддерживающие S-HTTP, могут устанавливать связь с серверами S-HTTPи наоборот, эти серверы могут связываться с клиентами S-HTTP, хотя в процессе подобных транзакцийфункции безопасности S-HTTP использоваться скорее всего не будут.
S-HTTP не требует от клиента сертификатов общих ключей (или самих общих ключей), потому что этот протокол поддерживает толькооперации с симметричными шифровальными ключами. Хотя S-HTTP может пользоваться преимуществами глобальных сертификационных инфраструктур, для его работы такие структуры не обязательны.Протокол S-HTTP поддерживает безопасные сквозные (end-to-end) транзакции, что выгодно отличаетего от базовых механизмов аутентификации HTTP, которые требуют, чтобы клиент попытался получитьдоступ и получил отказ, и лишь затем включают механизм безопасности.
Клиенты могут быть настроенытаким образом, чтобы любая их транзакция автоматически защищалась (обычно с помощью специальной метки в заголовке сообщения). Такая настройка, к примеру, часто используется для передачи заполненных бланков. Если вы используете протокол S-HTTP, вам никогда не придется отправлять важныеданные по сети в незащищенном виде.S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов, режимов и параметров. Для того, чтобы клиенты и серверы смогли выбрать единый режим транзакции (так, например, имнужно решить, будет ли запрос только шифроваться или только подписываться или и шифроваться, иподписываться одновременно; такое же решение нужно принять и для ответов), используется механизмсогласования опций, криптографических алгоритмов (RSA или Digital Signature Standard [DSA] для подписи, DES или RC2 для шифрования и т.
д.), и выбора сертификатов (например: «Подписывайтесь своимсертификатом Verisign»). S-HTTP поддерживает криптографию общих ключей и функцию цифровойподписи и обеспечивает конфиденциальность данных.Протокол S-HTTP распространен не очень широко. Самые свежие данные и более подробные технические детали можно получить в рабочей группе IETF по безопасности web-транзакций (wts) по адресу:http://www.ietf.org/html.charters/wts-charter.html.SOCKSSOCKS разработан для того, чтобы дать возможность приложениям клиент/сервер в доменах TCP и UDPудобно и безопасно пользоваться услугами межсетевого экрана. Он дает пользователям возможностьпреодолевать межсетевой экран организации и получать доступ к ресурсам, расположенным в сети Интернет.
SOCKS является «посредником уровня приложений»: он взаимодействует с общими сетевымисредствами (например, Telnet и браузер Netscape) и с помощью центрального сервера (прокси-сервера)от имени вашего компьютера устанавливает связь с другими центральными компьютерами.SOCKS был разработан много лет назад Дейвом Кобласом (Dave Koblas) из компании SGI, и сегодня этоткод можно бесплатно получить через Интернет. С момента первого выпуска этот код пережил несколько крупных модификаций, но каждая из них распространялась совершенно бесплатно.
SOCKS версия 4решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, основанными на протоколе TCP, включая Telnet, FTP и популярные информационные протоколы, такие какHTTP, Wide Area Information Server (WAIS) и GOPHER. SOCKS версия 5, RFC 1928, является дальнейшимрасширением четвертой версии SOCKS. Он включает в себя UDP, расширяет общую рамочную структуру, придавая ей возможность использования мощных обобщенных схем аутентификации, и расширяетсистему адресации, включая в нее имя домена и адреса IP v6.В настоящее время предлагается создать механизм управления входящими и исходящими многоадресными сообщениями IP, которые проходят через межсетевой экран. Это достигается определением расширений для существующего протокола SOCKS V.5, что создает основу для аутентифицированного перехода межсетевого экрана одноадресным пользовательским трафиком TCP и UDP.
Однако ввиду того,что поддержка UDP в текущей версии SOCKS V.5 имеет проблемы с масштабируемостью и другие недостатки (и их обязательно нужно разрешить, прежде чем переходить к многоадресной передаче), расширения определяются двояко: как базовые расширения UDP и как многоадресные расширения UDP.Функционирование SOCKS заключается в замене стандартных сетевых системных вызовов в приложении их специальными версиями. Эти новые системные вызовы устанавливают связь с прокси-серверомSOCKS (который конфигурируется самим пользователем в приложении или системным файлом конфигурации), подключаясь к хорошо известному порту (обычно это порт 1080/TCP). После установления связи с сервером SOCKS приложение отправляет серверу имя машины и номер порта, к которому хочет подключиться пользователь.
Сервер SOCKS реально устанавливает связь с удаленным центральным компьютером, а затем прозрачно передает данные между приложением и удаленной машиной. При этом пользователь даже не подозревает, что в канале связи присутствует сервер SOCKS.Трудность с использованием SOCKS состоит в том, что кто-то должен проводить работу по замене сетевых системных вызовов версиями SOCKS (этот процесс обычно называется «SOCKS-ификацией» приложения). К счастью, большинство обычных сетевых приложений (Telnet, FTP, finger, whois) уже SOCKSифицированы, и многие производители включают поддержку SOCKS в свои коммерческие приложения.Кроме того, SOCKS V.5 включает эти процедуры в свою общую библиотеку: на некоторых системах (например, на машинах Solaris) можно автоматически SOCKS-ифицировать приложение, поставив общуюбиблиотеку SOCKS перед «shared libc» в вашей строке поиска библиотек (переменная средыLD_LIBRARY_PATH в системах Solaris).Самую свежую информацию и более подробные технические детали можно получить в рабочей группеIETF, работающей над проблемой аутентифицированного пересечения межсетевых экранов, по адресу:http://www.ietf.org/html.charters/aft-charter.html.IPSecБезопасный протокол IP (IPSec) представляет собой набор стандартов, используемых для защиты данныхи для аутентификации на уровне IP.
Текущие стандарты IPSec включают независимые от алгоритмов базовые спецификации, которые являются стандартными RFC.Эти RFC, перечисленные ниже, сейчас пересматриваются с целью разрешения различных проблем безопасности, которые имеются в текущих спецификациях.●RFC 2401 (Security Architecture for the Internet Protocol) – Архитектура защиты для протокола IP.●RFC 2402 (IP Authentication header) – Аутентификационный заголовок IP.●RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) – Использование алгоритма хэшированияMD-5 для создания аутентификационного заголовка.19●●●●●●●●●RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) – Использование алгоритма хэшированияSHA-1 для создания аутентификационного заголовка.RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) – Использование алгоритма шифрования DES.RFC 2406 (IP Encapsulating Security Payload (ESP)) – Шифрование данных.RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – Область применения протокола управления ключами.RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – Управление ключами и аутентификаторами защищенных соединений.RFC 2409 (The Internet Key Exchange (IKE)) – Обмен ключами.RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – Нулевой алгоритм шифрования иего использование.RFC 2411 (IP Security Document Roadmap) – Дальнейшее развитие стандарта.RFC 2412 (The OAKLEY Key Determination Protocol) – Проверка аутентичности ключа.Заметим, что со временем будут разработаны новые алгоритмы аутентификации и шифрования.
Работанад ними не прекращается, и в результате мы будем иметь смесь из этих алгоритмов, одни из которых будут сильнее, а другие слабее.Протокол IPSec также включает криптографические методы, удовлетворяющие потребности управления ключами на сетевом уровне безопасности. Протокол управления ключами Ассоциации безопасностиИнтернет (Internet Security Association Key Management Protocol — ISAKMP) создает рамочную структуру для управления ключами в сети Интернет и предоставляет конкретную протокольную поддержку длясогласования атрибутов безопасности.
Само по себе это не создает ключей сессии, однако эта процедура может использоваться с разными протоколами, создающими такие ключи (например, с Oakley), и в результате мы получаем полное решение для управления ключами в Интернет.20Протокол определения ключей Oakley Key Determination Protocol пользуется гибридным методом Диффи-Хеллмана, чтобы создать ключи сессии Интернет для центральных компьютеров и маршрутизаторов.Протокол Oakley решает важную задачу обеспечения полной безопасности эстафетной передачи данных. Он основан на криптографических методах, прошедших серьезное испытание практикой.
Полнаязащита эстафетной передачи означает, что если хотя бы один ключ раскрыт, раскрыты будут только теданные, которые зашифрованы этим ключом. Что же касается данных, зашифрованных последующимиключами, они останутся в полной безопасности.Протоколы ISAKMP и Oakley были совмещены в рамках гибридного протокола IKE — Internet KeyExchange. Протокол IKE, включающий ISAKMP и Oakley, использует рамочную структуру ISAKMP дляподдержки подмножества режимов обмена ключами Oakley. Новый протокол обмена ключами обеспечивает (в виде опции) полную защиту эстафетной передачи данных, полную защиту ассоциаций, согласования атрибутов, а также поддерживает методы аутентификации, допускающие отказ от авторства и не допускающие такого отказа.
Этот протокол может, к примеру, использоваться для создания виртуальныхчастных сетей (VPN) и для того, чтобы предоставить пользователям, находящимся в удаленных точках (ипользующимся динамически распределяемыми адресами IP), доступ к защищенной сети.Стандарт IPSec позволит поддержать на уровне IP потоки безопасных и аутентичных данных между взаимодействующими устройствами, включая центральные компьютеры, межсетевые экраны (сетевыефильтры) различных типов и маршрутизаторы. Ниже приводится пример использования IPSec для обеспечения обмена аутентифицированными конфиденциальными данными между удаленным маршрутизатором и межсетевым экраном (см. рисунок 22).êËÒÛÌÓÍ 22. ÅÂÁÓÔ‡ÒÌÓÒÚ¸ Ó·ÏÂ̇ ‰‡ÌÌ˚ÏË ÏÂÊ‰Û Û‰‡ÎÂÌÌ˚Ï Ï‡¯ÛÚËÁ‡ÚÓÓÏ Ë ÏÂÊÒÂÚ‚˚Ï ˝Í‡ÌÓÏПрежде чем пройти через межсетевой экран предприятия, весь трафик, идущий от удаленного маршрутизатора, должен быть аутентифицирован.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
