OSI и ее протоколы. Часть 3

Напомню нашим читателям, что в предыдущих номерах (см. КГ №№ 5, 6) мы коснулись краткого описания протоколов прикладного уровня сетевой модели OSI. Следующим после прикладного является уровень представления.

Уровень представления отвечает за возможность диалога между приложениями на разных машинах. Этот уровень обеспечивает преобразование данных (кодирование, компрессия и т.п.) прикладного уровня в поток информации для транспортного уровня. Не останавливаясь подробно на данном уровне модели (протоколов не так много, да и, к тому же, многие из них относят и описывают в рамках соседних уровней модели OSI), ограничимся лишь перечислением типичных протоколов прикладного уровня: LDAP, NetBIOS/IP, XDR, AFP и др.

Следующий уровень OSI — cеансовый — отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды простоя приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия. Типичные протоколы сеансового уровня: ASP, ADSP, DLC, Named Pipes, NBT, NetBIOS, NWLink, Printer Access Protocol, Zone Information Protocol, SSL, TLS, SOCKS. Опишем кратко лишь некоторые из них.

Протокол SSL

Протокол SSL — это защищенный протокол связи для передачи важных документов по локальной сети и Интернету. SSL обеспечивает повышенную безопасность сетевого соединения с помощью закрытого ключа, позволяющего зашифровать передаваемые данные. Наверное, многие из читателей обращали внимание, что отображение некоторых web-страниц сопровождается появлением "таинственного" желтого замочка в нижней панели интернет-обозревателя. Так вот, замочек этот вовсе никакой не таинственный: появляется он как раз тогда, когда начинается SSL-соединение. Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения — такие, как FTP, HTTP, TELNET и т.д. — могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL предоставляет своеобразный "безопасный канал", который выполняет три основные функции:

. Канал обеспечивает приватность. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
. Канал аутентифицирован. Серверная часть диалога аутентифицируется в принудительном порядке, клиентская — опционально.
. Канал высоконадежен и отказоустойчив. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

В SSL все данные пересылаются в виде т.н. рекордов, т.е. записей — объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, то рекорд не имеет заполнителя, и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель, и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка. Протокол диалога SSL имеет две основные фазы. Первая используется для установления конфиденциального канала коммуникаций. Вторая предназначена для аутентификации клиентской стороны. Рассмотрим спецификацию процесса диалога SSL поподробней. Протокол SSL состоит из двух этапов: установление подлинности сервера и необязательное установление подлинности клиента.

На первом этапе сервер в ответ на запрос клиента посылает свой сертификат и параметры шифрования. Затем клиент генерирует мастер-ключ, зашифровывает его открытым ключом сервера и отсылает серверу. Сервер расшифровывает мастер-ключ своим частным ключом и подтверждает свою подлинность клиенту, возвращая ему сообщение, заверенное мастером-ключом клиента. Последующие данные шифруются и заверяются ключами, полученными на основе этого же мастера-ключа. На втором этапе, который не является обязательным, сервер посылает запрос клиенту, а клиент подтверждает серверу свою подлинность, возвращая запрос с собственной цифровой подписью и сертификат открытого ключа. SSL поддерживает разнообразные криптографические алгоритмы. В ходе установления связи используется криптосистема открытого ключа RSA. После обмена ключами используется много разных шифров: RC2, RC4, IDEA, DES и TripleDES.

Протокол TLS

