Хабрахабр

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 13: «Сетевые протоколы», часть 2

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3

Студент: клиент не может расшифровать этот билет, потому что он зашифрован с помощью ключа сервиса.

У нас есть ключ Kс,s который может получить клиент, но здесь, в билете Tс,s есть еще одна копия этого ключа, зашифрованная с помощью Ks. Профессор: да, это действительно умно, не правда ли?

Поэтому Керберос создает случайный ключ Kс,s и даёт одну копию клиенту, а другую серверу, с которым клиент собирается поговорить. Причина, по которой это сделано, состоит в том, что сервер Kerberos на самом деле пытается обеспечить безопасность общения клиента с другим парнем. Это было бы прискорбно, потому что сервер Kerberos обращался бы к сервису снова и снова при каждом запросе. Представьте, что Kerberos просто бы обратился к сервису со словами: «эй, сервис, этот парень хочет поговорить с тобой, вот ключ для этого»! Так что KDS создаёт 2 копии сессионного ключа: одну для клиента, а другую для TGS.

И если этот сервис имеет правильный ключ Ks, он его расшифрует и скажет: «ага, это тот самый ключ, который я должен использовать, чтобы поговорить с этим клиентом». Поэтому вместо этого разработчики придумали хороший трюк, где они предоставляют клиенту этот билет, и тот не может с ним ничего сделать, кроме как обратиться с ним к правильному сервису. Таким образом, оба участника соединения, клиент и сервис, установят общий ключ для защиты своего соединения.

Студент: так что же такое TGS?

С точки зрения клиента, это просто еще одна услуга, для пользования которой вы можете получить билет. Профессор: существует два взгляда на то, что представляет собой TGS. Фактически это сервис по выдаче билетов. Чем больше функций предоставляет этот сервис, тем больше билетов он предоставляет.

Студент: извините, я имел в виду, что у нас билет называется TGS.

Вы можете представить, что у нас есть сервер Kerberos, есть этот сервис TGS и есть реальный сервис, до которого вы хотите добраться. Профессор: о, да, извините, надпись tgs под стрелкой на этой схеме является всего лишь сокращением для всего блока записи, кроме индекса s в параметре Tс,s, который означает фактическое имя этого сервиса — TGS. Так что сначала вам придётся попросить Kerberos предоставить вам билет для получения доступа к определённому сервису.

Но для этого вам бы понадобился ваш Kс для расшифровки и на всё остальное время пользования сервером. Вы бы могли попросить Kerberos дать вам билет непосредственно на файловый сервер, и это могло бы сработать. Он выглядит так же, как и другие службы, за исключением того, что размещён в отдельном боксе. Вместо этого вы получаете билет для специального сервиса TGS. И он с удовольствием даст вам позже больше билетов без повторного предоставления вашего первоначального ключа клиента Kc.

Студент: то есть его идея в том, что как только вы получите билет TGS, вы можете просто избавиться от своего ключа Kc?

Таким образом, как только вы авторизуетесь в рабочей станции Athena и через пару секунд получите билет Tс,s, ваш пароль удаляется из памяти. Профессор: да, самое классное в этом то, что как только вы получите этот билет Tс,s от сервиса TGS, вы избавляетесь от пароля и ключа Kc. Хорошо, если он сможет получить доступ к вашей информации на 10 часов, или на период действия билета, но не дольше, потому что пароль не сохранился и при следующем входе в «Афину» его потребуется вводить заново. Так что даже если кто-то схватит тебя, отберёт компьютер и убежит с ним, все, что у него будет – это твой билет.

После этого можно забыть про пароль. Единственный момент, когда нужен пароль – это когда вы посылаете запрос серверу Kerberos, вы получаете этот ответ с билетом и расшифровываете его. Но конечно, вы не можете отбросить пароль, прежде чем используете его для расшифровки.
Таким образом, первый, верхний интерфейс C на нашей схеме используется для получения билета с начальным ключом Kc, а второй, нижний интерфейс S – для доступа к сервисам, но уже без необходимости получения начального ключа Kc.

