Протокол шифрованного соединения SSLSSL - это открытый протокол, разработанный компанией Netscape. SSL определяет механизм поддержки безопасности данных на уровне между протоколами приложений и протоколом TCP. Он поддерживает шифрование данных, идентификацию серверов и целостность. SSL был представлен рабочей группе по безопасности консорциума W3 (W3C) для утверждения в качестве стандартного средства безопасности Web-браузеров и серверов в сети Интернет. Основная цель протокола SSL состоит в том, чтобы обеспечить защищенность и надежность связи между двумя подключенными друг к другу приложениями. Этот протокол состоит из двух уровней. Нижний уровень, который располагается поверх надежного транспортного протокола (например, TCP), называется SSL Record Protocol. SSL Record Protocol используется для встраивания различных протоколов высокого уровня. Один из таких встроенных протоколов, SSL Handshake Protocol, позволяет серверу и клиенту идентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол приложения произведет обмен первыми битами данных. Одно из преимуществ SSL состоит в том, что он независим от протоколов приложений. Протоколы высокого уровня могут совершенно прозрачно располагаться поверх протокола SSL. Протокол SSL поддерживает безопасность связи, придавая ей следующие свойства: Защищенность связи. После первоначального квитирования связи применяются средства шифрования и определяется секретный ключ. Для шифрования данных используются средства симметричной криптографии (например, DES, RC4 и т.д.). Определенность участников. Участник сеанса связи может быть идентифицирован (аутентифицирован) и данные сеанса шифруются с использованием общих ключей (например, RSA, DSS и т.д.). Надежность связи. Транспортные средства проводят проверку целостности сообщений с помощью зашифрованного кода целостности (MIC). Для вычисления кодов МIС используются безопасные хэш-функции (например, безопасный хэш-алгоритм [SHA], MD5 и т.д.). В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента. Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO. К этому моменту, как клиент, так и сервер имеют достаточно информации, чтобы знать, нужен ли новый мастер-ключ. Когда новый мастер-ключ не нужен, клиент и сервер немедленно переходят в фазу 2. Когда нужен новый мастер-ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастер-ключ и посылает сообщение CLIENT-MASTER-KEY Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.
Рис. Алгоритм работы SSL
Как было отмечено, протокол SSL состоит из нескольких уровней. На каждом уровне сообщения имеют ряд полей для указания длины, описания и содержания. SSL воспринимает данные, предназначенный для передачи, делит их на управляемые блоки, проводит компрессию данных (если это необходимо), использует код MIC, производит шифрование и передает результат. Принятые данные расшифровываются, проверяются, декомпрессируются и реассемблируются, а затем передаются клиентам более высокого уровня. Протокол SSL принят только в рамках HTTP. Другие протоколы доказали свою способность работать с SSL, но используют его не часто.
SSH Протокол Secure Shell (SSH) предназначен для защиты удаленного доступа и других сетевых услуг в незащищенной сети. Он поддерживает безопасный удаленный вход в сеть, безопасную передачу файлов и безопасную передачу сообщений. SSH может автоматически шифровать, аутентифицировать и сжимать передаваемые данные. В настоящее время SSH достаточно хорошо защищен от криптоанализа и протокольных атак. Он довольно хорошо работает при отсутствии глобальной системы управления ключами и инфраструктуры сертификатов и при необходимости может поддерживать инфраструктуры сертификатов, которые существуют в настоящий момент (например, DNSSEC, простую инфраструктуру общих ключей [SPKI], X.509). Протокол SSH состоит из трех основных компонентов: 1. Протокол транспортного уровня. Обеспечивает аутентификацию сервера, конфиденциальность и целостность данных с отличной защищенностью эстафетной передачи. В качестве опции может поддерживаться компрессия данных. 2. Протокол аутентификации пользователя позволяет серверу аутентифицировать клиента. 3. Протокол соединения мультиплексирует зашифрованный туннель, создавая в нем несколько логических каналов. Все сообщения шифруются с помощью IDEA или одного из нескольких других шифровальных средств (тройного DES с тремя ключами, DES, RC4-128, Blowfish). Обмен ключами шифрования происходит с помощью RSA, а данные, использованные при этом обмене, уничтожаются каждый час (ключи нигде не сохраняются). Каждый центральный компьютер имеет ключ RSA, который используется для аутентификации центрального компьютера при использовании специальной технологии аутентификации RSA. Для защиты от подслушивания (спуфинга) сети IP используется шифрование; для защиты от DNS и спуфинга маршрутизации используется аутентификация с помощью общих ключей. Кроме того, ключи RSA используются для аутентификации центральных компьютеров. Преимущества средств безопасности сеансового уровня (например, SSL или SSH) включают: - возможность действий на сквозной основе (end-to-end) с существующими стеками TCP/IP, существующими интерфейсами прикладного программирования (API) (WinSock, Berkeley Standard Distribution [BSD] и т. д.); - повышенная эффективность по сравнению с медленными каналами, поддержка технологии Van Jacobson для компрессии заголовков, поддержка различных средств контроля за переполнением сети, просматривающих заголовки TCP/IP; - отсутствие каких-либо проблем с фрагментацией, определением максимального объема блоков, передаваемых по данному маршруту (MTU) и т. д.; - сочетание компрессии с шифрованием. На этом уровне такое сочетание оказывается гораздо более эффективным, чем на уровне пакетов.
LDAP Lightweight Directory Access Protocol (LDAP) — это протокол для обращения к сервису директорий в режиме реального времени. Протокол LDAP был разработан Университетом шт. Мичиган в 1995 г. для обеспечения доступа к директориям Х.500 Прежде всего кратко определим что такое служба директорий Х.500. Разыскать нужную информацию об объекте -- задача непростая, если она находится в большом количестве каталогов, которые не взаимодействуют друг с другом, или хранится в разных форматах. Желание создать глобальную справочную службу стало основным толчком для начала работ, которые завершились серией стандартов известных под названием X.500. Ядро модели X.500 составляет распределенная база данных, содержащая информацию об объекте, такую, как его местонахождение в сети и ряд характеристик, именуемых атрибутами. Модель X.500 предусматривает для каталогов 17 основных классов объектов, таких, как Country, Locality, Organization, Organizational Unit, Person и т. д. Схема также детально описывает набор атрибутов объектов и их синтаксис. Каждый объект имеет относительное отличительное имя (Relative Distinguised Name -- RDN), которое является уникальным его идентификатором среди объектов того же уровня и содержится в атрибуте Common Name (cn). Глобальное уникальное имя объекта, или отличительное имя (Distinguised Name -- DN), образуется с помощью объединения RDN от корня до самого объекта. Отметим, что каталог хранит информацию, достаточно редко изменяющуюся, и оптимизирован для операций чтения. Протокол LDAP для работы с базой данных каталога использует непосредственно протокол TCP и может быть использован для обращения как к автономному сервису директории LDAP, так и для обращения к сервису директории какой-либо системы, например AD. Данный стандарт определяет: - сетевой протокол для получения доступа к информации в директории; - информационную модель, которая определяет форму и характер информации; - пространство имен, которое устанавливает, как информация снабжена ссылками и организована; - распределенную модель функционирования, которая устанавливает, как данные могут быть распределены и снабжены ссылками (в версии 3). Было осуществлено несколько реализаций данного протокола от различных фирм. Наиболее известные из них— это Netscape Directory Service™, Microsoft Active Directory™, Novell Directory Service™. Из некоммерческих реализаций LDAP наибольшее распространение получил проект OpenLDAP.
RPC Remote Procedure Call – является одним из базовых элементов организации распределенных сетевых вычислений. Существует много реализаций механизма RPC, поэтому мы рассмотрим базовые принципы его функционирования. Вызов удаленных процедур является расширением хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными. Характерными чертами вызова локальных процедур являются: · Асимметричность, то есть одна из взаимодействующих сторон является инициатором; · Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов. Принципиальным отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. В реализации RPC участвуют как минимум два процесса - по одному в каждой машине. При аварии вызывающей процедуры удаленно вызванные процедуры станут "осиротевшими", а при аварийном завершении удаленных процедур станут "обездоленными родителями" вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур. Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
Базовые операции RPC RPC достигает прозрачности путем подмены собственно удаленной процедуры её образом – клиентским стабом (stub – заглушка), помещаемым в библиотеку вместо локальной процедуры. Удаленный вызов процедуры включает следующие шаги: 1. Программа-клиент производит локальный вызов процедуры - заглушки. При этом клиенту "кажется", что, вызывая заглушку, он производит собственно вызов процедуры-сервера. И действительно, клиент передает заглушке необходимые параметры, а она возвращает результат. Однако дело обстоит не совсем так, как это себе представляет клиент. Задача заглушки - принять аргументы, предназначаемые удаленной процедуре, возможно, преобразовать их в некий стандартный формат и сформировать сетевой запрос. Упаковка аргументов и создание сетевого запроса называется сборкой (marshalling). 2. Сетевой запрос пересылается по сети на удаленную систему. Для этого в заглушке используются соответствующие вызовы. При этом могут быть использованы различные транспортные протоколы, причем не только семейства TCP/IP. 3. На удаленном хосте все происходит в обратном порядке. Заглушка сервера ожидает запрос и при получении извлекает параметры - аргументы вызова процедуры. Извлечение (unmarshalling) может включать необходимые преобразования (например, изменения порядка расположения байтов). 4. Заглушка выполняет вызов настоящей процедуры-сервера, которой адресован запрос клиента, передавая ей полученные по сети аргументы. 5. После выполнения процедуры управление возвращается в заглушку сервера, передавая ей требуемые параметры. Как и заглушка клиента; заглушка сервера преобразует возвращенные процедурой значения, формируя сетевое сообщение-отклик, который передается по сети системе, от которой пришел запрос. 6. Операционная система передает полученное сообщение заглушке клиента, которая, после необходимого преобразования, передает значения (являющиеся значениями, возвращенными удаленной процедурой) клиенту, воспринимающему это как нормальный возврат из процедуры.
Таким образом, с точки зрения клиента, он производит вызов удаленной процедуры, как он это сделал бы для локальной. То же самое можно сказать и о сервере: вызов процедуры происходит стандартным образом, некий объект (заглушка сервера) производит вызов локальной процедуры и получает возвращенные ею значения. Клиент воспринимает заглушку как вызываемую процедуру-сервер, а сервер принимает собственную заглушку за клиента. Таким образом, заглушки составляют ядро системы RPC, отвечая за все аспекты формирования и передачи сообщений между клиентом и удаленным сервером (процедурой), хотя и клиент и сервер считают, что вызовы происходят локально. Преимущества такого подхода очевидны: и клиент и сервер являются независимыми от сетевой реализации, оба они работают в рамках некой распределенной виртуальной машины, и вызовы процедур имеют стандартный интерфейс.
Передача параметров Передача параметров-значений не вызывает особых трудностей. В этом случае заглушка клиента размещает значение параметра в сетевом запросе при необходимости выполняя преобразования к стандартному виду. Гораздо сложнее с передачей указателей, когда параметр представляет собой адрес данных, а не их значение. Передача в запросе адреса лишена смысла, так как удаленная процедура выполняется в другом адресном пространстве. Самым простым решением является запрет клиентам передавать параметры иначе, как по значению, но это может накладывать неприемлемые ограничения.
Связывание (binding) Прежде чем клиент сможет вызвать удаленную процедуру, необходимо связать его с удаленной системой, располагающей требуемым сервером. Таким образом, задача связывания распадается на две: 1. Нахождение удаленного хоста с требуемым сервером 2. Нахождение требуемого серверного процесса на удаленном хосте Для нахождения хоста могут использоваться различные подходы. Возможно создание некоего централизованного справочника, в котором хосты анонсируют свои серверы, и где клиент при желании может выбрать подходящие для него хост и адрес процедуры. Каждая процедура RPC однозначно определяется номером программы и процедуры. Номер программы определяет группу удаленных процедур, каждая из которых имеет собственный номер. Программе может присваивается номер версии, так что при внесении в программу незначительных изменений отсутствует необходимость менять ее номер. Несколько функционально сходных процедур могут реализовываться в одном программном модуле, который при запуске становится сервером этих процедур, и который идентифицируется номером программы. Таким образом, когда клиент хочет вызвать удаленную процедуру, ему необходимо знать номера программы, версии и процедуры, предоставляющей требуемый сервис. Для передачи запроса клиенту также необходимо знать сетевой адрес хоста и номер порта, связанный с программой-сервером, обеспечивающей требуемые процедуры. Для этого используется демон, запускаемый на хосте предоставляющем сервис удаленных процедур. Демон использует общеизвестный номер порта. При инициализации процесса-сервера он регистрирует в процессе-демоне свои процедуры и номера портов. Теперь, когда клиенту требуется знать номер порта для вызова конкретной процедуры, он посылает запрос демону, который, в свою очередь, либо возвращает номер порта, либо перенаправляет запрос непосредственно серверу удаленной процедуры и после ее выполнения возвращает клиенту отклик. В любом случае, если требуемая процедура существует, клиент получает от демона номер порта процедуры, и дальнейшие запросы может делать уже непосредственно на этот порт.
Обработка особых ситуаций (exception) Обработка особых ситуаций при вызове локальных процедур не представляет особой проблемы. В случае вызова удаленной процедуры вероятность возникновения ошибочных ситуаций увеличивается. К ошибкам сервера и заглушек добавляются ошибки возникающие на транспортном уровне. Например, при использовании UDP в качестве транспортного протокола производится повторная передача сообщений после определенного тайм-аута. Клиенту возвращается ошибка, если, спустя определенное число попыток, отклик от сервера так и не был получен. В случае, когда используется протокол TCP, клиенту возвращается ошибка, если сервер оборвал TCP-соединение. Вызов локальной процедуры однозначно приводит к ее выполнению после чего управление возвращается в головную программу. Иначе дело обстоит при вызове удаленной процедуры. Невозможно установить, когда конкретно будет выполняться процедура, будет ли она выполнена вообще, а если будет, то какое число раз? Например, если запрос будет получен удаленной системой после аварийного завершения программы сервера, процедура не будет выполнена вообще. Если клиент при неполучении отклика после определенного промежутка времени (тайм-аута) повторно посылает запрос, то может создаться ситуация, когда отклик уже передается по сети, а повторный запрос вновь принимается на обработку удаленной процедурой. В этом случае процедура будет выполнена несколько раз. Представление данных Когда клиент и сервер выполняются в одной системе на одном компьютере, проблем с несовместимостью данных не возникает. И для клиента и для сервера данные в двоичном виде представляются одинаково. В случае удаленного вызова дело осложняется тем, что клиент и сервер могут выполняться на системах с различной архитектурой, имеющих различное представление данных. Большинство реализаций системы RPC определяют некоторые стандартные виды представления данных, к которым должны быть преобразованы все значения, передаваемые в запросах и откликах. Например, формат представления данных в RPC фирмы Sun Microsystems следующий: 1. Порядок следования байтов - Старший - последний 2. Представление значений с плавающей точкой - IEEE 3. Представление символа - ASCII Сеть По своей функциональности система RPC занимает промежуточное место между уровнем приложения и транспортным уровнем. В соответствии с моделью OSI этому положению соответствуют уровни представления и сеанса. Таким образом, RPC теоретически независим от реализации сети, в частности, от сетевых протоколов транспортного уровня. Программные реализации системы обычно поддерживают один или два протокола. Например, система RPC разработки фирмы Sun Microsystems поддерживает передачу сообщений с использованием протоколов TCP и UDP. Выбор того или иного протокола зависит от требований приложения. Выбор протокола UDP оправдан для приложений, обладающих следующими характеристиками: § Вызываемые процедуры идемпотентны (Повторное выполнение процедуры не вызывает накапливающихся изменений. Чтение файла идемпотентно, а добавление данных в файл нет). § Размер передаваемых аргументов и возвращаемого результата меньше размера пакета UDP - 8 Кбайт. § Сервер обеспечивает работу с большим количеством клиентов. Поскольку при работе с протоколами TCP сервер вынужден поддерживать соединение с каждым из активных клиентов, это занимает значительную часть его ресурсов. Протокол UDP в этом отношении является менее ресурсоемким С другой стороны, TCP обеспечивает эффективную работу приложений со следующими характеристиками: § Приложению требуется надежный протокол передачи § Вызываемые процедуры неидемпонентны § Размер аргументов или возвращаемого результата превышает 8 Кбайт Выбор протокола обычно остается за клиентом, и система по-разному организует формирование и передачу сообщений. Так, при использовании протокола TCP, для которого передаваемые данные представляют собой поток байтов, необходимо отделить сообщения друг от друга. Для этого например, применяется протокол маркировки записей, при котором в начале каждого сообщения помещается 32-разрядное целое число, определяющее размер сообщения в байтах. В качестве примера можно представить RPC фирмы Sun Microsystems. Система состоит из трех основных частей: § rpcgen(1) - RPC-компилятор, который на основании описания интерфейса удаленной процедуры генерирует заглушки клиента и сервера в виде программ на языке С. § Библиотека XDR (eXternal Data Representation), которая содержит функции для преобразования различных типов данных в машинно-независимый вид, позволяющий производить обмен информацией между разнородными системами. § Библиотека модулей, обеспечивающих работу системы в целом.
Уровень представления (Presentation layer)
Осуществляет промежуточное преобразование данных исходящего сообщения в общий формат, который предусмотрен средствами нижних уровней, а также обратное преобразование входящих данных из общего формата в формат, понятный получающей программе. Назначением представительного уровня является обеспечение независимости прикладных взаимодействующих сущностей (A-entities) от использования конкретного синтаксиса (кодирования) передаваемой информации. Таким образом, на этом уровне решается проблема представления данных, подлежащих передаче между прикладными сущностями, а именно представление структур данных, которыми прикладные сущности обмениваются. Представительный уровень имеет дело с синтаксисом, т.е. с представлением данных, а не с их семантикой, известной только прикладным сущностям. Представление данных с помощью общего синтаксиса освобождает прикладные сущности от необходимости заботиться о проблеме унифицированного представления информации. Таким образом, обеспечивается независимость прикладных сущностей от синтаксиса представления прикладных данных, благодаря чему прикладные сущности могут использовать любой локальный синтаксис, а представительный уровень выполняет необходимые преобразования между этими синтаксисами и общим синтаксисом. Функции представительного уровня включают: -запрос на установление сеансового соединения и его разъединение (в случае режима обмена с соединением), -передачу данных, -согласование и пересогласование выбора синтаксиса, -преобразование синтаксисов, -кодирование структур данных в битовые представления и декодирование из битовых представлений в структуры данных в заданном синтаксисе, -специальные преобразования (например, сжатие и шифрация передаваемых данных). Поясним некоторые функции, связанные с синтаксическим представлением данных и манипулированием синтаксисом представления. Имеются три возможных синтаксиса данных: · синтаксис, используемый прикладной сущностью-отправителем, · синтаксис, используемый прикладной сущностью-получателем и · синтаксис, используемый между представительными сущностями (синтаксис передачи). Два из них или даже все три синтаксиса могут быть идентичными. Представительный уровень содержит функции, необходимые для выполнения преобразования между синтаксисом передачи и каждым из остальных двух локальных синтаксисов по мере необходимости. Для ISO не вводится единого заранее установленного синтаксиса передачи. Синтаксис передачи, который будет использоваться для конкретного представительного соединения, может определяться динамически в процессе согласования между сущностями-корреспондентами представительного уровня. Таким образом, сущность представительного уровня (или просто представительная сущность - P-entity) должна знать синтаксис своего пользователя и оговоренный синтаксис передачи, идентификатор которого используется в протоколах представительного уровня. Согласование синтаксиса осуществляется посредством диалога между представительными сущностями. В процессе согласования определяется, какие преобразования необходимо выполнить (если такая необходимость имеется) и где они должны выполняться в процессе сеанса. Фактически функции уровня представлений часто реализуются в протоколах, функционирующих на прикладном уровне.
|
