id: Гость   вход   регистрация
текущее время 12:13 18/11/2019
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 15/05/2007 21:26 (автор: SATtva) Печать
Категории: криптография, инфобезопасность, протоколы, сайт проекта, статьи, стандарты, атаки, ssl, человек посередине
https://www.pgpru.com/Библиотека/Статьи/КтоБоитсяМэллориВульфа
создать
просмотр
редакции
ссылки

Кто боится Мэллори Вульфа?


В общепринятом представлении, протокол SSL служит для защиты от так называемой атаки "человек посередине" (man-in-the-middle, сокращённо MITM), или от Мэллори, как этого "человека" обозначают в криптологических кругах. Возникает вопрос, почему? По какой причине MITM стал главным компонентом модели угрозы в SSL? И почему все реализации протокола соглашаются с этим? (На самом деле, можно использовать SSL, или TLS, как он ныне известен, и без механизма защиты от MITM как части модели угрозы – то есть без сертификатов X.509, – но я опущу этот момент, как, впрочем, это делают и реализации.)


Стоит вспомнить времена создания SSL, период 1994 года: веб – второе величайшее приложение Всемирной сети (первым был email) – берёт баррикады; бизнесы начинают погружаться в бескрайние возможности электронной коммерции. Netscape превращался во властителя Новой Сети, в соперника Microsoft. И, как и у всего последующего сумесшествия дот-комов, бизнес-модель Netscape не представляла ничего выдающегося: продажа нескольких защищённых серверов – и все дела. Вся штука коммерции тех дней была великим чудом, ибо предусматривала зарабатывание денег, а деньги, заработанные честно, были тогда в Netscape ценным дефицитным товаром.


Чтобы не затягивать историю, перейдём к сути. Netscape создал вариант протокола HTTP, объединённого со слоем шифрования, – SSL. Он продавался в дополнение к его серверам как средство защиты платежей по кредитным картам, совершаемым через интернет.


Анализ разработчиков SSL показал, что его модель угрозы должна включать MITM. На чём было основано такое предположение? Трудно рассматривать это иначе, и стоит рассматривать именно так, учитывая опыт последних десяти лет, что включение MITM в модель угрозы было банальной ошибкой. Взгляните на простой факт: за всю историю интернета не состоялось ни единой атаки MITM, независимо от среды передачи, когда был бы зафиксирован и задокументирован перехват и незаконное использование кредитной карточки. Более того, не было проведено ни одной атаки MITM в любой агрессивной форме. Единственное, что известно, – это несколько демонстраций, выполненных в лабораторных условиях. Они не в счёт, и MITM по-прежнему остаётся более теоретической атакой, предметом исследований и дизайнерских концепций, нежели областью бизнеса и крипто-инженеринга.


Насколько серьёзен этот факт? В действительности, довольно прост, но учитывая объёмы трафика, виденного нами в последнее десятилетие, можно было бы допустить, что к сегодняшнему дню должны были появиться MITM и более агрессивных видов: сканирование емэйла или, вероятно, прослушивание незащищённого HTTP. (Впрочем, пришествие беспроводных сетей в виде 802.11b – Wi-Fi – стало плодородной почвой для подобных атак. Существуют даже аппаратно-программные комплексы для их проведения.) Однако до сего дня ни одного случая не зафиксировано. На самом деле, нет никаких свидетельств, помимо обстоятельного нытья некоторых параноиков, что потенциальные взломщики даже пассивно слушивают трафик, не говоря уже о проведении более изощрённых MITM-атак.


В мире кредитных карт, люди, непосредственно занятые в индустрии электронной коммерции, подтверждают в частных беседах справедливость таких аргументов. 1 Все случаи утери кредитных карт основаны на иных атаках. Что приводит нас к вопросу, а что есть угроза? И есть ли эта угроза в действительности? Другими словами, должен MITM входить в модель угрозы SSL или должен быть исключён?


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


Экономика даёт нам другой ответ: стандартный анализ расходования средств.


  1. Оцените средний ущерб от каждой атаки;
  2. оцените количество атак;
  3. перемножьте предыдущие результаты, чтобы получить общую оценку угрозы;
  4. аналогично, оцените общую стоимость контрмер для защиты от этой угрозы;
  5. сравните:
    • если контрмеры обошлись дешевле стоимости этих атак, вы в выигрыше;
    • если вы потеряли больше, чем защитили, вы в убытке.