Во-первых, создатели предполагали, что шифрование также обеспечит аутентификацию или целостность сообщений, но этого не произошло. Итак, мы уже поговорили о двух конкретных проблемах протокола Kerberos, которые как бы встроены в него, что причиняло определённые неудобства. Во-вторых, для произвольных клиентов у них существовала возможность угадывать пароли других людей. Этот недостаток исправлен в Kerberos версии 5, где выполняется явная проверка подлинности сообщений.

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

Студент: я не уверен, но можно попробовать «посолить» пароль.

Но это не помешает попробовать его подобрать. Профессор: «соление» просто означает, что клиент, возможно, должен разными способами хешировать пароль. Так что, возможно, дороже будет построить словарь.

Студент: можно попробовать усложнить функцию вычисления пароля.

Возможно, это разумно. Профессор: да, еще одна хорошая идея — сделать процесс хеширования очень дорогим. Так что это кажется разумным планом – использовать комбинацию «соления» и усложнения процесса отгадывания. Поэтому, если эта хэш-функция занимает секунду вычислительного времени, как вы, ребята, делали это во второй лабораторной работе, то в этом случае подбор паролей стал бы очень дорогим занятием.

Вы слышали, что в первых версиях протокола сервер Kerberos не имел ни малейшего представления, правильный клиент к нему обращается или нет. Еще одним способом защиты может стать усложнение ответа. Затем сервер Kerberos мог бы просто проверить, правильность этих вещей, и если они совпадают, предоставить вам билет. Что вы могли бы сделать – это предоставить доказательства, что вы правильный клиент, то есть зашифровать текущую метку времени с хешем пароля, или что-то в этом роде.

Пока что предположим, что можно взять метку времени и выполнить её хеширование вместе с ключом Kc, и кроме того, просто добавить метку времени. Вы, вероятно, не захотите добавлять больше проверочных этапов, но это может сработать.

Если он получает то же значение, то вероятно, запрос сделан правильным пользователем, которому можно отправить билет. В этом случае сервер может увидеть, что у него есть ваш ключ Kc и он также может хешировать текущую метку времени. Если же нет, то это был неправильный пароль.

Студент: можно просто ограничить выдачу билетов, если серверы фиксируют слишком много запросов на их предоставление.

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

Студент: как атакующий может послать запрос серверу Kerberos?

Если хакер просматривает сеть, он может перехватить сообщение во время передачи. Профессор: я думаю, он мог бы воспроизвести сообщение правильного пользователя, то есть увидеть его, скопировать, отправить и так же получить ответ с сервера Kerberos. Но, конечно, если вы просматриваете чужую сеть, то вы увидите, как этот пакет возвращается с сервера независимо от того, что произошло на этапе формирования Tс,s. Так что ограничение количества запросов – временная мера, лишь немного повышающая безопасность. Так что хакер может увидеть ответ сервера клиенту и попытаться напасть на него.

Вероятно, существуют более сложные схемы, которые вы могли бы разработать, но я не думаю, что Kerberos 5 реализует нечто более сложное, чем рассмотренный нами план, который кажется достаточно хорошим, чтобы не позволить случайным людям пытаться сломать что-либо или использовать brute-force для взлома пароля.

И тогда вы сможете зашифровать эту вещь и общий ключ с помощью Kc. Студент: предположим, что можно предусмотреть аутентификацию или ещё что-то, чтобы установить общий ключ.

Если вы действительно делаете это правильно, то для этого существует протокол под названием Password Authenticated Key Exchange, PAKE, который выполняет аутентификацию по паролю. Профессор: да, это так. Именно это и происходит в Kerberos.

