TLS (англ. Transport Layer Security) — криптографический протокол, обеспечивающий защищённую передачу данных между узлами в сети Интернет.
TLS-протокол основан на Netscape SSL-протоколе версии 3.0 и состоит из двух частей — TLS Record Protocol и TLS Handshake Protocol. Различие между SSL 3.0 и TLS 1.0 незначительные, поэтому далее в тексте термин «SSL» будет относиться к ним обоим.
TLS Working Group, основанная в 1996 году, продолжает работать над протоколом.
Описание
TLS предоставляет возможности аутентификации и безопасной передачи данных через Интернет с использованием криптографических средств. Часто происходит лишь аутентификация сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих сообщений и создания поддельных.
SSL включает в себя три основных фазы:
* Диалог между сторонами, целью которого является выбор алгоритма шифрования
* Обмен ключами на основе криптосистем с открытым ключом или аутентификация на основе сертификатов.
Алгоритм процедуры установления соединения по протоколу TLS handshake
Клиент и сервер, работающие по TLS, устанавливают соединение, используя процедуру handshake («рукопожатие»). В течение этого handshake, клиент и сервер принимают соглашение относительно параметров, используемых для установления защищенного соединения.
* Последовательность действий при установлении TLS соединения:
o клиент подключается к серверу, поддерживающему TLS, и запрашивает защищенное соединение;
o клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
o сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые также поддерживаются сервером, и сообщает о своем выборе клиенту;
o сервер отправляет клиенту цифровой сертификат для собственной идентификации. Обычно цифровой сертификат содержит имя сервера, имя доверенного центра сертификации и открытый ключ сервера;
o клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
o для того чтобы сгенерировать сеансовый ключ для защищенного соединения, клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ;
Handshake в деталях
Согласно протоколу TLS приложения обмениваются записями, инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована MAC в зависимости от текущего состояния соединения (состояния протокола). Каждая запись в TLS содержит следующие поля: content type (определяет тип содержимого записи), поле, указывающее длину пакета, и поле, указывающее версию протокола TLS.
Когда соединение только устанавливается, взаимодействие идет по протоколу TLS handshake, content type которого 22.
Ниже описан простой пример установления соединения:
1. Клиент посылает сообщение ClientHello, указывая наиболее последнюю версию поддерживаемого TLS протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS.
2. Сервер отвечает сообщением ServerHello, содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом.
3. Сервер посылает сообщение Certificate, которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен)
4. Сервер может запросить сертификат у клиента, в таком случае соединение будет взаимно аутентифицировано.
5. Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание handshake.
6. Клиент отвечает сообщением ClientKeyExchange, которое содержит PreMasterSecret открытый ключ, или ничего (опять же зависит от алгоритма шифрования).
7. Клиент и сервер, используя PreMasterSecret ключ и случайно сгенерированные числа, вычисляют общий секретный ключ. Вся остальная информация о ключе будет получена из общего секретного ключа (и сгенерированных клиентом и сервером случайных значений).
8. Клиент посылает ChangeCipherSpec сообщение, которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе handshake алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22.
9. Клиент посылает сообщение Finished, которое содержит хеш и MAC (код аутентификации сообщения), сгенерированные на основе предыдущих сообщений handshake.
10. Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удается, handshake считается неудавшимся и соединение должно быть оборвано.
11. Сервер посылает ChangeCipherSpec и зашифрованное Finished сообщение и в свою очередь клиент тоже выполняет расшифровку и проверку.
С этого момента handshake считается завершенным, протокол установленным. Все последующее содержимое пакетов идет с типом 23, а все данные будут зашифрованы.
Алгоритмы, использующиеся в TLS
В данной текущей версии протокола доступны следующие алгоритмы:
* Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza.
* Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES;
* Для хэш-функций: MD5 или SHA.
Алгоритмы могут дополняться в зависимости от версии протокола.
SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.
Использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надёжность передачи данных за счёт использования корректирующих кодов и безопасных хэш-функций.
SSL состоит из двух уровней. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции (то есть формирования пакета) различных протоколов (SSL работает совместно с таким протоколами как POP3, IMAP, XMPP, SMTP и HTTP). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнёт передавать и получать данные.
Для доступа к веб-страницам, защищённым протоколом SSL, в URL вместо обычного префикса (schema) http, как правило, применяется префикс https, указывающий на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https — 443.
SSL разработан для самостоятельной установки и использования пользователем, без дальнейшей существенной поддержки поставщиком, причем техническая документация (описание алгоритмов криптографических преобразований, протоколы взаимодействия, описание интерфейсов и т.д.) для SSL является общедоступной.
SSL, как правило, является компонентом операционных систем, криптографические возможности которых не могут быть изменены обычными пользователями.
Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.
Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).
Принцип
Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова локальных процедур являются:
* Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
* Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:
* Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.
* В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.
* Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.
* Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.
Подсистемы
* Транспортная подсистема
— управление исходящими и входящими соединениями. — поддержка понятия «граница сообщения» для транспортных протоколов, не поддерживающих его непосредственно (TCP). — поддержка гарантированной доставки для транспортных протоколов, не поддерживающих ее непосредственно (UDP).
* Пул потоков (только для вызываемой стороны). Предоставляет контекст выполнения для вызванного по сети кода.
* Маршаллинг (также называется «сериализация»). Упаковка параметров вызовов в поток байт стандартным образом, не зависящим от архитектуры (в частности, от порядка байт в слове). В частности, ему могут подвергаться массивы, строки и структуры, на которые указывают параметры-указатели.
* Шифрование пакетов и наложение на них цифровой подписи.
* Аутентификация и авторизация. Передача по сети информации, идентифицирующей субъект, осуществляющий вызов.
В некоторых реализациях RPC (.NET Remoting) границы подсистем являются открытыми полиморфными интерфейсами, и возможно написать свою реализацию почти всех перечисленных подсистем. В других реализациях (DCE RPC в Windows) это не так.
* Network File System
Вызов удаленных процедур (RPC) Концепция удаленного вызова процедур
Идея вызова удаленных процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова локальных процедур являются:
* Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
* Синхронность, то есть выполнение вызывающей процедуры при останавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут «осиротевшими», а при аварийном завершении удаленных процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.
Кроме того, существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем. Базовые операции RPC
Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов
count=read (fd, buf, nbytes);
где fd — целое число, buf — массив символов, nbytes — целое число.
Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.
Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.
Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.
Решение о том, какой механизм передачи параметров использовать, принимается разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке С, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.
NetBIOS (Network Basic Input/Output System)
— протокол для работы в локальных сетях на персональных ЭВМ типа IBM/PC, разработан в виде интерфейса, который не зависит от фирмы-производителя. Был разработан фирмой Sytek Corporation по заказу IBM в 1983 году. Он включает в себя интерфейс сеансового уровня (NetBIOS interface), в качестве транспортных протоколов использует TCP и UDP.
Особенностью NetBIOS является возможность его работы поверх разных протоколов, самыми распространёнными/известными из которых являются NetBEUI, IPX и TCP/IP; причём если старые версии Windows ориентировались на более лёгкие в реализации и менее ресурсоёмкие NetBEUI и IPX, то современные Windows ориентируются на TCP/IP. При использовании NetBEUI и IPX NetBIOS сам обеспечивает надёжность доставки данных (функциональность SPX не использовалась), а при использовании TCP/IP надёжность доставки обеспечивает TCP, за что удостоился отдельного имени "NBT".
Интерфейс NetBIOS представляет собой стандартный интерфейс разработки приложений (API) для обеспечения сетевых операций ввода/вывода и управления нижележащим транспортным протоколом. Приложения, использующие NetBIOS API интерфейс, могут работать только при наличии протокола, допускающего использование такого интерфейса.
NetBIOS также определяет протокол, функционирующий на сеансовом/транспортном уровнях модели OSI. Этот протокол используется протоколами нижележащих уровней, такими как NBFP (NetBEUI) и NetBT для выполнения сетевых запросов ввода/вывода и операций, описанных в стандартном интерфейсном наборе команд NetBIOS. То есть NetBIOS сам не поддерживает выполнение файловых операций. Эта функция возлагается на протоколы нижележащих уровней, а сам NetBIOS обеспечивает только связь с этими протоколами и NetBIOS API интерфейс.
NetBIOS обеспечивает:
* Регистрацию и проверку сетевых имен
* Установление и разрыв соединений
* Связь с гарантированной доставкой информации
* Связь с негарантированной доставкой информации
* Поддержку управления и мониторинга драйвера и сетевой карты
AppleTalk — это стек протоколов, разработанных Apple Computer для компьютерной сети. Он был изначально включён в Macintosh (1984), сейчас компания отказалась от него в пользу TCP/IP.
Основные сведения
Соответствующая сеансовому уровню модели OSI версия AppleTalk состоит из пяти протоколов, поддерживающих полностью дуплексную передачу данных, преобразование логических названий в адреса, доступ к принтеру, переупорядочение пакетов и т. д.
Первый протокол сеансового уровня называется протоколом потоков данных (AppleTalk Data Stream Protocol — ADSP). Протокол ADSP предоставляет полностью дуплексные услуги, ориентированные на установление соединения и характеризующиеся высокой степенью надёжности. Такая надёжность достигается путём установления логического соединения (сеанса) между двумя взаимодействующими процессами на клиентских машинах. Протокол ADSP позволяет управлять этим соединением, обеспечивая контроль потока данных, переупорядочение пакетов и рассылку подтверждений о приёме пакетов. Для установления логического соединения между процессами используются номера сокетов. После установления соединения две системы могут начать обмен данными.
Следующим протоколом сеансового уровня AppleTalk является собственно сеансовый протокол (AppleTalk Session Protocol — ASP). Протокол ASP обеспечивает надёжную доставку данных, используя для этого ориентированное на корректность принятых последовательностей управление сеансом (sequence-oriented session management), и предоставляет доступ к транспортным услугам протокола транспортного уровня AppleTalk Transport Protocol (ATP).
Протокол маршрутизации с обновлением среды AppleTalk (AppleTalk Update-Based Routing Protocol — AURP) используется в больших сетях AppleTalk и применяется в основном для маршрутизации и поддержки обмена информацией между маршрутизирующими устройствами, в частности, между маршрутизаторами Exterior Gateway.
Кроме того, в состав сеансового уровня AppleTalk входит протокол доступа к принтеру (Printer Access Protocol — PAP). Несмотря на то что первоначально протокол РАР был разработан для управления доступом к сетевым принтерам, он может использоваться для обеспечения обмена данными между разнообразными устройствами. Между устройствами устанавливается двунаправленное соединение и одновременно осуществляется управление потоком данных и контроль последовательности пакетов.
И, наконец, последний протокол сеансового уровня AppleTalk, — протокол зонной информации (Zone Information Protocol — ZIP). Протокол ZIP предоставляет механизм логического группирования отдельных сетевых устройств с помощью «дружественных» имен. Такие логические группы называются зонами (zones). В расширенной сети компьютеры могут охватывать несколько сетей, но оставаться при этом логически сгруппированными в одну зону. Однако в небольших, нерасширенных сетях может быть определена единственная зона.
Для преобразования названия зон в номера сетей и узлов ZIP использует протокол связывания имен (Name Binding Protocol — NBP), принадлежащий транспортному уровню. Для рассылки данных об изменении конфигурации зоны используется протокол АТР.
Пять протоколов сеансового уровня AppleTalk предоставляют клиентам возможность устанавливать логическое соединение и обмениваться данными между компьютерами вне зависимости от расстояния между ними.