Тай Данг (Thai Duong) и Джулиано Риццо (Juliano Rizzo), известные исследователи компьютерной безопасности, обладатели премии Pwnie Awards 2011 (http://www.opennet.me/opennews/art.shtml?num=31407) за разработку метода компрометации приложений ASP.NET, намерены (http://threatpost.com/en_us/blogs/new-attack-breaks-confiden...) на конференции Ekoparty 7 (http://www.ekoparty.org/2011/juliano-rizzo.php) раскрыть завесу над новым способом атаки на SSL/TLS. Для осуществления атаки подготовлен инструментарий, развиваемый под именем BEAST (Browser Exploit Against SSL/TLS) и позволяющий организовать перехват информации, передаваемой в рамках зашифрованного соединения. В частности, исследователи продемонстрировали успешный перехват защищенной сессии для сервиса PayPal и утверждают, что метод применим и для любых других сайтов.Судя по всему представленная работа является первый удачным методом атаки против TLS 1.0 и SSL 3.0, позволяющим ра...
URL: http://threatpost.com/en_us/blogs/new-attack-breaks-confiden...
Новость: http://www.opennet.me/opennews/art.shtml?num=31797
Это серьезно.
При таком количестве условий, при которых возможна атака, она становится *очень* трудно осуществимой.
Т.е. при тщательной подготовке все-таки возможна.
А до выхода нового протокола NoScript лишний раз нам друг и товарищ, так что посторонние iframe'ы - пролетают.
Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом сайте. И все другие SSL можно читать?
> Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом
> сайте. И все другие SSL можно читать?нет
>> Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом
>> сайте. И все другие SSL можно читать?
> нетА почему это нет???
Потому что должен быть подконтрольный шлюз через который ходит жертва в интернет через который можно снифать трафикто есть одно из минимальных условий то, что злоумышленник должен контролировать шлюз вашего провайдера или WiFi через который выходит человек
это более серьезное условие чем просто IFRAME
хотя самое страшное то что позволит к примеру самим операторам снифать защищенный трафик и дешифровать его. И инъекция постороннего кода для них не составит проблем
> Потому что должен быть подконтрольный шлюз через который ходит жертва в интернет
> через который можно снифать трафик
> то есть одно из минимальных условий то, что злоумышленник должен контролировать шлюз
> вашего провайдера или WiFi через который выходит человек
> это более серьезное условие чем просто IFRAME
> хотя самое страшное то что позволит к примеру самим операторам снифать защищенный
> трафик и дешифровать его. И инъекция постороннего кода для них не
> составит проблемЦена вопроса - пятсот баксов сисадмину провайдера. И все. Продаются все. Вопрос лишь в цене.
> Продаются все. Вопрос лишь в цене.Нет.
Твои хотелки, Майк, не есть реальность. К сожалению. Я бы тоже хотел, чтобы был мир во всем мире и у баб было в груди сердце, а не контрольно-кассовая машина. Но увы.Не за пятьсот - так за пять штук любой админ продастся. За пятьдесят. "Кто вы такая, мадам, мы уже выяснили. Осталось договориться о цене".
> Твои хотелки, Майк, не есть реальность.Хотелки хотелками, а ответ на утверждение остаётся в силе.
> Не за пятьсот - так за пять штук любой админ продастся. За пятьдесят.
Мне известны не продавшиеся за миллионы, чего достаточно для признания и этого утверждения ложным. Из чего притом не следует, что продающихся за поржать не существует...
>продающихся за поржатьВ фортунки!!!!!!! :)
Я являюсь начальником IT отдела у ISP. Провернуть подобное, в масштабах всей сети, могут 3 человека. Провернуть подобное, в масштабах одного/нескольких домов, могут около 30 человек подрядчика, занимающиеся монтажом оптики и свичей в домах. Огромное количество народа может зайти на чердак, врезать в витую пару точку доступа wi-fi и получать информацию из интересующей квартиры.
> Цена вопроса - пятсот баксов сисадмину провайдера. И все. Продаются все. Вопрос лишь в цене.А также:
1) Фиктивная точка доступа.
2) Флуд свичей и спуфинг
3) Просто наглейший MITM.Даже нахаляву можно проскочить.
> пятсот баксов сисадмину провайдераЗа недельную зарплату получить вполне реальный шанс оказаться на нарах с переломанными ногами мечтает каждый сисадмин.
Вы путаете мелкую пакость надоевшему работодателю и конкретный криминал. Среди сисадминов (точнее сетевых админов) потенциальных уголовников я не видел.
>> пятсот баксов сисадмину провайдера
> За недельную зарплату получить вполне реальный шанс оказаться на нарах с переломанными
> ногами мечтает каждый сисадмин.(холодно) Я видел, как сисадмин за угрозу сесть вполне легально открывает доступ. Товарищам в погонах. И как такой же всего за паршивые сто баксов раскрывает конфиденциальные данные. Мне известны случаи бесследного исчезновения сисадминов. Редкие. Но также известны случаи их внезапного обогащения и ПМЖ в теплых краях.
> Вы путаете мелкую пакость надоевшему работодателю и конкретный криминал. Среди сисадминов
> (точнее сетевых админов) потенциальных уголовников я не видел.А я на луне флага США не видел. Его там нет?
> А я на луне флага США не видел. Его там нет?<offtopic>Почти уверен, что нет</offtopic>
Не забывайте о не зашифрованном WiFi - а такие мети стоят в большинстве публичных/бесплатных сетей во всевозможных заведениях. И такой трафик может перехватить кто угодно, и не нужен подконтрольный шлюз.
Вы уверены, что когда мне нужно будет провести банковскую транзакцию или для чего то другого воспользоваться SSL, я пойду в публичное заведение пользоваться бесплатным WiFi.Вопрос насколько сложно воспользоваться этой уязвимостью в реальных условиях.
> Вы уверены, что когда мне нужно будет провести банковскую транзакцию или для
> чего то другого воспользоваться SSL, я пойду в публичное заведение пользоваться
> бесплатным WiFi.С развитием online-банкинга уже типично перед покупкой залезть со смартфона/планшета и проверить сколько денег лежит на карте и при необходимости докинуть с отдельного счета. WebMoney и ЯндексДеньги тоже многие с телефонов пользуются.
Если у тебя не будет ДРУГОЙ возможности провести транзакцию, а транзакцию провести КОНКРЕТНО НУЖНО СЕЙЧАС - пойдешь как миленький.
> При таком количестве условий, при которых возможна атака, она становится *очень* трудно
> осуществимой.Ну-ну. При цене вопроса - "перехват банковской сессии" - можно выполнить ЛЮБОЕ количество условий.
Там еще трафик надо контролировать...
Думается мне - проще трояна подсадить на нужную машину и снять с нее пароли. Или, удаленно управляя, совершить транзакцию.
Большая проблема создать фиктивную точку доступа WiFi? На которую затянуть соединение жертвы?
К сожалению это сделать чуть ли не проще чем JavaScript в IFRAME...
> Большая проблема создать фиктивную точку доступа WiFi?Как два пальца...
- Семеныч, ну чо ты уже перевел лимон баксов кому надо?
- Нее, Петрович, мне до офиса доехать надо.
- Да ладно, тебе, время - деньги. У тебя же банк-клиент через веб работает. Зайди в ближайшую кафешку, они все с WiFi'ем, да проведи транзакцию. А в параллельном табе посмотришь фотки с порносайта, я тебе щас ссылку кину. Тока там надо с JavaScript'ом смотреть.
- А ну тада канешна, ща сделаю.С какого перепуга жертва ломанется на твой WiFi?
> С какого перепуга жертва ломанется на твой WiFi?Не ломанется на WiFi так кабель в подьезде/подвале/люке разрезать не долго
>> С какого перепуга жертва ломанется на твой WiFi?
> Не ломанется на WiFi так кабель в подьезде/подвале/люке разрезать не долгоПовторяю для тех, кто на бронепоезде. Все зависит от ЦЕНЫ ВОПРОСА. "За червонец потийский полицмейстер разденется" (С). Не я сказал. И кабель разрежут, и ТД поставят и на криминал любой пойдут. Цена вопроса.
> При таком количестве условий, при которых возможна атака, она становится *очень* трудно
> осуществимой.Собирать аккаунты можно элементарно. Создаешь свою точку доступа к каком-нибудь торговом центре с кафешками и делаешь Captive Portal для входа, на который вешаешь нужный JavaScript. Все условия выполнены.
И зачем тебе в таких условиях SSL ломать? Ты насобираешь паролей от кучи аккаунтов пользователей (они у них везде одинаковые). Только ни один из них не даст тебе доступа к сколько нибудь денежной информации, потому как в банковских личный кабинет никто не пойдет из WiFi торгового центра (ни через SSL ни без него).P.S. Если тебя поймают, разбираться ты будешь не с милицией, а с бандитами-охранниками ТЦ, только после этого тебя отвезут в "дружественное" начальнику охраны ТЦ отделение милиции.
> И зачем тебе в таких условиях SSL ломать? Ты насобираешь паролей от
> кучи аккаунтов пользователей (они у них везде одинаковые). Только ни один
> из них не даст тебе доступа к сколько нибудь денежной информации,
> потому как в банковских личный кабинет никто не пойдет из WiFi
> торгового центра (ни через SSL ни без него).Ты точно уверен, что не пойдет? Бывают совершенно патовые ситуации, когда НАДО, понимаешь? НАДО срочно. И ничего нет. Куда ты, милый, денешься?
> P.S. Если тебя поймают, разбираться ты будешь не с милицией, а с
> бандитами-охранниками ТЦ, только после этого тебя отвезут в "дружественное" начальнику
> охраны ТЦ отделение милиции."Если" - хорошее слово. Кстати, не повезут. Бесследно исчез человек. Так бывает.
В реальных условиях наверное целая контора нужна для организации такой атаки. Один кабель режит, другой яваскрипт "социалит"...С другой стороны если протокол дырявый ( условно говоря ), и дело по его изменению упёрлось только в несколько программ, так вроде очевидно, что протокол просто необходимо как минимум коррегировать, а как максимум постараться разработать более надёжный.
Как минимум нужно разработать более надежный.
То есть теперь, чтобы зайти в банковский аккаунт, нужно закрыть браузер (чтобы не осталось недозакрытых скрытых IFrame), открыть его с единственной вкладкой, залогиниться в банк и никаких других вкладок с JavaScript не открывать. Так как банк вряд ли встроит IFrame с кодом подбирающим куку, то все пройдет безопасно (подбирать данные для авторизации будет некому). Не очень удобно, если в другой вкладке нужно открыть страницу с данными для перевода денег, но безопасно.
Одно окно браузера, "NoScript", плюс только минимально необходимое время в сети.
не открывая левых окон можно не особо беспокоиться за шифрование...
<iframe> же
iframe еще и внедрить надо
что там внедрять? подменяем скрип рисующий популярные нынче кнопочки, типа "добавит в твитер, facebook i like, и т п" который обычно сами не пишут...
Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной степени уменьшает вероятность перехвата.
А что они не изолированы? Какой ужас.
> А что они не изолированы? Какой ужас.Да просто конекция реюзается, на свою задницу. Оптимизация скорости выходит боком.
> Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной
> степени уменьшает вероятность перехвата.Изоляция вкладок не поможет, все равно почти все браузеры для одного сайта, открытого несколько раз в разных вкладках, данные будут слать через одно уже установленное SSL-соединение.
У Хромиума, вроде как, задавалось с командной строки, per-tab или per-site. Или это касалось только rendering'а?
Да, это только рендеринг. С private prowsing попутали, небось.
> Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной
> степени уменьшает вероятность перехвата.Угу, щаз. Изолировать надо ключи и локальный сторадж... Корочч -- по отдельному бровзеру и профилю для каждого сайта. И ни-ни по ссылкам ходить... или скрытые фреймы открывать, или джаваскрипт пускать, или........ :(
Ну на самом деле вкладки и так изолированы друг от друга, если бы было не так то любой сайт мог был явой забирать куки любого другого моего сайта... Как-то-так.Та, насколько я понял, в другой вкладке ява-код просто генерирует заведомо известные шифрованные блоки... и дальше я не понял.
Написанно коряво, суть в отправки данных js со страницы одного сайта в контексте другого как фишки браузера - объединение сессий, и тут как раз "межсайтовый скриптинг" должен спасти (или как его там), но есть методы обхода его вполне официальные.Остается еще "защита" по проверки рефферов, но большенство серверов ее не используют
А красиво предумали.
Реферрер не спасет, так как его проверка возможно только ПОСЛЕ установки ссл сессии и отправки текста.
Дык перехват и происходит после установки сессии, а реферер скажет - есть ли прешедший пакет хакерский вброс с целью взлома с левого сайта; или пользователь кнопку обновить нажал.
хреново блин. кастую TLSv2.>осуществляется выполнение сниффера
перефразируйте пожалуйста, не по-русски оно.
А "кастую" типа по-русски? :)
> кастую TLSv2.Уже есть TLS 1.1+:
https://secure.wikimedia.org/wikipedia/en/wiki/Transport_Lay...
"TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0. Significant differences in this version include:
* Added protection against Cipher block chaining (CBC) attacks.
o The implicit Initialization Vector (IV) was replaced with an explicit IV.
o Change in handling of padding errors."Эту и другие полезные ссылки привели в этой дискуссии:
http://www.reddit.com/r/netsec/comments/kl1lr/hackers_break_.../
В том числе:
http://www.mail-archive.com/openssl-dev@openssl.org/msg...
2002-й год, проблема с IV уже была известна.
(Но новость серьезная - одно дело кусочек теории, а другое - практически продемонстрированная атака на реальные веб-сайты.)
NoScript спасет отцов русской демократии.
нет
Ага. То-то я смотрю на нем щас все переписывают. Начиная от qt и заканчивая целыми десктопами. Пре приложения вообще переписывают на js, перенося их в браузер. Такими темпами я думаю через 5 лет не останется ничего бинарного, все будет на жаваскриптах и дотнетах.
на чём переписывают?
Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль, к тому же бесполезный. Открой для себя по меньшей мере половину сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация пишется на JS. И как тебе Web 1.0 по W3C без JS вообще? Опаньки? Ну или кактус тебя устраивает?
Пользователи ноускрипта просто разрешают нужные сайты. Нормальные люди навигацию на сайте жестко завязанную на JS или, боже упаси, Flash не делают (если сайт не целиком на флэше). Так что лазить по инету без скриптов и разрешать их только на сайтах (или с сайтов), которым доверяешь, не такая и большая проблема как кажется. Я им пользовался некоторое время.Более того, можно настроить NoScript так, что он автоматически разрешаеет все скрипты с текущего домена или субдомена. Правда что б пользоваться этим режимом нужно понимать, что по левым ссылкам ходить с ним чревато, но зато все эти упоротые менюшки на скриптах гарантированно будут работать.
Фишка ноускрипта в том, что он позволяет ограничить выполнение скриптов только скриптами с определённых сайтов и если браузер пытается скачать скрипт из не доверенного источника, то он и не выполняется. В случае с iframe подразумевается встраивание одного сайта в другой. В такой ситуации даже если скрипты будут разрешены на текущем сайте они не будут работать во фрейме (если он не с того же сайта).
Это конечно костыль в данном случае, но крайне эффективный иснтрумент если хочется избавиться от здоровенной части рекламы и трекинга в интернете. А если учесть, что он ещё и умеет работать в режиме флэшблока разрешая выполнение флэш-роликов только по запросу пользователя…
> Я им пользовался некоторое время.И почему же перестал?
А что, AdBlock и Squid уже отменили с баннерорезками?
> А что, AdBlock и Squid уже отменили с баннерорезками?Squid - редкое явление у крупных провайдеров и просто на безлимитных тарифах.
Тем более настройка сквида для резки баннеров.
Не знаю, используется ли он ещё у буржуев (когда 30 мегабит за 50$ - накой там squid?).
Хомяки и слов таких не знают, а именно они создают основной вал инет-торговли.
> Нормальные люди навигацию на сайте жестко завязанную на JS <...> не делаютсвязанно это только-ЛИШЬ с тем что есть опасность неработоспособности такого сайта на MsIE (и Opera, конешноже, как лучший друг IE :))
еслибы не MsIE -- то давным давно-бы маршрутизация сайта переехала-бы из серверной части на клиенскую часть (тоесть переехалабы на Javascript, и все странички выглядилибы как -- my-site.org/#!/my_first_page , my-site.org/#!/my_first_page/sub_page , my-site.org/#!/my_second_page , my-site.org/#!/my_second_page/+param_name/param_value , ... )
....этобы одновременно:
1. разгрузило-бы серверную часть (которая по большей части -- занималась-бы только обеспечением связи с [моделью, из Model-View-Controller] базой данных для XMLHttpRequest-запросов)
2. и ускорилобы работу навигации сайтов на клиенской стороне -- так как шаблонизатор (визуальный стиль сайта) и маршрутизация/навигация -- полностью отрабатывались-бы локально на компьютере
3. многократно ускорило-бы работу выдачи сетевого-трафика из сервера, так как весь НЕ-динамический контент может отдаваться крайней-эффективным способом (или не передаваться вообще, если уже таковой есть в кэше на клиенской стороне) по сравнению с этими ПыхПых-скриптами (которые на каждый запрос генерируют кучу одних и техже действий, а потом ещё и передают данные которые на 75% "оказываются" точ-в-точ как и данные из прошлого запроса... где эффективность??? :):))..
----------
и только (повторюсь ещё раз) скажите спасибо говнобраузеру (и его говнокомпании) Microsoft Internet Explorer :-) , за то что вы до сих можете лазить по интернетам через свои NoScript-плугины :-D
>И как тебе Web 1.0 по W3C без JS вообще?Кошерно. Почитай комменты к новости про браузер Dillo.
> Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль,
> к тому же бесполезный. Открой для себя по меньшей мере половину
> сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация
> пишется на JS. И как тебе Web 1.0 по W3C без
> JS вообще? Опаньки? Ну или кактус тебя устраивает?Уже довольно давно пользуюсь NoScript. Большинство юзабельны без JS (да, кое что расползается и нет некоторых свистоперделок, ну и что).
Ну и выборочных разрешений для доверенных сайтов никто не отменял.
>> Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль,
>> к тому же бесполезный. Открой для себя по меньшей мере половину
>> сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация
>> пишется на JS. И как тебе Web 1.0 по W3C без
>> JS вообще? Опаньки? Ну или кактус тебя устраивает?
> Уже довольно давно пользуюсь NoScript. Большинство юзабельны без JS (да, кое что
> расползается и нет некоторых свистоперделок, ну и что).
> Ну и выборочных разрешений для доверенных сайтов никто не отменял.Да-да, CA тоже доверенные. Как бы. Были. И типа доверенные сайты не ломаются, да?
> Ну или кактус тебя устраивает?Пробовали?
Против MITM тебя никакой NoScript не спасет. Просто скрипты будут встраиваться в доверенные тобой страницы, или у тебя все страницы через SSL?
Интернет давно себя дискредитировал. Создаваясь как средство военной коммуникации, он себя не оправдал уже тогда, и его сбросили нам, чтобы можно бесконтрольно отслеживать все действия людей в Сети.
То ли дело фидонет.
То ли дело векторный гипертекстовый фидонет.
>фидонет.Гипертекстовый! Национаолтьный!! С поэтессами...
> То ли дело фидонет.Мицгóл, невозбрáнно залогиньтесь ужé!
FTN в этом плане на порядок хуже IP. Централизован по самое небалуйся, шифрования (по крайней мере, стандартизированного) на транспортных и протокольных слоях не имеет, для даже самого мягкого реалтайма непригоден, ну и вообще — умер давно, лол.
> FTN в этом плане на порядок хуже IP. Централизован по самое небалуйся,Можно подробнее с этого места? И что мне мешает делать обмен с любой нодой, если это у ней специально не запрещено?
> шифрования (по крайней мере, стандартизированного) на транспортных и протокольных слоях
> не имеетПростите, а какие у FidoNet особые транспортные протоколы? Там все основывается на передаче файлов, которые можно носить (и иногда носили) хоть на флопике. А файлы можно шифровать хоть мульен раз
>, для даже самого мягкого реалтайма непригоден, ну и вообще
Специально для риалтайма есть BBS.
А в общем случае, риалтайм определяется шириной канала. Файлики гоняются же.> — умер давно, лол.
Вам не мешает и хорошо.
> И что мне мешает делать обмен с любой нодой, если это у ней специально не запрещено?Нодой — ничто не мешает, идете, договариваетесь о пиринге, оно работает. Тут у нас F2F, на уровне чисто нод.
Хотя остаются еще зона, сеть и поинт в адресе. Об аналоге BGP в FTN можно только мечтать, все на обходе графа бродкастами, хех.
> Простите, а какие у FidoNet особые транспортные протоколы?
Так в том и прикол, что транспортных нет никаких. Речь была о «стандартизированном», а вся сеть — «мы тут как-то договорились и скрутили проводки».
Потому и централизованно, что, вообще говоря, нет метода как-либо соединиться с произвольной нодой. На уровне FTN — вообще, в принципе нет, а на уровне транспортов — нет обобщенного. Соответственно, нет той же децентрализованной мобильности (поинт уехал в другой город, хочет читать свою почту, или enjoy your велосипеды или добро пожаловать в ненавистный Интернет, который умеет маршрутизировать, хехе).
Про «протокольные» это я оговорился, имелось в виду, «прикладных». Хотя я сейчас посмотрел на binkp и удивился, оказывается, приделали туда шифрование, наврал я.
Не совсем понятно причём тут сам протокол TLS. Объединять запросы разных вкладок в один сокет — это же фишка конкретных браузеров и соответственно и проблема конкретных браузеров.
> Не совсем понятно причём тут сам протокол TLS.Вот как бы, да. Например, относится ли все написанное к, например, IMAP4-клиентам, работающим по TLS? Или, если даже касаться браузеров — тех же вебсокетов под TLS'ом (схема wss), где соединение и параметры TLS, вроде бы (не уверен!!!) не шарятся? Вроде как, никак не относится.
>> Не совсем понятно причём тут сам протокол TLS.
> Вот как бы, да. Например, относится ли все написанное к, например, IMAP4-клиентам,
> работающим по TLS? Или, если даже касаться браузеров — тех же
> вебсокетов под TLS'ом (схема wss), где соединение и параметры TLS, вроде
> бы (не уверен!!!) не шарятся? Вроде как, никак не относится.на самом деле тоже относится...
...но просто должнабыть какаято другая схема экплоита (чем в www-браузере)
сутьто ясна:
недоработка с вектором инициализации в TLS, поэтому имея возможность подставлять свой собственный (эталонный) открытый-текст и видить каким он получается в зашифрованном-виде -- мы [при определённых условиях] имеем возможность угадывать подобные зашифрованные блоки
что например если я [теоретически... это ещё надо до-продумать :)] отправлю несколько огромных писем с эталонными данными... а потом проснифлю зашифрованный трафик IMAP?
например, по криптоактвности (большая порция данных) я могу почти-достоверно определить что "вот щаз качается моё огромнное письмо"
ну и т д ...
> недоработка с вектором инициализации в TLSА оно вообще в принципе доработано может быть ? Насколько мне известно оно надо лишь для того чтобы данные не шифровались совсем уж прямо на основе открытого ключа, т.е. таким образом создается сессионный ключ, небольшое усложнение, но в случае перебора оно ни коим образом не помогает, грубо говоря криптостойкость ключа от того что вы его сгенерируете на основе других данных не измениться (не учитывая коллизий), если вам известны исходные данные то ключ относительно легко вычислить, алгоритм то открыт.
вектор инициализации не связан с генерацией ключей... ...(он используется в процессе шифрования),и нужен для того чтобы одни и теже зашифрованные-блоки открытого-текста (находящиеся в одном и томже месте зашифрованного сообщения, тобишь в данном случае в начале запроса) -- получались-бы каждый раз разными
а раз блоки получатся разными -- то вероятность одинаковых блоков (например при CBC-режиме-шифрования) уменьшается при увелечении размера блоков (например AES-256 имеет меньшею вероятность получения повторяющихся зашифрованных-блоков, чем AES-128)
> вектор инициализации не связан...Насколько я понимаю расшифровка (определение ключа) идет не на основе нахождения одинаковых блоков а на основе перебора - сопоставления известных исходных данных возможным вариантам их шифровки исходя из алгоритма шифрования. Алгоритм шифрования и вектор инициализации нам также известны как и сами данные, поэтому перебор можно существенно сократить. Вопрос в том на сколько существенно. Усложнение алгоритма/инициализации приводит к тормозам при шифровке/дешифровке, значит сильно их не усложнишь, а значит имея исходные данные и зная соответствующие особенности расшифровать за приемлемое время можно. Уж не знаю насколько это верное утверждение, в криптоматематике не силен, но спецы наверное не зря такого сочетания побаиваются.
> что например если я [теоретически... это ещё надо до-продумать :)] отправлю несколько огромных писем с эталонными данными... а потом проснифлю зашифрованный трафик IMAP?SMTP-сервер добавит к Вашим письмам с эталонными данными совсем не эталонные заголовки непредсказуемой длины, что очень сильно осложнит жизнь. А приличная хеш-функция, если мне не изменяет склероз, должна при изменении одного бита во входных данных изменить не менее половины бит в результирующем хеше.
Т.е. при шифровании письма целиком с заголовками и без, результат не будет иметь ничего общего...
> например, по криптоактвности (большая порция данных) я могу почти-достоверно определить что "вот щаз качается моё огромнное письмо"
Неее... Это я отправляю home video своему корешу... ;-)
> SMTP-сервер добавит к Вашим письмам с эталонными данными совсем не эталонные заголовки непредсказуемой длиныэт Вы верно подметили... один такой случайный заголовок (находящийся ПЕРЕД данными) -- напрочь вероятнее всего испортит всю идею.
...но яже так и написал: что нужно-додумать-всё-это :-)
вдруг например случайные заголовки окажутся не такими уж и "случйными" %) %) %)... или ещё чтонибудь всплывёт..... :)
>только переход на новый протоколУра! Давно пора.
Зачем такие сложности?
Headless webkit
публичная точка доступа wifi
репроксирование без ssl
...
Profit.
Намного проще.
>репроксирование без sslЧестно говоря не понял. Если удаленный узел принудительно перенаправляет соединение на https, то что Вы с этим будете делать?
отвечая на ваш вопрос что делать можно
-
ну, тут в одной недетской конторе безопасность додумалась подменять сертификаты
то есть идёте вы скажем в гугловую почту по https, а вам говорят - надо бы принять сертификат ...
-
вы его качаете, смотрите - вроде навскидку "по диагонали" правильно всё ... и в большинстве случаев жмёте "принять"
-
а если посмотреть кто удостоверяет его - окажется что якобы какой нибудь Microsoft, что уже странно. Но дальше оказывается, что этот издательский микрософтовый сертификат подписан самоподписанным сертификатом локальной конторы, который честно растиражирован на рабочие машины пользователей этой конторы как доверенный
-
как результат шибко умный сервер безопасников имеет весь контент в нешифрованном виде, пользователи не замечают лапшу на ушах и большого брата в личной переписке ... правильно, не фиг служебное железо использовать в личных целях :)
-
похожую схему можно выстроить и от провайдера, обязав разместить в доверенных издателях сертификат провайдера - например для личного кабинета
> отвечая на ваш вопрос что делать можно
> ...
> похожую схему можно выстроить и от провайдера, обязав разместить в доверенных издателях
> сертификат провайдера - например для личного кабинетаНавскидку, разместить iframe в том же личном кабинете провайдера гораздо проще, чем обязать юзеров использовать самоподписанные сертификаты. Ведь в большинстве атак получение cookies является достаточным для дальнейших действий.
> отвечая на ваш вопрос что делать можноНо дальше оказывается, что этот издательский микрософтовый
> сертификат подписан самоподписанным сертификатом локальной конторы, который честно растиражирован
> на рабочие машины пользователей этой конторы как доверенный
> -
> как результат шибко умный сервер безопасников имеет весь контент в нешифрованном виде,
> пользователи не замечают лапшу на ушах и большого брата в личной
> переписке ... правильно, не фиг служебное железо использовать в личных целях
> :)
> -
> похожую схему можно выстроить и от провайдера, обязав разместить в доверенных издателях
> сертификат провайдера - например для личного кабинетаКакой онанизм! В условиях конторы на комп пользователя политиками ставится кейлогер, типа Employee Monitor, коих чуть больше чем много. Есть под все платформы. Заодно они еще и зарплату считают.
Разве возможность зашифровать данные, посмотреть результат шифрования и НЕ узнать ключ не является одним из правил криптографии? Или тут не об этом?
> Разве возможность зашифровать данные, посмотреть результат шифрования и НЕ узнать ключ
> не является одним из правил криптографии? Или тут не об этом?В данном случае незашифрованные данные известны, их генерирует используемый для атаки JavaScript.
> Тай Данг (Thai Duong) и Джулиано Риццо (Juliano Rizzo)Прошу прощения, но он не Тай Данг, а Тхай Дыонг. Поправьте, пожалуйста, если можно.
Откуда такая информация? в языках от латинского в 'Th' 'h' не читается. И обычно звучит как 't', разве только в английском чуть по другому.
C каких пор китайский берет начало в латинском языке ? :D
> C каких пор китайский берет начало в латинском языке ? :DА что "Thai" - это китайские иероглифы?
> Откуда такая информация? в языках от латинского в 'Th' 'h' не читается.
> И обычно звучит как 't', разве только в английском чуть по
> другому.Это даже не китайский - это вьетнамский. Он вьетнамец. Thái Dương.
> которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AESТак. А вот, например, если браузер и вебсервер новый (openssl больше какой-то версии), то SSL по умолчанию использует 256-ти битный Camellia, а не AES. Как данная атака к этому относится?
>> которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES
> Так. А вот, например, если браузер и вебсервер новый (openssl больше какой-то
> версии), то SSL по умолчанию использует 256-ти битный Camellia, а не
> AES. Как данная атака к этому относится?Camellia патентована. И - где она повсеместно на серверах? А - самое главное - проблема не в шифрах, проблема В ПРОТОКОЛЕ. Компренде?
Ну, любой сервер на текущей версии редхата/центоси/SL как минимум по умолчанию предлагает Camellia из апача ;) А редхат обычно патентованные алгоритмы вырезает от греха подальше, вон ecc до сих пор в openssl выключена..То, что проблема в протоколе понятно; непонятно, какую роль тут играет шифр. Как я понял из описания, воссоздать блоки шифрования по контрольным меткам получается используя именно особенности AES.
Вот мне тоже это интересно, почему именно AES ? Зная алгоритм шифрования, исходные данные, и результат, подобрать можно только AES или это общая болезнь ? Существует ли такой алгоритм который не ломается относительно быстро если известны исходные данные и сам алгоритм ?
И всё равно неповоротливые задницы миллиардеров не пошевелятся, чтобы что-то изменить: их всё устраивает. HTML5 не хотят, каким образом повсеместно наступил Web 2.0 даже не знаю. Нужен пинок посильнее, вроде взлома ряда важных клиентов с последующей миграцией на другие способы обеспечения безопасности.
> И всё равно неповоротливые задницы миллиардеров не пошевелятся, чтобы что-то изменить:
> их всё устраивает. HTML5 не хотят, каким образом повсеместно наступил Web
> 2.0 даже не знаю. Нужен пинок посильнее, вроде взлома ряда важных
> клиентов с последующей миграцией на другие способы обеспечения безопасности.Ты притворяешься или и правда клиника? Сколько времени что-то становится стандартом де-факто? Сколько x500/x509 стандартом становились? Напомнить? И бабло вливалось лярдами, и движущая сила покруче RMS была. И что?
> Сколько x500/x509 стандартом становились? Напомнить? И бабло вливалось лярдами, и движущая сила покруче RMS была. И что?Да его с самого начало нужно было закапать, что собственно и выразилось в выпуске light версии.
зы. А если вспомнить сколько стандартов вообще умерло не родившись ... :)
зы2. а HTML5 будет, он действительно нужен.
То есть, обе вкладки будут юзать одну и туже SSL сессию. Яваскрипт будет отправлять в банк заведомо известные данные. Снифер будет видеть эти данные в зашифрованном виде, и зная их исходники, сможет подобрать ключ. Ы?
Абалдеть! :D Дяденьки открыли классический криптоанализ с возможностью генерации открытого текста. Только я недопонял, а salt-то хде?>JavaScript-код используется для отправки на сайт с которым работает жертва фиктивных запросов с изначально известными контрольными метками
> Абалдеть! :D Дяденьки открыли классический криптоанализ с возможностью генерации открытого
> текста. Только я недопонял, а salt-то хде?
>>JavaScript-код используется для отправки на сайт с которым работает жертва фиктивных запросов с изначально известными контрольными меткамиSalt вычисляется по известному алгоритму. Курить матчасть до просветления.
Salt вычисляется
А не берётся случайно?
> Salt вычисляется
> А не берётся случайно?Случайного в компе, увы, нет.
> Случайного в компе, увы, нет.а у меня в компе есть (/dev/random и чуть-меннее-случайный /dev/urandom) ...
...сажите -- у меня волшебный комп? o_0
Толку то, примесь вычисляется.
>> Случайного в компе, увы, нет.
> а у меня в компе есть (/dev/random и чуть-меннее-случайный /dev/urandom) ...
> ...сажите -- у меня волшебный комп? o_0Ты просто трындишь.
/dev/random не является полноценным аппаратным рандомизатором. Или у тебя, анон, Sun SPARC выпуска 2001 года? В них - да, /dev/random хардверный.
зачем мне на домашнем компьютере (на котором установлен www-браузер с поддержкой TLS/SSL) аппаратный рандомайзер от Sun SPARC? :-).. то что я щёлкаю клавиши на клавиатуре, то что мой жосткий диск производит хаотичную активность, то что я постоянно двигаю мышкой по столу -- всё это хотите сказать не является случайными данными? ЛОЛ
> /dev/random не является полноценным аппаратным рандомизатором. Или у тебя, анон, Sun SPARC
> выпуска 2001 года? В них - да, /dev/random хардверный.ну, товарищ привёл неудачный пример
а если так - в качестве демонстрации идеи ?
tail -20 /var/log/maillog | md5sum
думаю идея понятна - в компе вполне можно получить значение, которое будет практически случайным
Ну допустим получили, а как потом не зная этой соли на принимающей стороне расшифровать ?
Да никак. "Соль" или Примесь задаётся заранее известным алгоритмом или из таблицы.
> Да никак. "Соль" или Примесь задаётся заранее известным алгоритмом или из таблицы.Отсыпь.
>А не берётся случайно?man генератор псевдослучайных чисел
В общем, если пользуетесь платежами по карточке, то держите открытым только одно окно в браузере.
> В общем, если пользуетесь платежами по карточке, то держите открытым только одно
> окно в браузере.именно! плюсую :-)
а ещё с увелечением числа CSRF-уязвимостей в интернетах
(причём авторы этих сайтов обычно не хотят верить что на их сайте есть CSRF-уязвимость, пока не сделаешь персонально-для-них эксплоит)
-- вообще делаю вывод что в броузере должно быть открыто только одно окно с сайтом :-) [а потом ещё и кнопку выход недайбох забыть нажать!]
> В общем, если пользуетесь платежами по карточке, то держите открытым только одно
> окно в браузере.Можно пользоваться каким-то одним браузером только для банка.
Например, FF - для всего, Chrome - для банка.
Или Chrome - для всего, какой-нибудь Safari - для банка.
А если банк хочет только IE, то это только на руку всему миру - IE только для банка =)
платные (или собственные) vpn-аккаунты внезапно должны стать очень популярными.
А для параноиков лучше ходить лично на рынок (там камер меньше) и покупать за наличку. Но при этом дома, обязательно, "держите открытым только одно окно в браузере". :)
> А для параноиков лучше ходить лично на рынок (там камер меньше)
> и покупать за наличку.Так и делаем, плюс своё (в качестве дизель-генератора).
Используйте одноразовые пароли как в телебанке ВТБ24 и вам не будет страшен никакой перехват сессии.
И как эти пароли защищают от MitM?:) Даже на википедии в первых строках:
"Использование одноразовых паролей само по себе не защищает от атак, основанных на активном вмешательстве в канал связи, используемый для аутентификации"
Насчет сниффания - может и не нужно, если удастся похитрить с DNS.
Подставить свой ip для домена сайт-банка.рф.
Возможно, это реально сделать на JavaScript - работать с кешем DNS на машине клиента.Вообще для банка хорошо бы использовать Шифр Вернама (система одноразовых блокнотов) ( http://ru.wikipedia.org/wiki/%D0%A8%D0%B... ).
Сделать сайт банка, где статика грузится с одного домена (там простой tls, пусть ломают), а динамика, запросы, бабло, текст - с другого домена (там шифр вермана).
Допустим, одна банковская операция занимает 1-10 кб текстового трафика.
Допустим, в день делается 10 операций.
Тогда в день будет тратиться 10-100 кб.
Пусть даже 1 Мб трафика в день.
При регистрации можно передать клиенту флешку с 2 гигами одноразовых паролей (1 гиг на шифрование передачи, 1 гиг на дешифрование приема).
Этого должно хватить с головой на год-другой.
И все, через интернет сие взломать не возможно, даже пустив весь банковский трафик через сниффер.
>ВерманаДа чего вы до него докапались-то?
Хватит адекватной реализации любого сильного алгоритма шифрования, адекватного протокола и достаточной длины ключа.
>>Вермана
> Да чего вы до него докапались-то?
> Хватит адекватной реализации любого сильного алгоритма шифрования, адекватного протокола
> и достаточной длины ключа.А почему-бы и нет?
Шифр не требователен к ресурсам проца.
При текущих объемах жестких и флешек хранить пару гиг одноразовых данных - не проблема.
А так пока видна гонка алгоритмов:
- хаха! мы сделали алгоритм сложности 2 в степени n!
- хаха! мы научились понижать степень на 2!
- хаха! мы сделали такую большую n, что по барабану на ваши 2!
- хаха! мы научились взламывать при любом n!А ещё видна гонка шифрующих/дешифрующих мощностей.
Знаете, сколько раз winrar шифрует ключ?
С другой стороны, знаете, сколько миллиардов паролей в секунду подбирает одна видеокарта?Поэтому шифр, для которого доказана абсолютная криптостойкость (при любом росте мощностей), заслуживает внимания.
Возможно, при развитии квантовой криптографии (когда сниффер палится), все равно придут к чему-то подобному.
Не понятно причём здесь недостатки протоколов, если взломаются сообщения зашифрованные по алгоритму AES
> Не понятно причём здесь недостатки протоколов, если взломаются сообщения зашифрованные
> по алгоритму AESЯ так понял, сообщения шифруются одним ключиком в течение всего сеанса или достаточного для проведения атаки времени. AES, вероятно, недостаточно стоек при возможности выбора открытых текстов и при данной (недостаточной?) длине ключа.
>>недостаточно стоек при возможности выбора открытых текстовЯ не думают что алгоритм не проверили на стойкость к этому виду атаки, прежде чем его сделали стандартом.
>>при данной (недостаточной?) длине ключа.
Вообще то при такой длине ключа как 128-256 бит, сообщение не должно быть расшифровано за 5-10 минут, иначе ключ не был бы пригоден для защиты данных.
Надо детально смотреть, что и как они там "поломали". Честно, мне - лень. :D
>>>недостаточно стоек при возможности выбора открытых текстов
> Я не думают что алгоритм не проверили на стойкость к этому виду
> атаки, прежде чем его сделали стандартом.
>>>при данной (недостаточной?) длине ключа.
> Вообще то при такой длине ключа как 128-256 бит, сообщение не должно
> быть расшифровано за 5-10 минут, иначе ключ не был бы пригоден
> для защиты данных.Грубо говоря:
Дано:
- есть функция хеширования xor;
- есть исходные данные;
- есть результат хеширования;
Вопрос:
- за сколько можно узнать ключ хеширования?Правильно - мгновенно.
исходник -> xor -> результат = ключ.
Только в статье не xor, а aes.
> Грубо говоря:
> Дано:
> - есть функция хеширования xor;
> - есть исходные данные;
> - есть результат хеширования;
> Вопрос:
> - за сколько можно узнать ключ хеширования?
> Правильно - мгновенно.
> исходник -> xor -> результат = ключ.
> Только в статье не xor, а aes.Хеширование и шифрование это не одно и тоже, так что предложенный алгоритм не прокатит -)
И, битовая операция XOR (исключающее ИЛИ) - это тоже совсем не шифрование. ;)
И не хеширование.
И когда уже эта фигня про "xor-шифрование" перестанет проникать в неокрепшие умы?
> И когда уже эта фигня про "xor-шифрование" перестанет проникать в неокрепшие умы?Шифр вернама как раз работает через xor.
И считается абсолютно стойким шифром.
> Шифр вернама как раз работает через xor.
> И считается абсолютно стойким шифром.Шифр Вернама работает через ключ гаммирования длины == длине открытого текста. Гамму можно класть хоть xor-ом (сложение под mod 2), хоть по любому другому модулю, например, для англ. алфавита по mod 26 (или сколько там букв? :D), хоть любым другим раком.
>> Шифр вернама как раз работает через xor.
>> И считается абсолютно стойким шифром.
> Шифр Вернама работает через ключ гаммирования длины == длине открытого текста. Гамму
> можно класть хоть xor-ом (сложение под mod 2), хоть по любому
> другому модулю, например, для англ. алфавита по mod 26 (или сколько
> там букв? :D), хоть любым другим раком.Ну да.
Нагенерить несколько гигов рандомных данных, обменяться этими гигами, и шифровать)
И ведь не расшифровать, даже вклинившись.
> И не хеширование.Все такие умные.
Знают правильные определения.
А подумать дальше определений - понять, что это грубый пример описанного способа - не осилили.
В моем примере можно написать не xor, а md5.
Суть в том, что когда известны первоначальный и зашифрованный блоки, можно попробовать подобрать ключ шифрования.
>Вопрос:
>- за сколько можно узнать ключ хеширования?
>Правильно - мгновенно.
>можно попробовать
> подобратьВот в этом "можно попробовать" и есть вся соль.
>>Вопрос:
>>- за сколько можно узнать ключ хеширования?
>>Правильно - мгновенно.
>>можно попробовать
>> подобрать
> Вот в этом "можно попробовать" и есть вся соль.AES уже попробовали.
Слава богу, что каждый протокол нужно взламывать в частном порядке, и достаточно просто перейти на TLS 1.1/1.2.
> AES уже попробовали.Разве тут что-то было про aes?
>> AES уже попробовали.
> Разве тут что-то было про aes?JavaScript-код используется для отправки на сайт, с которым работает жертва, фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES.
Вы читали новость?
>>> AES уже попробовали.:E Уязвимость _в протоколе_ SSL. AES вполне себе живой. ;)