Эти протоколы и связанные с ними элементы справляются гораздо лучше с поставленной вами задачей, в которой вы должны доказать обеим сторонам, что вы установили новый ключ. Вы можете посмотреть в Google, для чего предназначены протоколы SRP или PAKE. При этом обе стороны должны быть убеждены в правильности друг друга и в том, и что нет никакого способа, чтобы отгадать этот пароль в режиме оффлайн и совершить атаку на набор сетевых пакетов, которые вы наблюдаете, и так далее.

Это протоколы, которые в значительной мере полагаются на криптографию, поэтому трудно объяснить на доске, почему они работают.

И протоколы как раз позволяют вам отправить в качестве аутентификатора только одну вещь. Студент: одна из причин, по которой разработчики поступили подобным образом, состоит в том, что они хотели поддержать возможность отправки только пароля.

Конечно, на практике, эти серверы могут принимать как соединения Kerberos, так и соединения не-Kerberos. Профессор: да, есть много странных требований, которые учитывали эти ребята. Он просто хочет отправить свой пароль. И для не-Kerberos соединений, вы получаете картину, как будто кто-то подключается к почтовому серверу, но не использует рабочую станцию Athena.

Так что, вероятно, вы всё-таки захотите, чтобы проверку паролей Kerberos осуществлял сам Kerberos. И тогда почтовый клиент здесь, скажем так, собирается взять этот пароль и получить билет от вашего имени только для его проверки, что позволит вам использовать этот почтовый клиент. Я не думаю, что это исключается, потому что, конечно, Kerberos 5 развертывает это хеши меток времени и всё такое.

Это симметричный блочный шифр, довольно быстрый. Я думаю, что еще одна вещь, на которую вы должны обратить внимание в материалах лекции, это то, что разработчики Kerberos 4 выбрали одну схему шифрования — DES, наиболее популярный алгоритм шифрования того времени. В то время он обеспечивал достаточную безопасность, и они просто встроили его в протокол.

Это стало проблематичным, потому что теперь, 25-30 лет спустя, шифрование DES легко поддаётся взлому методом brute-force, так как ключи шифрования имеют очень маленький размер – всего 56 бит. Все в Kerberos должно было использовать только DES, или, по крайней мере, все в Kerberos версии 4.

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

Так что это кажется гораздо лучшим способом обеспечить безопасность. Kerberos версии 5 поддерживает несколько различных схем шифрования, включая AES и другие криптографические алгоритмы. Теперь давайте рассмотрим, что происходит в сервисе TGS, от которого вы получаете билет. С другой стороны, MIT продолжал поддерживать DES ещё 2 года назад, но теперь от этого отказался, так что на сегодня ваш ректор защищен, по крайней мере, от такого типа атак. Взаимодействие с этим сервисом выглядит немного по-другому.

Рассмотрим, как вы выполняете собственную аутентификацию с билетом к какой-то машине. С одной стороны, как клиент, вы собираетесь говорить с ним так, как если бы вы говорили с любым другим сервисом с поддержкой Kerberos. Но ответ, который вы собираетесь вернуть — это просто билет к какому-то другому принципу, на основе которого вы будете общаться, например, с файловым сервером.

У клиента уже есть билет для TGS, полученный с помощью протокола, изображённого вверху. Поэтому сообщения уровня протокола будут выглядеть таким образом – справа я нарисую TGS, а слева — клиента.

Теперь клиент собирается отправить некие комбинации сообщений, которые доказывают, что он правильный клиент, и эти сообщения имеют отношение к выдаче запроса по какому-то конкретному принципу через TGS.

Вот так выглядит сообщение, которое вы собираетесь отправить в TGS – оно говорит: «посмотрите на это сообщение, сделайте с ним что-нибудь и ответьте билетом на этот новый сервис S». Итак, клиент собирается отправить в TGS такое послание: S – это сервис, с которым он собирается общаться дальше, это может быть почтовый или файловый сервер, затем сюда включается билет клиента Tc, который он получил для tgs, зашифрованный с помощью ключа K tgs и аутентификатор, который зашифрован ключом Kc,tgs общим для клиента и сервиса TGS. Но теперь здесь стало немного по-другому. Ответ здесь выглядит почти так же, как на рисунке вверху, и на самом деле это то же самое – это билет между клиентом и этим новым сервисом, зашифрованным с помощью Ks.