Это лишь экономика и статистика, и обоснование здесь в том, что кредитные карточки – ничто, если они не вписаны в основанную на экономике и статистике модель коммерции и воровства.


Итак, давайте примем ущерб от перехвата каждой кредитки от нашей MITM-атаки в $1000 (можете придумать собственную сумму, если вам не нравится эта). Далее, сколько всего атак? Ни одной, как было сказано выше. Перемножаем наши цифры и получаем... правильно, ноль.


Что это означает? Это означает, что если вы потратите даже цент на защиту от атак "человек посередине", вы окажетесь в проигрыше, поскольку, исходя из экономического и статистического анализа, основанного на отсутствии какого-либо ощутимого риска от MITM-атак, нет ни малейшей нужды в расходовании денег на защиту от них. Если мы верим в экономику, или, хотя бы, в приведённую модель ущерба и рисков, становится совершенно понятно, почему так важно измерять угрозы. Если не существует опыта атак MITM и какого-либо последующего ущерба, то модель определяет отсутствие угрозы.


Каков компромисс? Давайте прежде взглянем на другую часть уравнения. Создание защиты от MITM стоит денег. Эти расходы следует оценить и сравнить с потерями от MITM. (Если таковые были. Тем не менее, их можно ожидать. Чувствую нутром, что однажды атака произойдёт. Представьте, 10 млн. незащищённых сайтов – рано или поздно, это должно случиться.)


"Хороший" серверный сертификат Х.509 стоит около $700. Средняя цена его установки – от начала и до конца – в средней организации, похоже, затянется на несколько дней, но давайте оценим её в 6 часов времени. Почему так много? Потому что этот процесс редок и неавтоматизирован. Десятки одиночных этапов; подробный аудит, документация и т.п., от которых идёт кругом голова у технарей и скрипят зубы у менеджеров. Примем сумму в нашей средней западной компании за $50/час, и мы имеем расходы на установку приблизительно в $300. Забудьте об остальных расходах; оценим полную стоимость каждого сертификата примерно в $1000. Я думаю, она больше, но давайте округлим до $1000. Умножим на общее количество действующих сертификатов, порядка 100 тыс., и получим размер понесённых расходов в $100 млн. на защиту от атак "человек посередине". Каждый год, а иногда чаще, действие сертификатов истекает, так что мы как сетевое сообщество ежегодно тратим $100 млн. для предотвращения того, чего нет.


Вернёмся к копромиссу. Представим, что 10 MITM перехватили номера кредитных карт и успешно похитили по $1000 с каждой. Таким образом, мы защитили $10 тыс. Сообщество – то есть мы, мы все – попусту тратим время. Нужно 100 тыс. атак подобных масштабов, чтобы хоть как-то оправдать существующую инфраструктуру. Или 100 атак на шейхов с миллионными карточками. И это только для безубыточности системы! Нужно ещё больше, чтобы она приносила доход.


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


Для определённого сервера, любого конкретного сервера, защита от MITM может быть оправданной. Возможно, у владельца сервера более высокая модель угрозы, чем у обычного продавца товаров. Возможно, такую защиту требуют пользователи. А возможно, у владельца просто больше денег, и его не волнует экономия средств. Каждое из этих "возможно" было бы полезно и хорошо, если бы владелец имел единоличное право решения — решения о распоряжении своими деньгами. Однако в сегодняшнем вебе у владельца нет выбора. Если шифрование связи необходимо – например, для защиты от простого прослушивания – тогда требуется и сертификат! Этого требует софт: прежде всего браузеры, но также и серверы, сконфигурированные так, чтобы поднимать вонь от одной лишь мысли связаться с сайтом, у которого нет сертификата.


Таким образом, SSL, как он сегодня реализован, представляет собой грубейшую ошибку разработки. Угроза иллюзорна, но браузеры настаивают на защите. При переходе от незащищённых сайтов к защищённым пользователи начинают волноваться об отсутствии сертификатов, как будто бы от этого была какая-то разница. Несомненно, браузеры не должны дискриминировать сайты без сертификатов. Скажу даже больше: если пользователь заходит на сайт с автоподписанным (self-signed) сертификатом, браузер должен воздавать хвалу такому варианту: "Поздравляем! Вы выбрали сайт, который разумно защищает наше соединение с помощью Сертификата Свободы, созданного для защиты от мерзких нежелательных шпионов и для победы в войне над Осью Зла прослушивателей!".