TLS — протокол, который основан и очень похож на SSL. Первоначальной целью протокола TLS (Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (напр., TCP [TCP]), размещается протокол записей TLS. Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три фундаментальных свойства:

. Идентичность партнеров может быть выяснена с использованием асимметричной криптографии (напр., RSA [RSA], DSS [DSS] и т.д.). Эта аутентификация может быть сделана опциональной, но она необходима, по крайней мере, для одного из партнеров.
. Выявление общего секретного кода является безопасным: этот секретный код недоступен злоумышленнику даже если он ухитрится
подключиться к соединению.
. Диалог надежен: атакующий не может модифицировать обсуждаемое соединение без того, чтобы быть обнаруженным партнерами обмена.

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

. Конфиденциальность. Для защиты данных используется один из алгоритмов симметричного шифрования. Ключ для этого алгоритма создается для каждой сессии и основан на секрете, о котором договариваются в протоколе Рукопожатия. Протокол Записи также может использоваться без шифрования.
. Целостность. Обеспечивается проверка целостности сообщения с помощью МАС с ключом. Для вычисления МАС используются безопасные хэш- функции SHA-1 и MD5. Протокол Записи может выполняться без вычисления МАС, но обычно функционирует в этом режиме.

"Протокол Записи" используется для инкапсуляции различных протоколов более высокого уровня. Одним из протоколов более высокого уровня является "протокол Рукопожатия", который использует "протокол Записи" в качестве транспорта для ведения переговоров о параметрах безопасности. "Протокол Рукопожатия" позволяет серверу и клиенту аутентифицировать друг друга и договориться об алгоритмах шифрования и криптографических ключах до того, как прикладной протокол, выполняющийся на том же уровне, начнет передавать или принимать первые байты данных. Таким образом, протокол TLS обеспечивает:

. Криптографическую безопасность. TLS должен использоваться для установления безопасного соединения между двумя партнерами.
. Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга.
. Расширяемость. TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность.
. Относительную эффективность. Криптографические операции требуют больших мощностей ЦПУ — особенно этим славятся операции с открытыми ключами. По этой причине протокол TLS имеет опциональную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность.

Протокол SOCKS

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

Когда работающий по TCP клиент хочет соединиться с объектом, доступным только через брандмауэр, он должен открыть TCP-соединение c соответствующим SOCKS-портом SOCKS-сервера. Сервис SOCKS обычно находится на TCP-порту 1080. Если соединение прошло успешно, клиент начинает переговоры о методе аутентификации, который будет использоваться, проходит аутентификацию по выбранному методу и посылает свой запрос. SOCKS-сервер обрабатывает запрос и либо пытается установить соответствующее соединение, либо отказывает в нем. После того как аутентификация выполнена, клиент посылает детали запроса. Если выбранный метод аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфиденциальности, запросы должны инкапсулироваться в пакет, формат которого определяется выбранным методом. SOCKS-запрос посылается клиентом как только он установил соединение с SOCKS-сервером и выполнил аутентификацию. Более подробно про данный протокол можно прочитать в оригинальной спецификации RFC1928.

Протокол NWLink

Протокол NWLink — это Microsoft-совместимый IPX/SPX-протокол для Windows. Он необходим для доступа к сетям под управлением серверов с ОС Nоwell NetWare. Сам протокол NWLink реализует как сетевой, так и транспортный уровень взаимодействия. Для доступа к файлам или принтерам сервера NetWare необходимо задействовать специальный редиректор, представленный в Windows XP Professional службой CSNW (клиент для сетей NetWare), а в Windows Server 2003 — службой GSNW (шлюз для сетей NetWare). Протокол NWLink включен в состав обеих ОС Windows и устанавливается автоматически вместе с клиентом и службой шлюза для NetWare.

Протокол NETBIOS

Протокол NETBIOS (Network Basic Input/Output System — базовая сетевая система ввода/вывода), разработанный IBM. Протокол поистине является "космополитом" сетевой модели OSI, т.к., кроме сеансового, работает на сетевом, транспортном и уровне каналов связи. Протокол NetBIOS был разработан в 1983 г. компанией Sytek для IBM для локальной сети персональных компьютеров. Интерфейс был разработан для малых сетей и поддерживал не более 80 компьютеров одновременно. NetBIOS — это сетевой сервис сессионного уровня, который выполняет отображение имен в IP-адреса.

В настоящее время широкое распространение получила улучшенная версия NETBIOS — NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP. Он обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине NetBeui рекомендуется использовать исключительно для локальных сетей (здесь они предпочтительнее других протоколов), для внешних же связей использовать, например, TCP/IP.

Продолжение следует.

Олег Бойцев, Boyscout_zone@mail.ru


Компьютерная газета. Статья была опубликована в номере 08 за 2007 год в рубрике сети

©1997-2024 Компьютерная газета