Вместо шифрования ключом Kс, который клиент, наверное, забыл с тех пор, теперь шифрование происходит с помощью общего ключа Kc,tgs между клиентом и службой TGS.

Сервер TGS знает свой собственный ключ Ktgs, поэтому сначала он собирается расшифровать это послание Tc,tgs, заглянуть внутрь билета и выяснить, что происходит. Как же сервер выясняет, чего хочет клиент и как сервер выполняет проверку подлинности клиента? Почему так важно иметь в билете имя сервера S? Зачем же нам нужны все эти поля в билете? Что бы пошло не так, если бы у нас не было S?

Студент: если бы его не было, тогда можно было бы потенциально получить разрешение на использование любого сервера.

Вообще это хорошая идея — сделать в сетевых протоколах так, чтобы можно было точно сказать, что означает это сообщение. Профессор: да, это так. Так что кажется, что это хорошая идея – включить название сервиса для того, чтобы убедиться, что сервер, который получает эти билеты, расшифровывает их и проверяет — это билет для меня или для кто-то еще? В случае, если вы опустите S, вы можете опираться на то, что если вы используете билет для неправильного S, тогда, возможно, у вас будет другой ключ Ks, и он не сможет выполнить расшифровку или что-то вроде этого.

Студент: что делает клиент с полученным ключом Ktgs?

Клиент понятия не имеет, что это. Профессор: хороший вопрос! Если бы вы знали его, то были бы в состоянии взломать весь Kerberos. Потому что это сверхсекретный ключ. Так что клиент понятия не имеет, что такое Ktgs.

Студент: откуда же берётся этот Ktgs?

Профессор: сам сервер Kerberos генерирует для вас всё это послание, в котором уже есть Tc,tgs и Ktgs, вы не создаёте его сами, а просто копируете отсюда.

Это легко сообразить. Так для чего же так важно имя клиента? Он не знает, для кого должен выдать билет – для вас или для кого-то ещё. Если вы не помещаете имя клиента в билет, тогда сервер получает это послание, но понятия не имеет, с кем он пытается поговорить.

Почему разработчики вставляют в билет Tc,s адрес addr? А как обстоят дела с другими полями? Это ведь просто IP-адрес клиента, так почему бы его не использовать напрямую?

Они хотели убедиться, что если клиент вошел в систему с какого-то IP адреса, то все остальное по тому же билету происходит с того же IP-адреса. Я думаю, что смысл такого решения состоит в желании разработчиков повысить безопасность. 26. Например, если вы вошли с какого-то IP-адреса, например 18. 9, то каждое соединение с файловым или почтовым сервером должно быть с того же IP-адреса. 4. Таким образом мы защищаемся здесь от использования украденных билетов. В противном случае сервер должен отклонить ваше соединение, так как может предположить, что кто-то украл ваш билет. Если у вас ещё есть тот же билет — хорошо, но если вы не используете тот же IP-адрес, у вас ничего не получится.

Действительно, вы должны просто полагаться на криптографию вместо обеспечения безопасности IP-адреса. На данный момент это выглядит заблуждением, и Kerberos 5 все ещё использует подобный подход, хотя это необязательно.

Для чего они нужны и чем полезны? А в чём смысл временной метки timestamp и времени жизни life в билете?

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

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

Студент: ранее вы говорили, что клиент может выбросить свой начальный ключ отбрасывает Kс, но должен хранить Kс,s, полученный от TGS.

Профессор: да, это так, клиент отбрасывает Kс после входа в систему, но должен хранить Kс,s.

Студент: итак, если кто-то крадет Kс,s, то у него появляется доступ…

Почему лучше, чтобы хакер раскрыл этот Kc,tgs, чем Kс? Профессор: да, давайте рассмотрим, насколько это плохо?

Студент: если вы получите возьмете Kс,s, то вы сможете просто украсть сеанс между этими двумя собеседниками, но если вы украдёте Kс, то сможете выдать себя за клиента.

Поэтому единственный способ защиты это то, что Kc,s — это на самом деле новый ключ, который создается каждый раз, когда вы входите в систему. Профессор: совершенно верно. Если вы потеряете этот билет или он станет не действителен, то у вас есть ещё эти 56 бит в этом ключе Kc,s. Это хорошо, потому что у вас есть билет Tc,tgs, который к нему прилагается. Весь смысл этих битов в том, что благодаря им билет Tc,tgs говорит, что этот ключ Kc,s действителен в данный момент, и в нём есть какое-то ограничение. Но никто не собирается их использовать.

Студент: поэтому, если кто-то сможет украсть оба эти элемента — Tc,tgs, зашифрованный ключом Kc,tgs, и сам ключ Kc,tgs, зашифрованный Kc — то он не будет ничем ограничен.

Украденным Kc можно будет пользоваться без временных ограничений, пока вы не измените свой пароль. Профессор: да, если кто-то украдет обе эти вещи, то сможет выдать себя за вас или, например, войти в файловый или почтовый сервер в течение времени жизни билета, которая может составлять пару часов или 10 часов.

Мы наконец-то получаем в ответ этот билет, который изображён внизу схемы, и поскольку мы знаем Kc,tgs, то можем расшифровать ответ от сервера TGS. Итак, похоже, что на сегодня все эти поля в билете вроде как важны, кроме представления IP-адреса, который не особо влияет на безопасность. Теперь у нас есть билет на любой сервер — файловый сервер, почтовый сервер, какой угодно сервер, к которому мы хотели подключиться.

Предположим, что я говорю с почтовым сервером, чтобы получить свои сообщения. Теперь давайте рассмотрим, как вы можете, наконец, использовать всё это в протоколе уровня приложений. И внутри этого билета, или внутри этого ответа, у меня теперь есть общий ключ Kc,s для связи между мной и почтовым сервером. Поэтому моя клиентская рабочая станция собирается отправить TGS запрос на получения билета для доступа к почте, например, PO12, и TGS вернет ей билет с доступом к почте PO12. Так что у нас с почтовым сервером состоится зашифрованный разговор с использованием этого нового ключа Kc,s. Я покажу этот билет почтовому серверу, и он убедится в том, что я правильный клиент и всё в этом ключе соответствует правильным принципам.

Что я мог бы сделать как клиент, это сначала отправить сообщение на почтовый сервер, которое включает в себя билет на почтовый сервер Tc,mail, зашифрованный ключом почтового сервера Kmail, и вместе с ним отправить сообщение о том, что мне нужно сделать с почтой, например, удалить сообщение 5 – DELETE 5, зашифрованное ключом Kc,mail.

В первую очередь почтовый сервер использует для расшифровки этого билета свой секретный ключ Kmail, а потом заглянет внутрь и найдёт две важные вещи -основное имя того, кто с ним говорит, и ключ Kc,s, который он должен использовать для расшифровки всего последующего трафика и аутентификации его в Kerberos 5. Итак, что же происходит в этом протоколе на почтовом сервере mail? После этого он сможет расшифровать ваше сообщение и сказать: «ага, пользователь C пытается удалить пятое сообщение, поэтому я выполню эту команду».

Где здесь содержится аутентификатор? Студент: сервер Kerberos изначально отправляет билет Tc,tgs и ключ Kc,s.

