The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен первый успешный способ атаки на SSL/TLS

20.09.2011 09:58

Тхай Дыонг (Thai Duong) и Джулиано Риццо (Juliano Rizzo), известные исследователи компьютерной безопасности, обладатели премии Pwnie Awards 2011 за разработку метода компрометации приложений ASP.NET, намерены на конференции Ekoparty 7 раскрыть завесу над новым способом атаки на SSL/TLS. Для осуществления атаки подготовлен инструментарий, развиваемый под именем BEAST (Browser Exploit Against SSL/TLS) и позволяющий организовать перехват передаваемого в рамках зашифрованного соединения Cookie с параметрами аутентификации пользовательской сессии. В частности, исследователи продемонстрировали успешный перехват защищенной сессии для сервиса PayPal и утверждают, что метод применим и для любых других сайтов.

Судя по всему представленная работа является первым удачным методом атаки против TLS 1.0 и SSL 3.0, позволяющим расшифровать на лету запросы, отправляемые через HTTPS. Например, метод позволяет получить доступ к важной конфиденциальной информации, фигурирующей при работе с такими сервисами, как online-банкинг, службы электронной коммерции и платежные системы. Проблему усугубляет то, что она основывается на принципиальных недостатках протоколов TLS 1.0 и SSL 3.0, устранить которые можно только значительно переработав протокол. Закрытые обсуждения возможных путей решения проблемы с разработчиками браузеров и поставщиками SSL-продуктов проводятся начиная с мая, но они пока привели только к неутешительному выводу - все предложенные методы решения проблемы приводили к нарушению совместимости протокола с некоторыми SSL-приложениями.

Атака проводится многоэтапно. Для успешного осуществления атаки требуется запуск JavaScript-кода в браузере клиента, который должен быть запущен после установки SSL-соединения браузера с сайтом, данные которого требуется перехватить (SSL-соединение остается открытым длительное время, поэтому у атакующего есть запас времени). JavaScript-код не требуется запускать в контексте атакуемого сайта, его достаточно открыть в новой вкладке, например, путем встраивания через iframe в какой-нибудь сторонний сайт, открытие которого можно стимулировать методами социальной инженерии. JavaScript-код используется для отправки на сайт, с которым работает жертва, фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES.

После того как вспомогательный JavaScript-код запущен, на одном из промежуточных шлюзов осуществляется запуск сниффера (Организовать поток трафика через свой шлюз злоумышленник может, осуществив атаку в подконтрольной WiFi-сети или подключив свой сервер, разрезав кабель локальной или домашней сети. На этом же шлюзе может быть организована подстановка JavaScript-кода в запрашиваемые пользователем по незашифрованному каналу связи страницы). Задача сниффера сводится к выявлению связанных с определенным сайтом TLS-соединений, их перехват и расшифровка начальной части HTTPS-запроса, в которой содержится HTTPS Cookie (запросы вспомогательного скрипта отправляются через ранее установленный SSL-канал, при этом браузер добавит к этим запросам все ранее установленные Cookie). После того, как удалось воссоздать идентифицирующую HTTPS Cookie, осуществляется классическая атака, позволяющая вклиниться в активную сессию жертвы.

Расшифровка основана на методе угадывания содержимого отдельных блоков, часть которых содержит данные отправляемые подставным JavaScript-кодом. Если в процессе подбора предположение о содержимом блока оказывается верным, блочный шифр получит такие же входные данные для нового блока, как и для старого блока, произведя идентичный зашифрованный текст. На расшифровку байт за байтом всего содержимого идентификационной HTTPS Cookie, которая имеет размер 1000-2000 байт, для таких сайтов как PayPal тратится 5-10 минут. Для сайтов использующих вместо TLS 1.x и SSL 3.0 устаревший SSL 2.0 скорость подбора может быть кардинально увеличена.