Поскольку серверы не могут общаться с пользователем столь легко, им придётся ограничиться в борьбе с растратами и неверным распределением ресурсов путём исходной и изначальной настройки на лучшую возможную защиту. Автоматически генерируемые автоподписанные Сертификаты Свободы станут хорошей временной мерой до повсеместного распространения Anonymous-Diffie-Hellman, 2 и помогут нанести стремительный и сильнейший удар по противникам Свободного Серфинга.


© 2003 Иан Григг
Перевод © 2005 SATtva


1 Например, Лин Уиллер, 17 марта 2003 г.:

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

2 В действительности, изначально включённый в протокол SSL/TLS алгоритм анонимного согласования ключа по Диффи-Хеллману (Anonymous-Diffie-Hellman, или ADH), уже представляет замечательную возможность шифрованного серфинга. Напишите своему браузерному программисту сегодня и потребуйте немедленной реализации алгоритма в борьбе против террористов с большими ушами.


 
— Нубик (13/05/2007 03:12)   <#>
Смело. Даже очень. Я бы не кидался такими фразами, Но в них кроется доля истины. То что не стоит боятся MITM атак, то позволю с этим не согласится. Было время когда вирусы воспринимались за чтото далекое и нереальное... Они будут. И это факт. Тут в принципе это и сказано. Мы же сами и научили людей MITM атакам, придавая их такой огласке... У любого взломщика руки будут чесаться использовать этот способ. Дело реализации это конечно другой вопрос. Но элемент психологии имеет все таки тут свой фактор. Чем больше мы будем их боятся, тем больше их будет. Получается: если мы этого боимся, значит мы тут уязвимы... Но от этого уже никуда не дется. Просто сложить руки и посмотреть окупится они или нет? То есть получается мы говорим идите и атакуйте! Нам все равно не будем защищаться от этих атак. Нам просто это не выгодно. Мы сами провоцируем взломщиков на эти атаки.
Помоему из ситуации есть все таки выход. Не знаю на сколько он реален (и экономичен, что я так понимаю имеет большое значение). Но... (дальше чисто мои субъективные мысли) План такой:
-расчитать стоимость и выгодность проекта;
-придумать систему привлечения финансов для проекта, если он выгоден;
-разработать сам проект;
-и осуществить.
Суть проекта заключается в пресечениях таких атак путем создания определенных ресурсов. Эти ресурсы должны детектить атаки и принимать меры для поимки этих взломщиков. Конечно количество пойманных мошенников не окупит затраты на осуществление проекта. Но если учесть потери от атак которые не осуществились из-за психологического фактора (страх быть пойманным) и потерь повязанных недоверием потребителей самому протоколу SSL, то думаю оно окупится. Меры пресечения всегда дешевле мер лечения. Ну не буду больше с себя строить умника. Все выложенное выше сугубо мое личное мнение. Может я в чом то не прав... принимаю любую критику в свой адрес.
— fsdfs (13/05/2007 04:15)   <#>
Статья полный бред.

1 – почему автор бросается такими смелыми и неподкреплеными ничем удтверждениями?
2 – может быть такие атаки не стостоялись потому, что зазищенные протоколы разрабатываются с учетом их возможности?

Автор говорит, что mitm атаки никем не используются независимо от среды передачи данных. К примеру меня поражает глубина невежества в фразе
действительности, довольно прост, но учитывая объёмы трафика, виденного нами в последнее десятилетие, можно было бы допустить, что к сегодняшнему дню должны были появиться MITM и более агрессивных видов: сканирование емэйла или, вероятно, прослушивание незащищённого HTTP

При прослушивании незащищенного HTTP и перехвате мыла никакой mitm не используется просто потому, что он тут не нужен! Незазщищеный трафик прекрасно читается и так. Вклинивание в процесс передачи трафика по http протоколу производиться только в случае необходимости его модификации. Таким способом к примеру осуществляются продвинутые методы фишинга. Только фишеров сейчас сдает то, что они не могут подделать ssl :)

Применительно к защищеным протоколам не использующим модели mitm, могу привести пример RDP. RDP протокол прекрасно ловиться программой cain & abel, которая делает mitm используя arp спуфинг в локальной сети. Я сам парочку серваков таким макаром ломал. Но слава богу, в последних версиях m$ реализовали rdp over ssl, и для грамотного админа эта атака больше не страшна.

Далее, возьмем в пример OpenVPN, который кстати тоже на ssl работает (правда тут используется свой CA). Впн как известно предназначен для защиты трафика от провайдера и ментов с широкими ушами. Если бы ssl протокол не предусматривал защиту от mitm, то грош цена была бы такому vpn. (кстати, mitm атаки были бы просто кормушкой для админов провайдеров, ведь можно было бы столько интересного узнать о своих клиентах).
— Гость (13/05/2007 13:43)   <#>
Я тоже не согласен со статьей, там очень примитивно представлена и заужена модель угрозы, но если воспринимать чисто с экономической точки зрения, то в принципе есть большая доля правды, хотя цифры и не особо правильные приведены.
— SATtva (13/05/2007 16:11)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Григг — финансовый криптограф, его компетентность в умении исчислять и оценивать риски я бы под сомнение не ставил. Да, статья представлена в несколько провокационном духе, но это лишь манера его письма.
— spinore (14/05/2007 00:30, исправлен 14/05/2007 00:31)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786

сомнение не ставил.

Это "идол рода" Фрэнсиса Бэкона.
Мнение великих может быть только одним из аргументов, что, соответственно, не
отменяет собственные мозги. Даже если предположить что посылки статьи (факты)
были верные (что не так, так как пример "мэллори"-атак уже привели прокомментировавшие),
сходу видно ошибку:
Из того, что атак не было не следует что они не последуют когда защита ослабнет.

Несмотря на это посыл частично верный касаемо центральноподписных сертификатов.
Может быть, существуют схемы получше, а сходу могу придумать такую: в связит с тем
что SSL используется зачастую вместе с аутентификационными данными (логин и пароль),
выдавать последние напару с фингерпринтом сертификата сайта.
— SATtva (24/05/2007 21:42)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
в связит с тем что SSL используется зачастую вместе с аутентификационными данными (логин и пароль), выдавать последние напару с фингерпринтом сертификата сайта.

Соберите 100 произвольных интернет-пользователей (не из контингента, посещающего этот сайт) и спросите их, что они знают об SSL, PKI, цифровых сертификатах, криптографическом доверии, удостоверяющих центрах и длинах ключей. Уверяю, 98 не скажут ничего, а двое только сравнят длину ключей от своего авто и от квартиры.

Проблема SSL в том, что он не решает поставленную задачу. Какая ставилась задача? Защитить передаваемые по общественным сетям финансовые реквизиты (номера кредитных карт и пр.). А как поступает фишер? Сооружает на левом домене копию банковского сайта и покупает у любого удостоверяющего центра SSL-сертификат для этого домена. И 98 из 100 пользователей, пришедших на этот левый сайт по ссылке из спамовых писем, как миленькие введут свои банковские реквизиты: в браузере ведь красуется иконка закрытого замочка, значит всё путём, нечего бояться! И MITM тут не при чём...
— spinore (01/06/2007 03:36)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
ну, SATtva, если быть совсем неграмотным то можно и ручкой себе глаз проколоть вместо того чтобы письмо написать... Это уж никак не решается.
— sentaus (01/06/2007 14:35, исправлен 01/06/2007 14:36)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Я помню, не знал, смеяться или плакать, когда прочитал в предупреждениях о безопасности одного крупного западного банка (точнее, его представительства в РФ): "убедитесь, что соединение осуществляется с использованием SSL и сертификат выдан (название УЦ)".
— SATtva (01/06/2007 15:57)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
А как в этом убедиться, они написать конечно забыли. Кстати, а это предупреждение было указано на их сайте или (надеюсь на здравый смысл) всё-таки в буклете с инструкциями, выдаваемом в самом отделении банка?
— sentaus (01/06/2007 17:04)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Нет, к сожалению, на сайте.
Правда, сейчас всё немного изменилось :)
Написано, что подлинность сертификата можно проверить, основываясь на следующих данных:
1) Кому выдан
2) Кем выдан
3) Срок действия

Об отпечатке никакой информации нет – наверно это слишком сложно для пользователя. :)

Меня всё это очень удивляет, неужели банки не в состоянии обеспечить вменяемую безопасность? Напимер, почему бы не выдавать клиентам сертификаты банка на твёрдых носителях при заключении договора? В этом случае даже не нужны никакие УЦ-посредники...
— SATtva (01/06/2007 17:13)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Меня всё это очень удивляет, неужели банки не в состоянии обеспечить вменяемую безопасность?

А зачем им это? SSL прикрутили, остальное — проблемы пользователя. Экстерналии... У банка нет стимула, чтобы заниматься просвещением пользователей или модернизировать схему. А если чем-то таким и занимается, то по своей доброй воле.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3