Обратите внимание, что клиенту для генерации аутентификатора нужен только ключ Kc,s, и клиент может делать это столько раз, сколько захочет. Профессор: Идентификаторы Ac фактически генерируются клиентом. Таким образом, общий план для аутентификаторов или причина использования аутентификаторов состоит в предотвращении атаки повторного воспроизведения.

Таким образом, в Kerberos 4 каждый раз, когда клиент посылает новый запрос, будет создаваться новый аутентификатор, говорящий, что это новый запрос, клиент создаёт его только теперь и он отличается от всех предыдущих запросов, поэтому нужно сделать то, что просит клиент.

Поэтому если он видел дубликат аутентификатора, то воспринимал его как попытку атаки повторного воспроизведения и отвергал его. Общий план состоял в том, что сервер должен был хранить кэш этих аутентификаторов, которые были отправлены, например, в течение последних пяти минут. Сервер смотрел на метку времени в этом аутентификаторе, видел, что он устарел, и отклонял просьбу, потому что она была слишком старая. Так же он поступал, если видел аутентификатор, который находится за пределами пятиминутного времени жизни и которого у него не было в кэше. Как и многие вещи из первой версии Kerberos, в последствии они были немного изменены, по крайней мере, в Kerberos 4. Так что если клиенту нужно получить доступ, пусть отправит новый запрос.
Таков общий план использования аутентификаторов. Потому что этот аутентификатор на самом деле ничего не говорит о вашем послании, это просто какое-то дополнение к нему.

И почтовый сервер будет отслеживать, отправили ли вы этот аутентификатор заранее или нет. Таким образом, способ его использования, например, в этом протоколе почтового сервера, по крайней мере, в Kerberos 4, состоит в том, что вы генерируете аутентификатор, берёте его и так же зашифровываете ключом Kс,mail.

Для первого сообщения это было здорово, но когда через секунду вы посылаете следующее сообщение, вы создаёте второй аутентификатор. Но здесь нет ничего, что соединяет аутентификатор с сообщением, которое вы посылаете. При этом кто-то в сети может сказать: «ага, у меня есть ваш новый аутентификатор, я могу использовать его вместе с соединением со старым сообщением DELETE и тем самым заставить дважды удалить сообщение номер 5, даже если вторая команда предназначена для какой-то другой операции».

Разработчики, конечно, могли бы изначально использовать такой механизм, но понадобилось время, чтобы они поняли, как правильно должен работать протокол. Таким образом, Kerberos 5 предоставляет вам право вставить в аутентификатор что-то, что касается отдаваемой вами команды.

Студент: откуда клиент берёт Kс,mail?

Профессор: клиент получает его из этого ответа.

Так что этот Kc,s на самом деле Kс,mail. Потому что клиент, посылая TGS запрос на билет, имеет в виду, что это S – имя сервиса mail, и подстрочный индекс S в полученном билете Tc,s – это тоже mail, и индекс S в ключе Kc,s — это тоже имя mail. Вот так клиент узнает о ключе, который является общим для него и файлов на почтовом сервере.

Студент: а как почтовый сервер получает Kс,mail?

Ведь почтовый сервер, возможно, никогда раньше не слышал о вас и о вашем соединении. Профессор: да, как же почтовый сервер получает этот общий ключ? Откуда же Kс,mail приходит на почтовый сервер?

Студент: разве это не часть билета?

Вы отправляете этот билет на почтовый сервер и почтовый сервер узнаёт собственный секретный ключ Kmail, который он использует для расшифровки билета Tс,mail, и этот общий ключ находится там вместе с именем того, с кем он делится данным ключом. Профессор: да, правильно, так что это классная вещь! Вот так сервер узнает, что разговаривает с тем парнем, с которым должен использовать общий ключ.

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

54:00 мин

Лекция 13: «Сетевые протоколы», часть 3 Курс MIT «Безопасность компьютерных систем».

Полная версия курса доступна здесь.

Вам нравятся наши статьи? Спасибо, что остаётесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть