Массачусетский Институт Технологий.
Курс лекций №6.858. «Безопасность компьютерных систем».
Николай Зельдович, Джеймс Микенс.
2014 год Безопасность компьютерных систем — это курс, посвященный проектированию и внедрению безопасных компьютерных систем.
Лекции охватывают модели угроз, атаки, ставящие под угрозу безопасность, а также методы обеспечения безопасности, основанные на последних научных работах.
Темы включают безопасность операционной системы (ОС), возможности, управление информационными потоками, языковую безопасность, сетевые протоколы, аппаратную безопасность и безопасность веб-приложений.
Лекция 1: «Введение: модели угроз» Часть 1 / Часть 2 / Часть 3 Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3 Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3 Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3 Лекция 5: «Откуда берутся ошибки системы безопасности» Часть 1 / Часть 2 Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3 Лекция 7: «Нативная клиентская песочница» Часть 1 / Часть 2 / Часть 3 Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3 Лекция 9: «Безопасность веб-приложений» Часть 1 / Часть 2 / Часть 3 Лекция 10: Символическое исполнение Часть 1 / Часть 2 / Часть 3 Лекция 11: «Язык ур/веб-программирования» Часть 1 / Часть 2 / Часть 3 Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3 Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3 Студент: клиент не может расшифровать этот билет, поскольку он зашифрован с помощью служебного ключа.
Профессор: да, это действительно умно, не так ли? У нас есть ключ Kc,s, который может получить клиент, но здесь в билете Tc,s есть еще одна копия этого ключа, зашифрованная Ks. 
Причина, по которой это делается, заключается в том, что сервер Kerberos на самом деле пытается защитить связь клиента с другим парнем.
Поэтому Kerberos создает случайный ключ Kc,s и передает одну копию клиенту, а другую — серверу, с которым клиент собирается общаться.
Представьте себе, если бы Kerberos просто позвонил в службу и сказал: «Эй, служба, этот парень хочет с вами поговорить, вот ключ для этого»! Это было бы неудачно, поскольку сервер Kerberos будет обращаться к службе снова и снова при каждом запросе.
Таким образом, KDS создает две копии сеансового ключа: одну для клиента и одну для TGS. Поэтому вместо этого разработчики придумали красивый трюк, когда они предъявляют этот билет клиенту, а он ничего с ним не может сделать, кроме как передать его в нужный сервис.
И если у этого сервиса есть правильный ключ Ks, он его расшифрует и скажет: «Да, это ключ, который мне следует использовать для общения с этим клиентом».
Таким образом, обе стороны соединения, клиент и служба, установят общий ключ для защиты своего соединения.
Студент: так что такое ТГС? Профессор: Существует две точки зрения на то, что такое TGS. С точки зрения клиента, это просто еще одна услуга, на использование которой можно получить билет. Чем больше функций предоставляет эта услуга, тем больше билетов она предоставляет. По сути, это сервис по выдаче билетов.
Студент: Извините, я имел в виду, что наш билет называется TGS. Профессор: ой, да, извините, надпись tgs под стрелкой на этой схеме — это всего лишь аббревиатура всего блока записи, за исключением индекса s в параметре Tc,s, который означает собственно название этого сервиса — TGS. Вы можете представить, что у нас есть сервер Kerberos, есть служба TGS и есть сама служба, к которой вы хотите получить доступ.
Поэтому сначала вам нужно попросить Kerberos предоставить вам билет для получения доступа к определенной службе.
Вы можете попросить Kerberos предоставить вам билет непосредственно на файловый сервер, и это может сработать.
Но для этого вам понадобится ваш Кс для расшифровки и все остальное время вы пользуетесь сервером.
Вместо этого вы получаете билет на специальную услугу TGS. Выглядит так же, как и другие сервисы, за исключением того, что находится в отдельном боксе.
И он с радостью предоставит вам больше билетов позже, без необходимости снова предоставлять исходный клиентский ключ Kc. Студент: Итак, его идея состоит в том, что как только вы получите билет TGS, вы сможете просто избавиться от своего ключа Kc? Профессор: да, самое крутое в этом то, что как только вы получаете этот билет Tc,s от сервиса TGS, вы избавляетесь от пароля и ключа Kc. Таким образом, как только вы войдете на рабочую станцию Athena и в течение пары секунд получите билет Tc,s, ваш пароль будет удален из памяти.
Поэтому даже если кто-то схватит вас, заберет ваш компьютер и убежит с ним, все, что у него будет, — это ваш билет. Хорошо, если он сможет получить доступ к вашей информации на 10 часов, или на срок действия билета, но не дольше, потому что пароль не сохраняется и при следующем входе в Афину вам нужно будет вводить его заново.
.
Единственный раз, когда вам нужен пароль, — это когда вы отправляете запрос на сервер Kerberos, вы получаете этот ответ с билетом и расшифровываете его.
После этого о пароле можно забыть.
Но, конечно, вы не можете сбросить пароль, прежде чем использовать его для расшифровки.
Таким образом, первый, верхний интерфейс C на нашей схеме используется для получения билета с начальным ключом Кс, а второй, нижний интерфейс S — для доступа к сервисам, но без необходимости получения начального ключа Кс.
Итак, мы уже говорили о двух конкретных проблемах протокола Kerberos, которые, похоже, в него встроены и доставляли определенные неудобства.
Во-первых, создатели предполагали, что шифрование также обеспечит аутентификацию или целостность сообщения, но этого не произошло.
Этот недостаток исправлен в версии Kerberos 5, которая обеспечивает явную аутентификацию сообщений.
Во-вторых, для случайных клиентов была возможность угадывать чужие пароли.
Как это можно исправить? Как предотвратить атаки по подбору пароля в этих типах протоколов? Что мы можем попробовать? Студент: Я не уверен, но можно попробовать засолить пароль.
Профессор: «Соление» просто означает, что клиенту, возможно, придется хэшировать пароль разными способами.
Но попытаться подобрать его не помешает. Поэтому создание словаря может оказаться дороже.
Студент: Можно попробовать усложнить функцию расчета пароля.
Профессор: да, еще одна хорошая идея — сделать процесс хеширования очень дорогим.
Возможно, это разумно.
Итак, если эта хэш-функция займет секунду вычислительного времени, как вы, ребята, сделали во второй лаборатории, то угадывание паролей станет очень дорогостоящим занятием.
Поэтому кажется разумным план использовать комбинацию подсола и усложнения процесса угадывания.
Еще один способ обезопасить себя — усложнить ответ. Вы слышали, что в первых версиях протокола сервер Kerberos понятия не имел, обращается к нему нужный клиент или нет. Что вы можете сделать, так это предоставить доказательство того, что вы являетесь правильным клиентом, то есть зашифровать текущую временную метку с помощью хэша пароля или что-то в этом роде.
Затем сервер Kerberos может просто проверить, верны ли эти данные, и, если они совпадают, выдать вам билет. Вероятно, вы не захотите добавлять дополнительные этапы проверки, но это может сработать.
А пока давайте предположим, что мы можем взять временную метку и хешировать ее вместе с ключом Kc, а затем просто добавить временную метку.
В этом случае сервер может видеть, что у него есть ваш ключ Kc, а также может хешировать текущую метку времени.
Если он получает то же значение, то запрос, вероятно, был сделан тем пользователем, которому нужно отправить билет. Если нет, то это был неверный пароль.
Студент: можно просто ограничить выдачу билетов, если серверы фиксируют слишком много запросов на них.
Профессор: Правильно, мы можем ввести ограничение.
Однако у хакера нет причин запрашивать билет с сервера более одного раза.
Он просто запрашивает конкретного пользователя, получает от него этот зашифрованный блок и может пытаться расшифровать его в автономном режиме столько раз, сколько они хотят, с разными паролями, не спрашивая снова.
Так что я думаю, весь смысл защиты в том, чтобы сервер как-то реагировал на количество обращений, если злоумышленник неоднократно опрашивает сервер, пытаясь войти под разными паролями.
В этом случае может быть достигнут лимит запросов, что обеспечит лучшую защиту от взлома.
Студент: как злоумышленник может отправить запрос на сервер Kerberos? Профессор: Я думаю, он мог бы воспроизвести правильное сообщение пользователя, то есть увидеть его, скопировать, отправить, а также получить ответ от сервера Kerberos. Если хакер просматривает сеть, он может перехватить сообщение во время передачи.
Так что ограничение количества запросов — временная мера, лишь немного повышающая безопасность.
Но, конечно, если вы просматриваете чужую сеть, то вы увидите, как этот пакет возвращается с сервера, независимо от того, что произошло на этапе формирования Tс,s. Таким образом, хакер может увидеть ответ сервера клиенту и попытаться атаковать его.
Вероятно, вы могли бы разработать более сложные схемы, но я не думаю, что Kerberos 5 реализует что-то более сложное, чем план, который мы рассмотрели, который кажется достаточно хорошим, чтобы предотвратить попытки случайных людей сломать что-либо или использовать грубую силу.
заставить взломать пароль.
Студент: Давайте предположим, что мы можем обеспечить аутентификацию или что-то еще для установления общего ключа.
И тогда вы сможете зашифровать эту вещь и общий ключ с помощью Kc. Профессор: Да, это.
Если вы действительно все делаете правильно, для этого существует протокол, называемый обменом ключами с проверкой пароля, PAKE, который выполняет аутентификацию по паролю.
Именно это и происходит в Kerberos. 
Можете погуглить, для чего нужны протоколы SRP или PAKE. Эти протоколы и связанные с ними элементы гораздо лучше справляются с поставленной вами задачей, в которой вам нужно доказать обеим сторонам, что вы установили новый ключ.
В этом случае обе стороны должны быть убеждены в правоте друг друга и в том, что нет возможности подобрать этот пароль в автономном режиме и атаковать набор сетевых пакетов, которые вы наблюдаете, и так далее.
Эти протоколы в значительной степени основаны на криптографии, поэтому на доске сложно объяснить, почему они работают. Студент: Одна из причин, почему разработчики сделали это, заключается в том, что они хотели поддержать возможность отправки только пароля.
А протоколы позволяют отправлять в качестве аутентификатора только одну вещь.
Профессор: да, есть много странных требований, которые эти ребята учли.
Конечно, на практике эти серверы могут принимать как соединения Kerberos, так и не-Kerberos. А при соединениях без Kerberos кто-то подключается к почтовому серверу, но не использует рабочую станцию Athena. Он просто хочет отправить свой пароль.
И затем, скажем, почтовый клиент возьмет этот пароль и получит билет от вашего имени, просто чтобы проверить его, что позволит вам использовать этот почтовый клиент. Таким образом, вы, вероятно, по-прежнему хотите, чтобы проверка пароля Kerberos выполнялась самим Kerberos. Я не думаю, что об этом не может быть и речи, потому что, конечно, Kerberos 5 использует эти хэши временных меток и все такое.
Я думаю, что еще одна вещь, которую вы должны заметить в лекции, это то, что разработчики Kerberos 4 выбрали одну схему шифрования, DES, которая была самым популярным алгоритмом шифрования в то время.
Это симметричный блочный шифр, работающий довольно быстро.
В то время это обеспечивало достаточную безопасность, и их просто встроили в протокол.
Все в Kerberos должно было использовать только DES, или, по крайней мере, все в Kerberos версии 4. Это стало проблематичным, потому что сейчас, 25-30 лет спустя, шифрование DES легко поддается подбору, поскольку ключи шифрования имеют очень маленький размер - всего 56 бит. .
Поэтому можно просто создать какое-то пользовательское оборудование, которое будет рассчитывать от 2 до 56 силовых комбинаций и узнавать настоящий пароль.
Это то, чего следует избегать в любом протоколе, разработанном в наши дни.
Kerberos версии 5 поддерживает несколько различных схем шифрования, включая AES и другие криптографические алгоритмы.
Так что это кажется гораздо лучшим способом обеспечить безопасность.
С другой стороны, MIT продолжал поддерживать DES 2 года назад, но сейчас отказался от него, так что на данный момент ваш ректор защищён как минимум от такого типа атак.
Теперь давайте посмотрим, что происходит в сервисе TGS, от которого вы получаете свой билет. Взаимодействие с этим сервисом выглядит немного иначе.
С одной стороны, как клиент, вы будете общаться с ним так, как если бы вы разговаривали с любой другой службой с поддержкой Kerberos. Давайте посмотрим, как вы выполняете собственную аутентификацию с помощью билета на какой-либо машине.
Но ответ, который вы собираетесь вернуть, — это всего лишь билет на какой-то другой принцип, по которому вы будете общаться, например с файловым сервером.
Таким образом, сообщения уровня протокола будут выглядеть так — я нарисую TGS справа, а клиента — слева.
У клиента уже есть билет на TGS, полученный по протоколу, показанному выше.
Теперь клиент собирается отправить некоторую комбинацию сообщений, доказывающих, что это правильный клиент, и эти сообщения имеют отношение к выдаче запроса определенным способом через TGS.
Итак, клиент собирается отправить в TGS следующее сообщение: S — сервис, с которым он собирается общаться дальше, это может быть почтовый или файловый сервер, тогда сюда включается клиентский билет Tc, который он получил за tgs , зашифрованный с помощью ключа K tgs и аутентификатора, который зашифрован с помощью ключа Kc,tgs, общего для клиента и службы TGS. Вот как выглядит сообщение, которое вы собираетесь отправить в TGS: в нем говорится: «Посмотрите на это сообщение, сделайте что-нибудь с ним и ответьте билетом на эту новую услугу S».
Ответ здесь выглядит почти так же, как на картинке выше, и по сути это одно и то же — это билет между клиентом и этим новым сервисом, зашифрованный Ks. Но сейчас здесь дела обстоят немного иначе.
Вместо шифрования с использованием ключа Kc, который клиент, вероятно, с тех пор забыл, теперь происходит шифрование с использованием общего ключа Kc,tgs между клиентом и службой TGS.
Как сервер определяет, чего хочет клиент, и как сервер аутентифицирует клиента? Сервер TGS знает свой собственный ключ Ktgs, поэтому сначала он расшифровает это сообщение Tc,tgs, заглянет внутрь билета и выяснит, что происходит. Зачем нам все эти поля в билете? Почему важно иметь в билете имя сервера S? Что бы пошло не так, если бы у нас не было S? Студент: если бы его не существовало, то потенциально вы могли бы получить разрешение на использование любого сервера.
Профессор: Да, это.
В общем, неплохо было бы составить сетевые протоколы так, чтобы вы могли точно сказать, что означает это сообщение.
В случае, если вы опустите S, вы можете рассчитывать на то, что если вы используете билет для неправильного S, то, возможно, у вас будет другой ключ Ks, и он не сможет выполнить расшифровку или что-то в этом роде.
Так что включить имя сервиса кажется хорошей идеей, чтобы быть уверенным, что сервер, получающий эти билеты, расшифровывает их и проверяет — это билет мой или кого-то другого? Студент: Что делает клиент с полученным ключом Ktgs? Профессор: хороший вопрос! Клиент понятия не имеет, что это такое.
Потому что это совершенно секретный ключ.
Если бы вы это знали, вы бы смогли взломать весь Kerberos. Таким образом, клиент понятия не имеет, что такое Ktgs. Студент: откуда этот Ктгс? Профессор: Сервер Kerberos сам генерирует для вас все это сообщение, которое уже содержит Tc, tgs и Ktgs, вы его не создаете сами, а просто копируете отсюда.
Так почему же имя клиента так важно? Это легко понять.
Если вы не укажете имя клиента в билете, сервер получит сообщение, но не будет знать, с кем он пытается связаться.
Он не знает, кому выдать билет — вам или кому-то другому.
А как насчет других полей? Почему разработчики вставляют адрес addr в билет Tc,s? Это всего лишь IP-адрес клиента, так почему бы не использовать его напрямую? 
Думаю, смысл этого решения в желании разработчиков повысить безопасность.
Они хотели убедиться, что если клиент вошел в систему с определенного IP-адреса, то все остальное в том же билете пришло с того же IP-адреса.
Например, если вы вошли в систему с какого-либо IP-адреса, например 18.26.4.9, то каждое подключение к файловому или почтовому серверу должно осуществляться с одного и того же IP-адреса.
В противном случае сервер должен отклонить ваше соединение, так как может предположить, что кто-то украл ваш билет. Так мы защищаемся от использования ворованных билетов.
Если у вас все еще тот же билет, хорошо, но если вы не используете тот же IP-адрес, у вас ничего не получится.
На данный момент это кажется ошибочным, и Kerberos 5 по-прежнему использует аналогичный подход, хотя в этом нет необходимости.
На самом деле, вам следует просто полагаться на криптографию вместо защиты IP-адреса.
Что означают временная метка и время жизни в билете? Для чего они нужны и чем полезны? Студент: они необходимы для предотвращения атак повторного воспроизведения.
Профессор: Аутентификатор помогает нам предотвратить атаки повторного воспроизведения, поскольку он генерируется каждый раз, когда вы делаете новый запрос.
Но, с другой стороны, билет остается прежним, поэтому он, конечно, не предотвращает атаки повтора.
Студент: это не позволит кому-либо украсть ваш билет и затем использовать его в своих целях.
Профессор: Да, он просто ограничивает время действия билета, тем самым уменьшая ущерб от его кражи.
Временная метка — это время, когда вы получили билет, а срок действия показывает, сколько часов действителен билет с момента первоначальной временной метки.
Поэтому, если вы попытаетесь использовать его слишком рано или слишком поздно, протокол Kerberos потребует от любого сервера отклонить билет. Это означает, что каждый сервер должен синхронизировать свои часы.
Студент: Ранее вы говорили, что клиент может выбросить свой первоначальный ключ, отбросить Kc, но должен сохранить Kc,s, полученные от TGS. Профессор: да, верно, клиент отбрасывает Kc после входа в систему, но должен сохранить Kc,s. Студент: так что, если кто-то украдет Kc,s, то у него есть доступ.
Профессор: да, давайте посмотрим, насколько это плохо? Почему хакеру лучше раскрыть Kc,tgs, чем Kc? Студент: если вы получите Kc,s, то вы сможете просто украсть сессию между этими двумя собеседниками, но если вы украдете Kc, вы сможете выдать себя за клиента.
Профессор: совершенно верно.
Таким образом, единственный способ защитить его состоит в том, что Kc,s на самом деле является новым ключом, который создается каждый раз, когда вы входите в систему.
Это хорошо, потому что у вас есть билет Tc,tgs, который поставляется с ним.
Если вы потеряете этот билет или он станет недействительным, то эти 56 битов в этом ключе Kc,s у вас останутся.
Но никто ими пользоваться не собирается.
Весь смысл этих битов в том, что благодаря им билет Tc,tgs говорит, что этот ключ Kc,s действителен в данный момент, и в нем есть какое-то ограничение.
Студент: следовательно, если кто-то сможет украсть оба этих элемента — Tc,tgs, зашифрованный ключом Kc,tgs, и сам ключ Kc,tgs, зашифрованный Kc, — то он ничем не будет ограничен.
Профессор: да, если кто-то украдет обе эти вещи, он сможет выдать себя за вас или, например, войти на файловый или почтовый сервер в течение срока действия билета, который может составлять пару часов или 10 часов.
Украденным Кс можно пользоваться без ограничений по времени, пока вы не смените пароль.
Итак, похоже, что все эти поля в билете в наши дни очень важны, за исключением представления IP-адреса, который не оказывает большого влияния на безопасность.
В итоге мы получаем этот билет в ответ, что показано внизу диаграммы, и поскольку мы знаем Kc,tgs, мы можем расшифровать ответ от TGS-сервера.
Теперь у нас есть билет на любой сервер — файловый сервер, почтовый сервер, любой сервер, к которому мы хотели подключиться.
Теперь давайте посмотрим, как можно, наконец, использовать все это в протоколе прикладного уровня.
Допустим, я обращаюсь к почтовому серверу, чтобы получить сообщения.
Итак, моя клиентская рабочая станция отправит в TGS запрос на получение билета доступа к почте, скажем, PO12, и TGS вернет ей билет доступа к почте PO12. И внутри этого билета или внутри этого ответа у меня теперь есть открытый ключ Kc,s для связи между мной и почтовым сервером.
Я покажу этот билет почтовому серверу, и он удостоверится, что я тот самый клиент и что все в этом ключе соответствует правильным принципам.
Итак, у нас будет зашифрованный разговор с почтовым сервером, используя этот новый ключ Kc,s. 
Что я мог бы сделать как клиент, так это сначала отправить на почтовый сервер сообщение, которое включает в себя билет на почтовый сервер Tc,mail, зашифрованный ключом почтового сервера Kmail, и вместе с ним отправить сообщение о том, что мне нужно сделать с почтой.
например, удалить сообщение 5 – DELETE 5, зашифрованное ключом Kc,mail. 
Итак, что происходит по этому протоколу на почтовом сервере? Прежде всего, почтовый сервер будет использовать свой закрытый ключ Kmail для расшифровки этого билета, а затем он заглянет внутрь и обнаружит две важные вещи — основное имя говорящего с ним человека и ключ Kc,s, который он должен используйте для расшифровки всего последующего трафика и аутентификации его с помощью Kerberos 5. Затем он сможет расшифровать ваше сообщение и сказать: «Да, пользователь C пытается удалить пятое сообщение, поэтому я запущу эту команду».
Студент: Сервер Kerberos первоначально отправляет билет Tc,tgs и ключ Kc,s. Где здесь содержится аутентификатор? Профессор: Идентификаторы Ac фактически генерируются клиентом.
Обратите внимание, что для создания аутентификатора клиенту нужен только ключ Kc,s, и клиент может делать это столько раз, сколько захочет. Таким образом, общий план использования аутентификаторов или причина их использования заключается в предотвращении атаки повторного воспроизведения.
Итак, в Kerberos 4 каждый раз, когда клиент отправляет новый запрос, будет создан новый аутентификатор, сообщающий, что это новый запрос, клиент создает его только сейчас и он отличается от всех предыдущих запросов, поэтому вам нужно сделать то, что — спрашивает клиент.
Общий план заключался в том, что сервер будет хранить кеш этих аутентификаторов, отправленных, например, в течение последних пяти минут. Поэтому, если он видел дубликат аутентификатора, он воспринимал это как попытку повторной атаки и отклонял ее.
То же самое он делал, если видел аутентификатор, время жизни которого превышало пять минут и которого у него не было в кеше.
Сервер просмотрел временную метку в этом аутентификаторе, увидел, что она устарела, и отклонил запрос, поскольку она была слишком старой.
Поэтому, если клиенту необходимо получить доступ, пусть он отправит новый запрос.
Это общий план использования аутентификаторов.
Как и многие вещи из первой версии Kerberos, они позже были немного изменены, по крайней мере, в Kerberos 4. Поскольку этот аутентификатор на самом деле ничего не говорит о вашем сообщении, он является лишь своего рода дополнением к нему.
Таким образом, способ его использования, например, в этом протоколе почтового сервера, по крайней мере в Kerberos 4, заключается в том, что вы генерируете аутентификатор, берете его и также шифруете с помощью ключа Kc,mail. И почтовый сервер будет отслеживать, отправили ли вы этот аутентификатор заранее или нет. 
Но здесь нет ничего, что связывало бы аутентификатор с сообщением, которое вы отправляете.
Для первого сообщения это было здорово, но когда вы отправляете следующее сообщение секундой позже, вы создаете второй аутентификатор.
В этом случае кто-то в сети может сказать: «ага, у меня есть ваш новый аутентификатор, я могу использовать его вместе с соединением со старым сообщением DELETE и тем самым принудительно удалить сообщение номер 5 дважды, даже если вторая команда будет предназначен для какой-то другой операции».
Таким образом, Kerberos 5 дает вам возможность вставить в аутентификатор что-то, связанное с введенной вами командой.
Разработчики, конечно, изначально могли использовать такой механизм, но им потребовалось время, чтобы понять, как протокол должен работать правильно.
Студент: откуда клиент берет Kс,mail? Профессор: клиент получает это из этого ответа.
Потому что клиент, отправляя запрос билета в TGS, имеет в виду, что это S — имя почтового сервиса, и индекс S в полученном билете Tc,s — тоже почта, и индекс S в ключе Kc,s — тоже почта.
имя почта .
Итак, Kc,s на самом деле является Kc,mail. Таким образом клиент узнает о ключе, который используется им и файлами на почтовом сервере.
Студент: как почтовый сервер получает Kс,mail? Профессор: да, как почтовый сервер получает этот открытый ключ? В конце концов, почтовый сервер, возможно, никогда раньше не слышал о вас или вашем соединении.
Откуда приходит Kс,mail на почтовый сервер? Студент: разве это не часть билета? Профессор: да, это правда, так что это классная вещь! Вы отправляете этот билет на почтовый сервер, и почтовый сервер распознает собственный секретный ключ Kmail, который он использует для расшифровки билета Tс,mail, и этот общий Теги: #информационная безопасность #программирование #ИТ-инфраструктура #Анализ и проектирование систем #Криптография #kerberos #des #KDC #KDC #KDC #KDC #KDC #KDC #Центр выдачи ключей #Центр выдачи ключей #Центр выдачи ключей #TGS #TGS # TGS #Сервис выдачи билетов #Сервис выдачи билетов #Сервис выдачи билетов
-
Гонки На Реактивных Ранцах 2019
19 Oct, 24 -
Linux Ha На Основе Pacemaker
19 Oct, 24 -
Cakephp 1.2 Бета
19 Oct, 24