Атака с использованием браузера является одним из возможных вариантов и может быть переработана для нападения на другие продукты, использующие TLS и SSL, такие как VPN или клиенты для мгновенного обмена сообщениями. По мнению исследователей, производители web-браузеров в скором времени добавят в свои продукты обходной путь блокирования подобных атак, но так как суть проблемы кроется в недоработке архитектуры TLS и SSL, полноценным решением проблемы может быть только переход на новый протокол. Например, проблеме не подвержены уже доступные протоколы TLS 1.1 или TLS 1.2, степень внедрения которых в браузерах и на серверах находится почти на нулевом уровне: из полутора миллионов проверенных серверов 600 тыс. поддерживают TLS 1.0, 600 тыс. SSL 3.0, 300 тыс. устаревший SSL 2.0, 838 - TLS 1.1 и только 11 TLS 1.2.

  1. Главная ссылка к новости (http://threatpost.com/en_us/bl...)
  2. OpenNews: В протоколах SSL/TLS найдена критическая уязвимость
  3. OpenNews: Исследователи подчеркнули легкость расшифровки SSL-трафика от встраиваемых устройств
  4. OpenNews: Взлом аккаунта в удостоверяющем центре Comodo привёл к генерации 9 обманных SSL-сертификатов
  5. OpenNews: Опубликован полный список обманных SSL-сертификатов. В списке ЦРУ и МИ-6
  6. OpenNews: GlobalSign временно приостановил выдачу SSL-сертификатов из-за возможной компрометации
Лицензия: CC-BY
Тип: Интересно / Проблемы безопасности
Короткая ссылка: https://opennet.ru/31797-ssl
Ключевые слова: ssl, tls, security, sniffer, attack
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (147) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, jedie (?), 10:29, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Это серьезно.
     
     
  • 2.2, Онаним (?), 10:38, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При таком количестве условий, при которых возможна атака, она становится *очень* трудно осуществимой.
     
     
  • 3.4, Rom1 (ok), 10:47, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Т.е. при тщательной подготовке все-таки возможна.

     
     
  • 4.60, Аноним (-), 14:46, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А до выхода нового протокола NoScript лишний раз нам друг и товарищ, так что посторонние iframe'ы - пролетают.
     
  • 3.19, jedie (?), 11:09, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом сайте. И все другие SSL можно читать?
     
     
  • 4.41, koloboid (ok), 12:24, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом
    > сайте. И все другие SSL можно читать?

    нет

     
     
  • 5.45, ммм (?), 13:05, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не вижу каких то больших условий. Встраиваем IFRAME. В каком то левом
    >> сайте. И все другие SSL можно читать?
    > нет

    А почему это нет???

     
     
  • 6.52, follow_me (?), 13:21, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что должен быть подконтрольный шлюз через который ходит жертва в интернет через который можно снифать трафик

    то есть одно из минимальных условий то, что злоумышленник должен контролировать шлюз вашего провайдера или WiFi через который выходит человек

    это более серьезное условие чем просто IFRAME

    хотя самое страшное то что позволит к примеру самим операторам снифать защищенный трафик и дешифровать его. И инъекция постороннего кода для них не составит проблем

     
     
  • 7.59, Аноним (-), 14:33, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что должен быть подконтрольный шлюз через который ходит жертва в интернет
    > через который можно снифать трафик
    > то есть одно из минимальных условий то, что злоумышленник должен контролировать шлюз
    > вашего провайдера или WiFi через который выходит человек
    > это более серьезное условие чем просто IFRAME
    > хотя самое страшное то что позволит к примеру самим операторам снифать защищенный
    > трафик и дешифровать его. И инъекция постороннего кода для них не
    > составит проблем

    Цена вопроса - пятсот баксов сисадмину провайдера. И все. Продаются все. Вопрос лишь в цене.

     
     
  • 8.61, Michael Shigorin (ok), 14:47, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Нет ... текст свёрнут, показать
     
     
  • 9.99, Аноним (-), 17:13, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Твои хотелки, Майк, не есть реальность К сожалению Я бы тоже хотел, чтобы был ... текст свёрнут, показать
     
     
  • 10.107, Michael Shigorin (ok), 17:52, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хотелки хотелками, а ответ на утверждение остаётся в силе Мне известны не прода... текст свёрнут, показать
     
     
  • 11.109, Anonymouse (?), 18:36, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В фортунки ... текст свёрнут, показать
     
  • 9.115, Анонимоус (?), 21:32, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я являюсь начальником IT отдела у ISP Провернуть подобное, в масштабах всей сет... текст свёрнут, показать
     
  • 8.63, Аноним (-), 14:48, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А также 1 Фиктивная точка доступа 2 Флуд свичей и спуфинг 3 Просто наглей... текст свёрнут, показать
     
  • 8.85, ezhik (?), 16:36, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    За недельную зарплату получить вполне реальный шанс оказаться на нарах с перелом... текст свёрнут, показать
     
     
  • 9.101, Аноним (-), 17:15, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    холодно Я видел, как сисадмин за угрозу сесть вполне легально открывает доступ... текст свёрнут, показать
     
     
  • 10.140, Тоже аноним (?), 17:51, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    offtopic Почти уверен, что нет offtopic ... текст свёрнут, показать
     
  • 7.74, linalex (ok), 15:10, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не забывайте о не зашифрованном WiFi - а такие мети стоят в большинстве публичных/бесплатных сетей во всевозможных заведениях. И такой трафик может перехватить кто угодно, и не нужен подконтрольный шлюз.
     
     
  • 8.84, ezhik (?), 16:29, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы уверены, что когда мне нужно будет провести банковскую транзакцию или для чег... текст свёрнут, показать
     
     
  • 9.88, Аноним (-), 16:45, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    С развитием online-банкинга уже типично перед покупкой залезть со смартфона план... текст свёрнут, показать
     
  • 9.104, Аноним (-), 17:23, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя не будет ДРУГОЙ возможности провести транзакцию, а транзакцию провес... текст свёрнут, показать
     
  • 3.23, Аноним (-), 11:13, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > При таком количестве условий, при которых возможна атака, она становится *очень* трудно
    > осуществимой.

    Ну-ну. При цене вопроса - "перехват банковской сессии" - можно выполнить ЛЮБОЕ количество условий.

     
     
  • 4.51, Онаним (?), 13:20, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Там еще трафик надо контролировать...
    Думается мне - проще трояна подсадить на нужную машину и снять с нее пароли. Или, удаленно управляя, совершить транзакцию.
     
     
  • 5.58, Аноним (-), 14:32, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Большая проблема создать фиктивную точку доступа WiFi? На которую затянуть соединение жертвы?
     
     
  • 6.76, Rom1 (ok), 15:20, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению это сделать чуть ли не проще чем JavaScript в IFRAME...

     
  • 6.87, ezhik (?), 16:42, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Большая проблема создать фиктивную точку доступа WiFi?

    Как два пальца...

    - Семеныч, ну чо ты уже перевел лимон баксов кому надо?
    - Нее, Петрович, мне до офиса доехать надо.
    - Да ладно, тебе, время - деньги. У тебя же банк-клиент через веб работает. Зайди в ближайшую кафешку, они все с WiFi'ем, да проведи транзакцию. А в параллельном табе посмотришь фотки с порносайта, я тебе щас ссылку кину. Тока там надо с JavaScript'ом смотреть.
    - А ну тада канешна, ща сделаю.

    С какого перепуга жертва ломанется на твой WiFi?

     
     
  • 7.92, Аноним (-), 17:02, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > С какого перепуга жертва ломанется на твой WiFi?

    Не ломанется на WiFi так кабель в подьезде/подвале/люке разрезать не долго

     
     
  • 8.105, Аноним (-), 17:24, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Повторяю для тех, кто на бронепоезде Все зависит от ЦЕНЫ ВОПРОСА За червонец ... текст свёрнут, показать
     
  • 3.77, Аноним (-), 15:28, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > При таком количестве условий, при которых возможна атака, она становится *очень* трудно
    > осуществимой.

    Собирать аккаунты можно элементарно. Создаешь свою точку доступа к каком-нибудь торговом центре с кафешками и делаешь Captive Portal для входа, на который вешаешь нужный JavaScript. Все условия выполнены.

     
     
  • 4.89, ezhik (?), 16:49, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И зачем тебе в таких условиях SSL ломать? Ты насобираешь паролей от кучи аккаунтов пользователей (они у них везде одинаковые). Только ни один из них не даст тебе доступа к сколько нибудь денежной информации, потому как в банковских личный кабинет никто не пойдет из WiFi торгового центра (ни через SSL ни без него).

    P.S. Если тебя поймают, разбираться ты будешь не с милицией, а с бандитами-охранниками ТЦ, только после этого тебя отвезут в "дружественное" начальнику охраны ТЦ отделение милиции.

     
     
  • 5.102, Аноним (-), 17:17, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И зачем тебе в таких условиях SSL ломать? Ты насобираешь паролей от
    > кучи аккаунтов пользователей (они у них везде одинаковые). Только ни один
    > из них не даст тебе доступа к сколько нибудь денежной информации,
    > потому как в банковских личный кабинет никто не пойдет из WiFi
    > торгового центра (ни через SSL ни без него).

    Ты точно уверен, что не пойдет? Бывают совершенно патовые ситуации, когда НАДО, понимаешь? НАДО срочно. И ничего нет. Куда ты, милый, денешься?

    > P.S. Если тебя поймают, разбираться ты будешь не с милицией, а с
    > бандитами-охранниками ТЦ, только после этого тебя отвезут в "дружественное" начальнику
    > охраны ТЦ отделение милиции.

    "Если" - хорошее слово. Кстати, не повезут. Бесследно исчез человек. Так бывает.


     
  • 3.121, Аноним Ус (ok), 02:28, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В реальных условиях наверное целая контора нужна для организации такой атаки. Один кабель режит, другой яваскрипт "социалит"...

    С другой стороны если протокол дырявый ( условно говоря ), и дело по его изменению упёрлось только в несколько программ, так вроде очевидно, что протокол просто необходимо как минимум коррегировать, а как максимум постараться разработать более надёжный.

     
     
  • 4.123, jedie (?), 05:48, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум нужно разработать более надежный.
     
  • 2.46, ezhik (?), 13:05, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    То есть теперь, чтобы зайти в банковский аккаунт, нужно закрыть браузер (чтобы не осталось недозакрытых скрытых IFrame), открыть его с единственной вкладкой, залогиниться в банк и никаких других вкладок с JavaScript не открывать. Так как банк вряд ли встроит IFrame с кодом подбирающим куку, то все пройдет безопасно (подбирать данные для авторизации будет некому). Не очень удобно, если в другой вкладке нужно открыть страницу с данными для перевода денег, но безопасно.
     
     
  • 3.122, Аноним Ус (ok), 02:31, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Одно окно браузера, "NoScript", плюс только минимально необходимое время в сети.
     

     ....большая нить свёрнута, показать (35)

  • 1.3, Аноним (-), 10:41, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не открывая левых окон можно не особо беспокоиться за шифрование...
     
     
  • 2.13, Аноним (-), 11:05, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    <iframe> же
     
     
  • 3.40, koloboid (ok), 12:24, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    iframe еще и внедрить надо
     
     
  • 4.81, aaa (??), 16:02, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    что там внедрять? подменяем скрип рисующий популярные нынче кнопочки, типа "добавит в твитер, facebook i like,  и т п" который обычно сами не пишут...
     

  • 1.5, vadiml (ok), 10:47, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной степени уменьшает вероятность перехвата.
     
     
  • 2.6, anonymous (??), 10:50, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что они не изолированы? Какой ужас.
     
     
  • 3.66, Аноним (-), 14:51, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А что они не изолированы? Какой ужас.

    Да просто конекция реюзается, на свою задницу. Оптимизация скорости выходит боком.

     
  • 2.7, Аноним (-), 10:54, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной
    > степени уменьшает вероятность перехвата.

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

     
     
  • 3.24, Аноним (-), 11:22, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У Хромиума, вроде как, задавалось с командной строки, per-tab или per-site. Или это касалось только rendering'а?
     
     
  • 4.34, Имя (?), 11:43, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да, это только рендеринг. С private prowsing попутали, небось.
     
  • 2.8, Andrey Mitrofanov (?), 10:56, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Как я понимаю, полная изоляция вкладок броузера друг от друга в значительной
    > степени уменьшает вероятность перехвата.

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

     
  • 2.11, Дмитрий (??), 11:01, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну на самом деле вкладки и так изолированы друг от друга, если бы было не так то любой сайт мог был явой забирать куки любого другого моего сайта... Как-то-так.

    Та, насколько я понял, в другой вкладке ява-код просто генерирует заведомо известные шифрованные блоки... и дальше я не понял.

     
  • 2.20, cmp (ok), 11:11, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Написанно коряво, суть в отправки данных js со страницы одного сайта в контексте другого как фишки браузера - объединение сессий, и тут как раз "межсайтовый скриптинг" должен спасти (или как его там), но есть методы обхода его вполне официальные.

    Остается еще "защита" по проверки рефферов, но большенство серверов ее не используют

    А красиво предумали.

     
     
  • 3.57, samm (ok), 14:29, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Реферрер не спасет, так как его проверка возможно только ПОСЛЕ установки ссл сессии и отправки текста.
     
     
  • 4.90, cmp (ok), 16:56, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Дык перехват и происходит после установки сессии, а реферер скажет - есть ли прешедший пакет хакерский вброс с целью взлома с левого сайта; или пользователь кнопку обновить нажал.
     

  • 1.9, koloboid (ok), 10:56, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хреново блин. кастую TLSv2.

    >осуществляется выполнение сниффера

    перефразируйте пожалуйста, не по-русски оно.

     
     
  • 2.49, Cub (ok), 13:19, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А "кастую" типа по-русски? :)
     
  • 2.56, solardiz (ok), 14:24, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже есть TLS 1 1 https secure wikimedia org wikipedia en wiki Transport_Laye... большой текст свёрнут, показать
     

  • 1.10, дикий анон (?), 11:00, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    NoScript спасет отцов русской демократии.

     
     
  • 2.12, Дмитрий (??), 11:02, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    нет
     
  • 2.15, Корж (?), 11:06, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/

    Ага. То-то я смотрю на нем щас все переписывают. Начиная от qt и заканчивая целыми десктопами. Пре приложения вообще переписывают на js, перенося их в браузер. Такими темпами я думаю через 5 лет не останется ничего бинарного, все будет на жаваскриптах и дотнетах.
     
     
  • 3.73, Макс (??), 15:07, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    на чём переписывают?
     
  • 2.21, Аноним (-), 11:12, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль, к тому же бесполезный. Открой для себя по меньшей мере половину сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация пишется на JS. И как тебе Web 1.0 по W3C без JS вообще? Опаньки? Ну или кактус тебя устраивает?
     
     
  • 3.28, Lain_13 (?), 11:35, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Пользователи ноускрипта просто разрешают нужные сайты Нормальные люди навигацию... большой текст свёрнут, показать
     
     
  • 4.30, Аноним (-), 11:39, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я им пользовался некоторое время.

    И почему же перестал?

     
  • 4.47, Аноним (-), 13:18, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А что, AdBlock и Squid уже отменили с баннерорезками?
     
     
  • 5.130, XoRe (ok), 12:31, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, AdBlock и Squid уже отменили с баннерорезками?

    Squid - редкое явление у крупных провайдеров и просто на безлимитных тарифах.
    Тем более настройка сквида для резки баннеров.
    Не знаю, используется ли он ещё у буржуев (когда 30 мегабит за 50$ - накой там squid?).

     
  • 4.70, Кирилл (??), 15:02, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хомяки и слов таких не знают, а именно они создают основной вал инет-торговли.
     
  • 4.75, Xasd (ok), 15:15, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    связанно это только-ЛИШЬ с тем что есть опасность неработоспособности такого сай... большой текст свёрнут, показать
     
  • 3.33, Аноним (-), 11:42, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >И как тебе Web 1.0 по W3C без JS вообще?

    Кошерно. Почитай комменты к новости про браузер Dillo.

     
  • 3.48, MrClon (?), 13:19, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль,
    > к тому же бесполезный. Открой для себя по меньшей мере половину
    > сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация
    > пишется на JS. И как тебе Web 1.0 по W3C без
    > JS вообще? Опаньки? Ну или кактус тебя устраивает?

    Уже довольно давно пользуюсь NoScript. Большинство юзабельны без JS (да, кое что расползается и нет некоторых свистоперделок, ну и что).
    Ну и выборочных разрешений для доверенных сайтов никто не отменял.

     
     
  • 4.62, Аноним (-), 14:48, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не спасет. Принципиальная уязвимость реализации костылем не закрывается. No Script - костыль,
    >> к тому же бесполезный. Открой для себя по меньшей мере половину
    >> сайтов инета, которые без JS не функциональны. Вообще. Как минимум навигация
    >> пишется на JS. И как тебе Web 1.0 по W3C без
    >> JS вообще? Опаньки? Ну или кактус тебя устраивает?
    > Уже довольно давно пользуюсь NoScript. Большинство юзабельны без JS (да, кое что
    > расползается и нет некоторых свистоперделок, ну и что).
    > Ну и выборочных разрешений для доверенных сайтов никто не отменял.

    Да-да, CA тоже доверенные. Как бы. Были. И типа доверенные сайты не ломаются, да?

     
  • 3.65, Michael Shigorin (ok), 14:50, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну или кактус тебя устраивает?

    Пробовали?

     
  • 2.100, Аноним (-), 17:13, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Против MITM тебя никакой NoScript не спасет. Просто скрипты будут встраиваться в доверенные тобой страницы, или у тебя все страницы через SSL?
     

  • 1.14, Аноним (-), 11:06, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интернет давно себя дискредитировал. Создаваясь как средство военной коммуникации, он себя не оправдал уже тогда, и его сбросили нам, чтобы можно бесконтрольно отслеживать все действия людей в Сети.
    То ли дело фидонет.
     
     
  • 2.16, Вова (?), 11:08, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    То ли дело векторный гипертекстовый фидонет.
     
  • 2.17, Andrey Mitrofanov (?), 11:08, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >фидонет.

    Гипертекстовый! Национаолтьный!! С поэтессами...

     
  • 2.26, Аноним (-), 11:30, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То ли дело фидонет.

    Мицгóл, невозбрáнно залогиньтесь ужé!

    FTN в этом плане на порядок хуже IP. Централизован по самое небалуйся, шифрования (по крайней мере, стандартизированного) на транспортных и протокольных слоях не имеет, для даже самого мягкого реалтайма непригоден, ну и вообще — умер давно, лол.

     
     
  • 3.43, ffirefox (?), 12:42, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > FTN в этом плане на порядок хуже IP. Централизован по самое небалуйся,

    Можно подробнее с этого места? И что мне мешает делать обмен с любой нодой, если это у ней специально не запрещено?

    > шифрования (по крайней мере, стандартизированного) на транспортных и протокольных слоях
    > не имеет

    Простите, а какие у FidoNet особые транспортные протоколы? Там все основывается на передаче файлов, которые можно носить (и иногда носили) хоть на флопике. А файлы можно шифровать хоть мульен раз

    >, для даже самого мягкого реалтайма непригоден, ну и вообще

    Специально для риалтайма есть BBS.
    А в общем случае, риалтайм определяется шириной канала. Файлики гоняются же.

    > — умер давно, лол.

    Вам не мешает и хорошо.

     
     
  • 4.67, Аноним (-), 15:00, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Нодой 8212 ничто не мешает, идете, договариваетесь о пиринге, оно работает Т... большой текст свёрнут, показать
     

  • 1.25, Аноним (-), 11:26, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Не совсем понятно причём тут сам протокол TLS. Объединять запросы разных вкладок в один сокет — это же фишка конкретных браузеров и соответственно и проблема конкретных браузеров.
     
     
  • 2.27, Аноним (-), 11:33, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не совсем понятно причём тут сам протокол TLS.

    Вот как бы, да. Например, относится ли все написанное к, например, IMAP4-клиентам, работающим по TLS? Или, если даже касаться браузеров — тех же вебсокетов под TLS'ом (схема wss), где соединение и параметры TLS, вроде бы (не уверен!!!) не шарятся? Вроде как, никак не относится.

     
     
  • 3.80, Xasd (ok), 15:49, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    на самом деле тоже относится но просто должнабыть какаято другая схема экп... большой текст свёрнут, показать
     
     
  • 4.86, Аноним (-), 16:38, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > недоработка с вектором инициализации в TLS

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

     
     
  • 5.93, Xasd (ok), 17:02, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    вектор инициализации не связан с генерацией ключей... ...(он используется в процессе шифрования),

    и нужен для того чтобы одни и теже зашифрованные-блоки открытого-текста (находящиеся в одном и томже месте зашифрованного сообщения, тобишь в данном случае в начале запроса) -- получались-бы каждый раз разными

    а раз блоки получатся разными -- то вероятность одинаковых блоков (например при CBC-режиме-шифрования) уменьшается при увелечении размера блоков (например AES-256 имеет меньшею вероятность получения повторяющихся зашифрованных-блоков, чем AES-128)

     
     
  • 6.108, Аноним (-), 18:16, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > вектор инициализации не связан...

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

     
  • 4.91, Moomintroll (ok), 17:01, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > что например если я [теоретически... это ещё надо до-продумать :)] отправлю несколько огромных писем с эталонными данными... а потом проснифлю зашифрованный трафик IMAP?

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

    Т.е. при шифровании письма целиком с заголовками и без, результат не будет иметь ничего общего...

    > например, по криптоактвности (большая порция данных) я могу почти-достоверно определить что "вот щаз качается моё огромнное письмо"

    Неее... Это я отправляю home video своему корешу... ;-)

     
     
  • 5.95, Xasd (ok), 17:05, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > SMTP-сервер добавит к Вашим письмам с эталонными данными совсем не эталонные заголовки непредсказуемой длины

    эт Вы верно подметили... один такой случайный заголовок (находящийся ПЕРЕД данными) -- напрочь вероятнее всего испортит всю идею.

    ...но яже так и написал: что нужно-додумать-всё-это :-)

    вдруг например случайные заголовки окажутся не такими уж и "случйными" %) %) %)... или ещё чтонибудь всплывёт..... :)

     

  • 1.29, Аноним (-), 11:38, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >только переход на новый протокол

    Ура! Давно пора.

     
  • 1.31, Аноним (-), 11:41, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем такие сложности?
    Headless webkit
    публичная точка доступа wifi
    репроксирование без ssl
    ...
    Profit.
    Намного проще.
     
     
  • 2.96, KOL (ok), 17:09, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >репроксирование без ssl

    Честно говоря не понял. Если удаленный узел принудительно перенаправляет соединение на https, то что Вы с этим будете делать?

     
     
  • 3.116, zerot (ok), 21:46, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    отвечая на ваш вопрос что делать можно - ну, тут в одной недетской конторе безоп... большой текст свёрнут, показать
     
     
  • 4.119, KOL (ok), 23:31, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > отвечая на ваш вопрос что делать можно
    > ...
    > похожую схему можно выстроить и от провайдера, обязав разместить в доверенных издателях
    > сертификат провайдера - например для личного кабинета

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

     
  • 4.139, Chief Security II (?), 15:39, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Но дальше оказывается, что этот издательский микрософтовый Какой онанизм В усл... большой текст свёрнут, показать
     

  • 1.32, Аноним (-), 11:42, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Разве возможность зашифровать данные, посмотреть результат шифрования и НЕ узнать ключ не является одним из правил криптографии? Или тут не об этом?
     
     
  • 2.42, Аноним (-), 12:29, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Разве возможность зашифровать данные, посмотреть результат шифрования и НЕ узнать ключ
    > не является одним из правил криптографии? Или тут не об этом?

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

     

  • 1.36, Yakov Markovitch (?), 11:50, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Тай Данг (Thai Duong) и Джулиано Риццо (Juliano Rizzo)

    Прошу прощения, но он не Тай Данг, а Тхай Дыонг. Поправьте, пожалуйста, если можно.

     
     
  • 2.110, fi (ok), 18:49, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Откуда такая информация? в языках от латинского в 'Th' 'h' не читается. И обычно звучит как 't', разве только в английском чуть по другому.  
     
     
  • 3.114, sndev (ok), 19:36, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    C каких пор китайский берет начало в латинском языке ? :D
     
     
  • 4.145, fi (ok), 12:45, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > C каких пор китайский берет начало в латинском языке ? :D

    А что "Thai" - это китайские иероглифы?

     
  • 3.120, Yakov Markovitch (?), 23:33, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Откуда такая информация? в языках от латинского в 'Th' 'h' не читается.
    > И обычно звучит как 't', разве только в английском чуть по
    > другому.

    Это даже не китайский - это вьетнамский. Он вьетнамец. Thái Dương.

     

  • 1.39, Stax (ok), 12:17, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES

    Так. А вот, например, если браузер и вебсервер новый (openssl больше какой-то версии), то SSL по умолчанию использует 256-ти битный Camellia, а не AES. Как данная атака к этому относится?

     
     
  • 2.50, Аноним (-), 13:20, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES
    > Так. А вот, например, если браузер и вебсервер новый (openssl больше какой-то
    > версии), то SSL по умолчанию использует 256-ти битный Camellia, а не
    > AES. Как данная атака к этому относится?

    Camellia патентована. И - где она повсеместно на серверах? А - самое главное - проблема не в шифрах, проблема В ПРОТОКОЛЕ. Компренде?


     
     
  • 3.98, Stax (ok), 17:12, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, любой сервер на текущей версии редхата/центоси/SL как минимум по умолчанию предлагает Camellia из апача ;)  А редхат обычно патентованные алгоритмы вырезает от греха подальше, вон ecc до сих пор в openssl выключена..

    То, что проблема в протоколе понятно; непонятно, какую роль тут играет шифр. Как я понял из описания, воссоздать блоки шифрования по контрольным меткам получается используя именно особенности AES.

     
     
  • 4.112, Аноним (-), 18:57, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот мне тоже это интересно, почему именно AES ? Зная алгоритм шифрования, исходные данные, и результат, подобрать можно только AES или это общая болезнь ? Существует ли такой алгоритм который не ломается относительно быстро если известны исходные данные и сам алгоритм ?
     

  • 1.44, Аноним (-), 12:59, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И всё равно неповоротливые задницы миллиардеров не пошевелятся, чтобы что-то изменить: их всё устраивает. HTML5 не хотят, каким образом повсеместно наступил Web 2.0 даже не знаю. Нужен пинок посильнее, вроде взлома ряда важных клиентов с последующей миграцией на другие способы обеспечения безопасности.
     
     
  • 2.53, Аноним (-), 13:21, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И всё равно неповоротливые задницы миллиардеров не пошевелятся, чтобы что-то изменить:
    > их всё устраивает. HTML5 не хотят, каким образом повсеместно наступил Web
    > 2.0 даже не знаю. Нужен пинок посильнее, вроде взлома ряда важных
    > клиентов с последующей миграцией на другие способы обеспечения безопасности.

    Ты притворяешься или и правда клиника? Сколько времени что-то становится стандартом де-факто? Сколько x500/x509 стандартом становились? Напомнить? И бабло вливалось лярдами, и движущая сила покруче RMS была. И что?

     
     
  • 3.111, fi (ok), 18:53, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Сколько x500/x509 стандартом становились? Напомнить? И бабло вливалось лярдами, и движущая  сила покруче RMS была. И что?

    Да его с самого начало нужно было закапать, что собственно и выразилось в выпуске light версии.

    зы. А если вспомнить сколько стандартов вообще умерло не родившись ... :)

    зы2. а HTML5 будет, он действительно нужен.

     

  • 1.54, Pentarh (?), 13:27, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть, обе вкладки будут юзать одну и туже SSL сессию. Яваскрипт будет отправлять в банк заведомо известные данные. Снифер будет видеть эти данные в зашифрованном виде, и зная их исходники, сможет подобрать ключ. Ы?
     
  • 1.55, Аноним (-), 14:05, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Абалдеть! :D Дяденьки открыли классический криптоанализ с возможностью генерации открытого текста. Только я недопонял, а salt-то хде?

    >JavaScript-код используется для отправки на сайт с которым работает жертва фиктивных запросов с изначально известными контрольными метками

     
     
  • 2.64, Аноним (-), 14:49, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Абалдеть! :D Дяденьки открыли классический криптоанализ с возможностью генерации открытого
    > текста. Только я недопонял, а salt-то хде?
    >>JavaScript-код используется для отправки на сайт с которым работает жертва фиктивных запросов с изначально известными контрольными метками

    Salt вычисляется по известному алгоритму. Курить матчасть до просветления.

     
     
  • 3.69, Аноним (-), 15:00, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Salt вычисляется
    А не берётся случайно?
     
     
  • 4.72, Кирилл (??), 15:04, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Salt вычисляется
    > А не берётся случайно?

    Случайного в компе, увы, нет.

     
     
  • 5.78, Xasd (ok), 15:33, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Случайного в компе, увы, нет.

    а у меня в компе есть (/dev/random и чуть-меннее-случайный /dev/urandom) ...

    ...сажите -- у меня волшебный комп? o_0

     
     
  • 6.83, Кирилл (??), 16:14, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Толку то, примесь вычисляется.
     
  • 6.103, Аноним (-), 17:21, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Случайного в компе, увы, нет.
    > а у меня в компе есть (/dev/random и чуть-меннее-случайный /dev/urandom) ...
    > ...сажите -- у меня волшебный комп? o_0

    Ты просто трындишь.

    /dev/random не является полноценным аппаратным рандомизатором. Или у тебя, анон, Sun SPARC выпуска 2001 года? В них - да, /dev/random хардверный.

     
     
  • 7.106, Xasd (ok), 17:32, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    зачем мне на домашнем компьютере (на котором установлен www-браузер с поддержкой TLS/SSL) аппаратный рандомайзер от Sun SPARC? :-)

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

     
  • 7.117, zerot (ok), 21:52, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/

    > /dev/random не является полноценным аппаратным рандомизатором. Или у тебя, анон, Sun SPARC
    > выпуска 2001 года? В них - да, /dev/random хардверный.

    ну, товарищ привёл неудачный пример
    а если так - в качестве демонстрации идеи ?
    tail -20 /var/log/maillog | md5sum
    думаю идея понятна - в компе вполне можно получить значение, которое будет практически случайным

     
     
  • 8.118, Аноним (-), 23:10, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну допустим получили, а как потом не зная этой соли на принимающей стороне расши... текст свёрнут, показать
     
     
  • 9.126, Кирилл (??), 11:16, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да никак Соль или Примесь задаётся заранее известным алгоритмом или из таблиц... текст свёрнут, показать
     
     
  • 10.133, Аноним (-), 14:19, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Отсыпь ... текст свёрнут, показать
     
  • 4.94, Аноним (-), 17:04, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >А не берётся случайно?

    man генератор псевдослучайных чисел

     

  • 1.68, Кирилл (??), 15:00, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В общем, если пользуетесь платежами по карточке, то держите открытым только одно окно в браузере.
     
     
  • 2.79, Xasd (ok), 15:37, 20/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В общем, если пользуетесь платежами по карточке, то держите открытым только одно
    > окно в браузере.

    именно! плюсую :-)

    а ещё с увелечением числа CSRF-уязвимостей в интернетах
             (причём авторы этих сайтов обычно не хотят верить что на их сайте есть CSRF-уязвимость, пока не сделаешь персонально-для-них эксплоит)
        -- вообще делаю вывод что в броузере должно быть открыто только одно окно с сайтом :-) [а потом ещё и кнопку выход недайбох забыть нажать!]

     
  • 2.132, XoRe (ok), 12:44, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В общем, если пользуетесь платежами по карточке, то держите открытым только одно
    > окно в браузере.

    Можно пользоваться каким-то одним браузером только для банка.
    Например, FF - для всего, Chrome - для банка.
    Или Chrome - для всего, какой-нибудь Safari - для банка.
    А если банк хочет только IE, то это только на руку всему миру - IE только для банка =)

     

  • 1.82, stimpack (?), 16:11, 20/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    платные (или собственные) vpn-аккаунты внезапно должны стать очень популярными.
     
  • 1.124, Аноним (-), 09:11, 21/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А для параноиков лучше ходить лично на рынок (там камер меньше) и покупать за наличку. Но при этом дома, обязательно, "держите открытым только одно окно в браузере". :)
     
     
  • 2.128, Michael Shigorin (ok), 11:46, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А для параноиков лучше ходить лично на рынок (там камер меньше)
    > и покупать за наличку.

    Так и делаем, плюс своё (в качестве дизель-генератора).

     

  • 1.129, Стас Агарков (?), 12:00, 21/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Используйте одноразовые пароли как в телебанке ВТБ24 и вам не будет страшен никакой перехват сессии.
     
     
  • 2.136, scor (ok), 14:39, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И как эти пароли защищают от MitM?:) Даже на википедии в первых строках:
    "Использование одноразовых паролей само по себе не защищает от атак, основанных на активном вмешательстве в канал связи, используемый для аутентификации"
     

  • 1.131, XoRe (ok), 12:41, 21/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Насчет сниффания - может и не нужно, если удастся похитрить с DNS.
    Подставить свой ip для домена сайт-банка.рф.
    Возможно, это реально сделать на JavaScript - работать с кешем DNS на машине клиента.

    Вообще для банка хорошо бы использовать Шифр Вернама (система одноразовых блокнотов) ( http://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%84 ).
    Сделать сайт банка, где статика грузится с одного домена (там простой tls, пусть ломают), а динамика, запросы, бабло, текст - с другого домена (там шифр вермана).
    Допустим, одна банковская операция занимает 1-10 кб текстового трафика.
    Допустим, в день делается 10 операций.
    Тогда в день будет тратиться 10-100 кб.
    Пусть даже 1 Мб трафика в день.
    При регистрации можно передать клиенту флешку с 2 гигами одноразовых паролей (1 гиг на шифрование передачи, 1 гиг на дешифрование приема).
    Этого должно хватить с головой на год-другой.
    И все, через интернет сие взломать не возможно, даже пустив весь банковский трафик через сниффер.

     
     
  • 2.135, Аноним (-), 14:28, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Вермана

    Да чего вы до него докапались-то?

    Хватит адекватной реализации любого сильного алгоритма шифрования, адекватного протокола и достаточной длины ключа.

     
     
  • 3.142, XoRe (ok), 03:00, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Вермана
    > Да чего вы до него докапались-то?
    > Хватит адекватной реализации любого сильного алгоритма шифрования, адекватного протокола
    > и достаточной длины ключа.

    А почему-бы и нет?
    Шифр не требователен к ресурсам проца.
    При текущих объемах жестких и флешек хранить пару гиг одноразовых данных - не проблема.
    А так пока видна гонка алгоритмов:
    - хаха! мы сделали алгоритм сложности 2 в степени n!
    - хаха! мы научились понижать степень на 2!
    - хаха! мы сделали такую большую n, что по барабану на ваши 2!
    - хаха! мы научились взламывать при любом n!

    А ещё видна гонка шифрующих/дешифрующих мощностей.
    Знаете, сколько раз winrar шифрует ключ?
    С другой стороны, знаете, сколько миллиардов паролей в секунду подбирает одна видеокарта?

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

     

  • 1.134, Макар Жук (?), 14:23, 21/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не понятно причём здесь недостатки протоколов, если взломаются сообщения зашифрованные по алгоритму AES
     
     
  • 2.137, Аноним (-), 14:39, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не понятно причём здесь недостатки протоколов, если взломаются сообщения зашифрованные
    > по алгоритму AES

    Я так понял, сообщения шифруются одним ключиком в течение всего сеанса или достаточного для проведения атаки времени. AES, вероятно, недостаточно стоек при возможности выбора открытых текстов и при данной (недостаточной?) длине ключа.

     
     
  • 3.138, Макар Жук (?), 15:12, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>недостаточно стоек при возможности выбора открытых текстов

    Я не думают что алгоритм не проверили на стойкость к этому виду атаки, прежде чем его сделали стандартом.

    >>при данной (недостаточной?) длине ключа.

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

     
     
  • 4.141, Аноним (-), 21:09, 21/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Надо детально смотреть, что и как они там "поломали". Честно, мне - лень. :D
     
  • 4.143, XoRe (ok), 03:05, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>>недостаточно стоек при возможности выбора открытых текстов
    > Я не думают что алгоритм не проверили на стойкость к этому виду
    > атаки, прежде чем его сделали стандартом.
    >>>при данной (недостаточной?) длине ключа.
    > Вообще то при такой длине ключа как 128-256 бит, сообщение не должно
    > быть расшифровано за 5-10 минут, иначе ключ не был бы пригоден
    > для защиты данных.

    Грубо говоря:
    Дано:
    - есть функция хеширования xor;
    - есть исходные данные;
    - есть результат хеширования;
    Вопрос:
    - за сколько можно узнать ключ хеширования?

    Правильно - мгновенно.
    исходник -> xor -> результат = ключ.
    Только в статье не xor, а aes.

     
     
  • 5.144, Макар Жук (?), 09:41, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Грубо говоря:
    > Дано:
    > - есть функция хеширования xor;
    > - есть исходные данные;
    > - есть результат хеширования;
    > Вопрос:
    > - за сколько можно узнать ключ хеширования?
    > Правильно - мгновенно.
    > исходник -> xor -> результат = ключ.
    > Только в статье не xor, а aes.

    Хеширование и шифрование это не одно и тоже, так что предложенный алгоритм не прокатит -)

     
     
  • 6.146, Аноним (-), 22:55, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И, битовая операция XOR (исключающее ИЛИ) - это тоже совсем не шифрование. ;)
     
     
  • 7.147, Аноним (-), 22:56, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И не хеширование.
     
     
  • 8.148, Аноним (-), 22:57, 22/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И когда уже эта фигня про xor-шифрование перестанет проникать в неокрепшие умы... текст свёрнут, показать
     
     
  • 9.150, XoRe (ok), 01:25, 23/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Шифр вернама как раз работает через xor И считается абсолютно стойким шифром ... текст свёрнут, показать
     
     
  • 10.152, Аноним (-), 12:34, 23/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Шифр Вернама работает через ключ гаммирования длины длине открытого текста Г... текст свёрнут, показать
     
     
  • 11.153, XoRe (ok), 02:13, 24/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да Нагенерить несколько гигов рандомных данных, обменяться этими гигами, и ш... текст свёрнут, показать
     
  • 8.149, XoRe (ok), 01:24, 23/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Все такие умные Знают правильные определения А подумать дальше определений - п... текст свёрнут, показать
     
     
  • 9.151, Аноним (-), 12:29, 23/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот в этом можно попробовать и есть вся соль ... текст свёрнут, показать
     
     
  • 10.154, XoRe (ok), 02:15, 24/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    AES уже попробовали Слава богу, что каждый протокол нужно взламывать в частном ... текст свёрнут, показать
     
     
  • 11.155, Аноним (-), 14:23, 24/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Разве тут что-то было про aes ... текст свёрнут, показать
     
     
  • 12.156, XoRe (ok), 16:20, 24/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    JavaScript-код используется для отправки на сайт, с которым работает жертва, фик... текст свёрнут, показать
     
     
  • 13.157, Аноним (-), 17:29, 24/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    E Уязвимость _в протоколе_ SSL AES вполне себе живой ... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру