Размер полей 1 байт, 2 байта, 16 байт и 20 байт

Вид материала

Подобный материал:

Лекция №5

17.03.2009

Гурьев

Размер полей 1 байт, 2 байта, 16 байт и 20 байт.

Хэш считается по одной формуле для обеих функций. Только в первом случае используется MD5, а во втором SHA.

Формула хэша

pad1 и pad2 это некоторая константа

sender это тоже некоторая константа, но она отличается от того, клиент это посылает или сервер.

Считается два раза, только в первом случае используется MD5, а во втором SHA.

Pad1 это 0x36 повторенное n-ое количество раз (48 для MD5 или 40 для SHA) что бы общая длина была фиксированная.

Pad2 аналогично 0x5C, повторенное столько же раз. Запоминать это бессмысленно, это просто константы зафиксированные в протоколе ничего из себя не представляющие.

Sender это две константы. Когда посылает клиент, то sender = 0x434E54, если сервер, то 0x535256. С её помощью идентифицируется сторона.

Messages – все сообщения HP, предшествующие данному. То есть, фактически хэш берется по всему тексту предыдущего взаимодействия HP (Handshake Protocol). Напоминаю, что сюда входит разные вещи и в частности два случайных числа – ServerRandom и ClientRandom. Это полуавтоматически обеспечивает защиту от атаки повторений. Перехватить такой handshake, а потом ответы его посылать в ответ как бы поддерживая диалог не получится, потому что в следующем диалоге эти случайные числа ServerRandom и ClientRandom должны быть другими. И если одним из них, скажем, ClientRandom злоумышленник управляет, то второй он предсказать не может. И аналогично наоборот. Разумеется, когда эти сообщения приходят, то другая сторона точно так же этот хэш пересчитывает и любое несовпадение означает, что в процессе handshake произошла какая-то ошибка или вмешательство злоумышленника, и значит, соединение должно быть разорвано.

Собственно это основная процедура установления SSL соединения. Но есть варианты. Рассмотрим их. Но сначала надо восстановить исходную последовательность.

Есть Client и Server. Идет ClientHello. Потом ServerHello. Потом ServerCertifitate и ServerKeyExchange. Из последних двух бывает что посылается какое-то, бывает что посылается оба. ServerHelloDone. ClientKeyExchange. ChangeCipherSpec и Finished от клиента. И в обратную сторону ChangeCipherSpec и Finished от сервера.

По умолчанию в SSL сервер доказывает свою подлинность, а клиент нет. Сервер сам посылает свой сертификат. Сообщение не посылается только если сервер почему-то не может послать сертификат. Стандартно, это когда сертификат есть и он посылается.

Но есть вариант соединения, когда и клиент должен представить свой сертификат. Если сервер требует сертификат, то он посылает специальное сообщение перед ServerHelloDone, которое называется CertificateRequest.

Тогда в ответ клиент должен послать сообщение ClientCertificate после ClientKeyExchange. Клиент по умолчанию не аутентифицируется, а если сервер жэтого хочет, то он должен это сказать.

Рассматриваем эти два сообщения.

CertificateRequest

Начало стандартное для сообщений handshake протокола.

Дальше количество элементов и дальше сами элементы. CT это CertificateType – тип алгоритмов электронной подписи, которые умеет проверять данный сервер.

И следующее поле N – количество элементов и последовательность полей переменной длины (с префиксом длины), в которых имена удостоверяющих центров, которым сервер доверяет. То есть, что бы сертификационный путь заканчивался на одном из этих центров. Имена в смысле X.500.

ClientCertificate

По формату оно такое же, как и ServerCertificate.

Тип, длина, и некоторое количество сертификатов X.509 – сертификационный путь.

Если у клиента нет сертификата, он может и не послать его. Но это уже вопрос политики сервера, продолжать с таким клиентом работать или немедленно разорвать соединение. Возможны и промежуточные варианты, например, работать с таким клиентом как неаутентифицированным. Но это уже не имеет отношения к протоколу, а есть вопрос авторизации.

Еще один вариант - сокращенный Handshake. Для установления дополнительных соединений.

Клиент посылает сообщение ClientHello. В этом сообщении идентификатор сеанса не пустой. Если сервер про такой сеанс еще помнит и согласен его продолжить, то сервер отвечает сообщением ServerHello, в котором передается тот же самый идентификатор сеанса. Это уже согласие установить дополнительное соединение в рамках сеанса. После этого стороны в асинхронном порядке обмениваются сообщениями ChangeCipherSpec, то есть в этот момент проводят криптографические вычисления параметров соединения. Мы с вами помним, что были параметры сеанса, и в частности основной секрет, и параметры соединения. Вычисляются только параметры соединения, основной секрет остается прежним. И потом в том же порядке стороны обмениваются сообщениями Finished. И после этого соединение считается установленным. Но обратите внимание, что в этих сообщениях новые случайные числа, предложенные сервером и клиентом. Это означает, что в новом соединении рабочие ключи будут не такие как предыдущие. Компрометация ключа в одном соединении не нарушает безопасность в другом. Эти соединения можно устанавливать параллельно, а можно после (не останавливая сеанса). Если политика сервера это позволяет, то есть закрыть соединение, а потом открыть еще одно соединение, считающееся частью этого сеанса. Протокол разрешает и то, и другое.

Смена ключей.

Любая из сторон может решить, что пора поменять ключи. Если это решает клиент, то клиент просто посылает сообщение ClientHello с пустым SessionID. После этого сеанс начинает по новой устанавливаться. Снова сеанс, снова подключение и далее

Если сервер решил, что пора поменять ключи. Сервер же не может сам начать. На этот счет есть специальное сообщение HelloRequest, которое посылает сервер, а клиент на это сообщение должен ответить сообщением ClientHello. И дальше все по новой.

HelloRequest это сообщение из трех байт. Там нет данных. Только поле типа и поле двухбайтное

Итак, существует четыре вариации основной процедуры handshake. И на этом протокол Handshake мы закончим. Да и SSL тоже.

Единственное, что я забыл вам рассказать о том, как считается MAC в этом протоколе. Это функция RecordLayer.

MAC = H(mac_secret || pad2 || H(mac_secret || pad1 || seqN₁ || Length || data))

H – выбранная согласованная функция, либо MD5, либо SHA.

mac_secret – это либо client_write_mac_secret, либо server_write_mac_secret. В зависимости от того, какая из сторон посылает это сообщение.

seqN₁ – номер последовательности в данном направлении, который никогда не передается по сети, но который обе стороны синхронно подсчитывают. Таким образом, последовательность сообщений сохраняется. В другую сторону будет другой номер последовательности.

Length – это длина блока данных, того что в RecordLayer включено выше хеша.

Date – записи в блоке данных RecordLayer.

На этом с SSL закончим.

Протокол Kerberos

Протокол Kerberos предназначен для тех же целей, что и протоколы SSL и SSH. И расположен он примерно так же в стеке протоколов. То есть он встраивается между транспортным и прикладным уровнем. Но Kerberos использует протокол UDP, ну а сверху может быть что-то, что предполагает передачу потока. Предусмотрена передача зашифрованных данных. Но самое интересное в Kerberos не это. Самое интересное это процедура аутентификации сторон. И интересно в ней то, что она обеспечивает возможности практически такие же, как система на открытых ключах (ассиметричных алгоритмах). Но при этом никаких открытых ключей не используются, используются только симметричные алгоритмы шифрования. В версии 4 вообще допускался только один алгоритм DES, в версии 5 появился механизм, которых позволяет расширять список используемых алгоритмов шифрования. Всё только на симметричных алгоритмах шифрования. Но, тем не менее, на основе Kerberos можно построить системы из многих сетей, из многих организаций, и потенциально можно построить даже систему, покрывающую весь мир. Правда, это касается только аутентификации сторон при соединении, никакая электронная подпись сформирована не может быть.

Разработан протокол с 1987 по 1993 год в MIT (Массачусетский технологический институт) в рамках проекта Aheno. Известно и широком применении бывало две версии – v4 (про которую есть только технический отчет MIT) и v5 (про которую есть RFC1510, то есть это интернет-стандарт)

Вот это я все говорю, но не сказал одну интересную вещь. Для каких целей и для каких условий разрабатывался этот протокол? Представьте себе большой вычислительный центр. И представьте себе, что вы хотите для этой сети обеспечить безопасность, в частности, что бы все могли выполнять только те действия, которые им разрешены. Дело в том, что в таких ВЦ часто идут длинные-длинные задачи, которые считаются сутками. Оператор при этом может и не присутствовать. Просто некому подходить к терминалу и если задаче потребовался какой-то ресурс набирать логин и пароль. Эти задачи, кроме того, могут быть распределенными. Одна часть задачи считается на одном процессоре, другая на другом, скажем, специализированном, третья часть задачи полезла в БД, четвертая еще куда-то. То есть для условий длинных распределенных задач. Пример такой задачи – синтезированное кино. И вот они хотели разработать систему, которая бы обеспечивала безопасность, но не требовала бы постоянного участия оператора. И центральным понятием в этой системе является так называемый билет (ticket). Это такая зашифрованная последовательность, которая означает возможность воспользоваться каким-то сервером или ресурсом. Этими билетами можно заранее запастись, а потом предъявлять и, таким образом, получать доступ к разным ресурсам. Маленькая второстепенная подробность, но у меня уже не будет времени о ней упомянуть – в билете может быть включена информация для разграничения прав доступа, сам протокол, подобно SSL, разграничением прав доступа не занимается, но информация для прикладных серверов, необходимая для разграничения прав доступа, может быть туда включена. Таким образом, можно еще и разграничения прав доступа централизовано вести. Сейчас нечто подобное в мире персональной техники делает MS Active Directory. Kerberos-сервера появились лет на 10-15 раньше.

Общая архитектура системы.

Всё множество хостов, которое делится на клиентские машины и сервера, объединяются в area – область защиты. В этой area обычно бывает Kerberos Server. И обычно этот сервер делится на две части: AS – Authentication Server и TGS – Ticket Granting Server. То есть эти две части могут быть даже на разных хостах. Сервер аутентификации и сервер раздачи билетов. Хотя на самом деле билет можно получить и на сервере аутентификации тоже. Суть в том, что сервер аутентификации непосредственно аутентифицирует пользователей.

Как может выглядеть обращение к серверу?

Сценарий 1.

Клиент обращается к AS, доказывает ему свою подлинность и в ответ получает билет на сервер, к которому он хочет обратиться. И после этого он предъявляет этот билет на сервер. Во-первых, сервер понимает кто этот клиент на самом деле (аутентификация клиента), а во-вторых, сервер понимает, что этому клиенту разрешено обращаться к этому серверу, и в-третьих, если они захотят по защищенному протоколу общаться, то вся информация для установления защищенного соединения у них есть (в частности, ключ). И дальше уже начинается обмен между ними.

Если применять такой сценарий, то каждый раз, когда понадобится новый сервер, придется вводить логин-пароль.

Сценарий 2.

Начинает он так же, сообщение для аутентификации AS, а в ответ возвращается билет на сервер TGS (это же тоже сервер, значит, для него тоже можно выдать билет). А следующим сообщением, которых на самом деле может быть много, с сервера раздачи билетов получаем билет на конкретный сервер. И это можно делать многократно, и это можно делать без участия человека. И, соответственно, обращения пойдут с тем билетом, который выдал TGS. Такая возможность основана на том, что TGS это такой же сервер как и все и на него тоже можно выдать билет.

Некоторое развитие этой системы заключается в том, что сторона клиента может получить билет не только для себя, но для другой машины. Например, рабочая станция получает доступ к серверу базы данных, и получает билет к серверу печати, но так что бы клиентом не сама эта станция была, а этот сервер БД.

После этого сервер БД получает возможность самостоятельно, от имени этого пользователя обращаться к серверу печати в автоматическом режиме. Такой механизм называется проксирование.

А есть еще механизм форвардинга. Похожий по смыслу, но дающий совершенно другие возможности. Это выдача билета на сервер раздачи билета в чужой автономной области.

Клиентская машина, Kerberos Server, внутри TGS.

Запрашивает билет
Получает билет на второй сервер раздачи билетов, который принадлежит области2.
Предъявляет этот билет на TGS2
Получаем билет на некоторый сервер в области2.
Предъявляет билет на этот сервер и пользуется его услугами.

Тут есть одна тонкость. Идентифицируется он исходно в области1, а услуги он в другой. Между двумя этими областями должно быть установлено определенные отношения доверия. По умолчанию, никаких отношений доверия нет. То есть, если одного удостоверяет другой, то такое отношение можно организовать. Ну а дальше понятно, что из таких областей можно построить такую сетевую или иерархическую структуру, которая потенциально могла бы покрыть весь мир. Другое дело, что это никому не надо.

Состав билета.

Во-первых, билет всегда выдается кому-то и на какой-то сервер. То есть это функция пары взаимодействующих субъектов.

Основные поля в билете

VerNo=5 Номер ревизии. Фактически это номер версии протокола.
Srealm – имя области сервера
Sname – имя сервера

Srealm и sname можно рассматривать как идентификатор сервера

Эти три поля – открытая часть билета, все остальное не будет видно никому.

Type – код алгоритма шифрования. Если 1, то DES
Key – общий ключ, общий секрет будущего сеанса между клиентом и сервером. Его выбирает тот, кто выдал билет.
Flags – слово, в котором могут быть установлены или сброшены отдельные биты, но эти биты много чего значат.

не используется
forwardable. Разрешение выдать на основе данного билета билет на другой TGS.
forwarded бит установлен в дочернем билете
proxiable разрешение выдать билет для использования с другого IP адреса
proxy установлен, когда это сделано
maypostdate разрешение на основе данного билета выпускать билеты далеко в будущее
postdated отмечают когда это так.
invalid нерабочий билет. Но его можно предъявить на TGS, и получить взамен рабочий.
renewable возобновляемый. Значит, когда время действия билета закончится, то этот билет можно предъявить на TGS и получить точно такой же, но с валидным сроком действия.
initial выдан AS. То есть при получении этого билета пользователь водил логин-пароль и собственноручно доказывал, что он это он. Считается, что такие билеты нужно отличать от билетов, выданных механически.
PreAuth Дополнительные функции аутентификации пользователя
HWAuth Дополнительные функции аутентификации пользователя

Crealm – идентификатор клиента
Cname – идентификатор клиента
Transited – список пройденных областей. Если клиент получил билет в чужой области, а из неё получил билет еще в чужую область, а еще получил билет еще в чужую область, то здесь оказывается список всех этих областей. Это аналог сертификационного пути в X.509. И этот список нужен, что бы можно было настроить политики на Kerberos-серверах – каким областям мы доверяем, а каким нет. Соответственно билеты с одними путями будут приниматься, а с другими нет. Это возможность, которая довольно редко используется.
Authtime – время аутентификации пользователя. Время, когда пользователь собственноручно ввел пароль. Некоторым сервисам все равно когда пользователь ввел пароль, а некоторым не все равно. Если это время слишком большое, то такой билет будет считаться недействительным. Но это уже даже не политики Kerberos-сервера, а вопрос политики конкретного сервиса. Например, сервис смены пароля. Ввести новый пароль можно только в течение нескольких секунд после ввода предыдущего. Опоздал – давай по новой.
Starttime – период действия билета
Endtime – период действия билета
Renewaltime – время окончания действия всех дочерних билетов
Caddr – IP адреса клиента, с которого можно пользоваться этим билетом. Ну мы видели ситуацию, когда от имени пользователя кто-то третий обращается в серверу, вот IP-адрес в этом случае будет другой. Тут может быть целый список.
Authorizationdata – данные для авторизации. Kerberos их никак не использует, он просто их пропускает. Под авторизацией я имею в виду настройки сеанса. Конфигурационная информация, адресованная прикладному сервису. Эти настройки сеанса, в частности, могут включать ограничения прав пользователя. Например, для протокола ftp или nfs это может быть ограничение по каталогам, в какие файлы можно заходить, а в какие нельзя.

Это все зашифровано ключом сервера

Тут мне надо сделать отступление и сказать что такое ключ сервера.

Если говорить о серверах, то в Kerberos имеются предустановленные ключи для каждого сервера. Для каждого сервера имеется ключ этого сервера. И этот ключ известен самому серверу и Kerberos. И больше никому. Kerberos эксплуатирует идею установления соединения через доверенные серверы. Что касается пользователей, то у пользователя нет ключа, у него есть пароль. Ключ пользователя – некая одностороння функция от этого пароля. Таким образом, люди запоминают то, что им удобно, а машина работает с тем, что её удобно. Можно считать, что есть заранее распределенные ключи для общения Kerberos с каждым конкретным сервером и с каждым конкретным пользователем.

И вот таким ключом сервера большая часть билета зашифрована.

Blog

Размер полей 1 байт, 2 байта, 16 байт и 20 байт

CertificateRequest