Достоинство этого протокола в том, что теперь Алиса может получать защищенный доступ к любому серверу сети, и в то же время ее пароль никогда не передается. В действительности он лишь на несколько миллисекунд появляется на ее рабочей станции. Однако обратите внимание, что каждый сервер выполняет свою собственную процедуру авторизации. Когда Алиса предъявляет свое удостоверение Бобу, это всего лишь подтверждает, что она та, за кого себя выдает. При этом действия, которые Алиса может выполнять, определяет Боб.

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

8.9.5. Аутентификация путем шифрования с открытым ключом

Взаимная аутентификация также может выполняться с помощью шифрования с открытым ключом. Сначала Алиса должна получить открытый ключ Боба. Если PKI реализована на основе сервера каталогов, выдающего сертификаты на открытые ключи, Алиса может запросить сертификат Боба (сообщение 1 на илл. 8.40). В ответе (сообщение 2) содержится сертификат X.509 с открытым ключом Боба. Проверив корректность подписи, Алиса может отправить Бобу сообщение со своим идентификатором и нонсом.

Илл. 8.40. Взаимная аутентификация с помощью открытого ключа

Когда Боб получает это сообщение, он не знает, от кого оно пришло — от Алисы или от Труди, — но делает вид, что все в порядке, и просит сервер каталогов выдать ему открытый ключ Алисы (сообщение 4). Вскоре он его получает (сообщение 5). Затем он отсылает Алисе сообщение 6, содержащее случайное число Алисы RA, свой собственный нонс RB и предлагаемый ключ сеанса KS.

Алиса расшифровывает полученное сообщение 6 своим закрытым ключом. Она видит в нем свое случайное число RA и очень этому рада: это подтверждает, что сообщение пришло от Боба, так как Труди не способна определить значение RA. Кроме того, RA свидетельствует о свежести этого сообщения. Алиса соглашается на установление сеанса (сообщение 7). Когда Боб видит свое случайное число RB, зашифрованное ключом сеанса (который он сформировал сам), он понимает, что Алиса получила сообщение 6 и проверила значение RA. Боб счастлив.

Может ли Труди обойти этот протокол? Она может сфабриковать сообщение 3 и спровоцировать Боба на проверку Алисы, но Алиса увидит число RA, которое она не отсылала, и не ответит. Труди не удастся убедительно подделать сообщение 7, так как она не знает содержимого запроса RB или ключа KS, и не может определить их, поскольку не располагает закрытым ключом Алисы. Удача не на ее стороне.

43 Также ее называют атакой по принципу пожарной цепочки (bucket brigade attack), поскольку она напоминает действия пожарной бригады прежних времен — передачу ведер с водой от пожарной машины к месту возгорания.

44 В литературе их также называют билетами. — Примеч. ред.

8.10. Защита соединений

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

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

8.10.1. IPsec

IETF в течение многих лет мирился с отсутствием безопасности в интернете. Обеспечить ее было непросто из-за жарких споров о том, в какой части системы располагать средства защиты. Большинство экспертов по вопросам безопасности уверены в том, что по-настоящему надежная система должна выполнять сквозное шифрование и сквозное обеспечение целостности данных (то есть все это должно быть сделано на прикладном уровне). Другими словами, процесс-источник шифрует и/или ставит защиту целостности данных и отправляет их процессу-получателю, который, в свою очередь, дешифрует данные и/или проверяет их целостность. Это позволит заметить любые попытки взлома (даже на уровне операционной системы на любой из сторон). Проблема в том, что для обеспечения безопасности требуется вносить изменения во все приложения. Из этого следует, что лучше перенести шифрование на транспортный уровень или организовать новый специализированный подуровень между прикладным и транспортным. Он должен быть сквозным, но в то же время не требующим внесения изменений в приложения.

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

Результатом всех этих споров было создание стандарта IPsec (IP security — IP-безопасность), описанного в ряде спецификаций RFC. Не всем пользователям требуется шифрование соединений (соответствующие процедуры могут занимать существенную долю вычислительных ресурсов). Однако вместо того чтобы делать шифрование необязательным, пользователю предлагается в случае необходимости выбирать нулевое шифрование. В RFC 2410 описаны такие достоинства нулевого шифрования, как простота, легкость реализации и высокая скорость.

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

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