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
Тип: Интересно / Проблемы безопасности
Ключевые слова: ssl, tls, security, sniffer, attack
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (147) Ajax/Линейный | Раскрыть все сообщения | 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. Провернуть подобное, в масштабах всей сети, могут 3 человека. Провернуть подобное, в масштабах одного/нескольких домов, могут около 30 человек подрядчика, занимающиеся монтажом оптики и свичей в домах. Огромное количество народа может зайти на чердак, врезать в витую пару точку доступа wi-fi и получать информацию из интересующей квартиры.
     
  • 8.63, Аноним (-), 14:48, 20/09/2011 [^] [ответить]    [к модератору]  
  • +/
    > Цена вопроса - пятсот баксов сисадмину провайдера. И все. Продаются все. Вопрос лишь в цене.

    А также:
    1) Фиктивная точка доступа.
    2) Флуд свичей и спуфинг
    3) Просто наглейший MITM.

    Даже нахаляву можно проскочить.

     
  • 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 +/
    Вы уверены, что когда мне нужно будет провести банковскую транзакцию или для чего то другого воспользоваться SSL, я пойду в публичное заведение пользоваться бесплатным WiFi.

    Вопрос насколько сложно воспользоваться этой уязвимостью в реальных условиях.

     
     
  • 9.88, Аноним (-), 16:45, 20/09/2011 [^] [ответить]    [к модератору]  
  • +/
    > Вы уверены, что когда мне нужно будет провести банковскую транзакцию или для
    > чего то другого воспользоваться SSL, я пойду в публичное заведение пользоваться
    > бесплатным WiFi.

    С развитием online-банкинга уже типично перед покупкой залезть со смартфона/планшета и проверить сколько денег лежит на карте и при необходимости докинуть с отдельного счета. WebMoney и ЯндексДеньги тоже многие с телефонов пользуются.

     
  • 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 [^] [ответить]    [к модератору]  
  • +/
    >> С какого перепуга жертва ломанется на твой WiFi?
    > Не ломанется на WiFi так кабель в подьезде/подвале/люке разрезать не долго

    Повторяю для тех, кто на бронепоезде. Все зависит от ЦЕНЫ ВОПРОСА. "За червонец потийский полицмейстер разденется" (С). Не я сказал. И кабель разрежут, и ТД поставят и на криминал любой пойдут. Цена вопроса.

     
  • 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 +/
    > кастую TLSv2.

    Уже есть TLS 1.1+:

    https://secure.wikimedia.org/wikipedia/en/wiki/Transport_Layer_Security#TLS_1.

    "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_ssl_encryption/

    В том числе:

    http://www.mail-archive.com/openssl-dev@openssl.org/msg10664.html

    2002-й год, проблема с IV уже была известна.

    (Но новость серьезная - одно дело кусочек теории, а другое - практически продемонстрированная атака на реальные веб-сайты.)

     
  • 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 [^] [ответить]    [к модератору]  
  • +/
    > отвечая на ваш вопрос что делать можно

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

    Какой онанизм! В условиях конторы на комп пользователя политиками ставится кейлогер, типа Employee Monitor, коих чуть больше чем много. Есть под все платформы. Заодно они еще и зарплату считают.

     
  • 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-шифрование" перестанет проникать в неокрепшие умы?

    Шифр вернама как раз работает через xor.
    И считается абсолютно стойким шифром.

     
     
  • 10.152, Аноним (-), 12:34, 23/09/2011 [^] [ответить]    [к модератору]  
  • +/
    > Шифр вернама как раз работает через xor.
    > И считается абсолютно стойким шифром.

    Шифр Вернама работает через ключ гаммирования длины == длине открытого текста. Гамму можно класть хоть xor-ом (сложение под mod 2), хоть по любому другому модулю, например, для англ. алфавита по mod 26 (или сколько там букв? :D), хоть любым другим раком.

     
     
  • 11.153, XoRe (ok), 02:13, 24/09/2011 [^] [ответить]    [к модератору]  
  • +/
    >> Шифр вернама как раз работает через xor.
    >> И считается абсолютно стойким шифром.
    > Шифр Вернама работает через ключ гаммирования длины == длине открытого текста. Гамму
    > можно класть хоть xor-ом (сложение под mod 2), хоть по любому
    > другому модулю, например, для англ. алфавита по mod 26 (или сколько
    > там букв? :D), хоть любым другим раком.

    Ну да.
    Нагенерить несколько гигов рандомных данных, обменяться этими гигами, и шифровать)
    И ведь не расшифровать, даже вклинившись.

     
  • 8.149, XoRe (ok), 01:24, 23/09/2011 [^] [ответить]    [к модератору]  
  • +/
    > И не хеширование.

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

     
     
  • 9.151, Аноним (-), 12:29, 23/09/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    >Вопрос:
    >- за сколько можно узнать ключ хеширования?
    >Правильно - мгновенно.
    >можно попробовать
    > подобрать

    Вот в этом "можно попробовать" и есть вся соль.

     
     
  • 10.154, XoRe (ok), 02:15, 24/09/2011 [^] [ответить]    [к модератору]  
  • +/
    >>Вопрос:
    >>- за сколько можно узнать ключ хеширования?
    >>Правильно - мгновенно.
    >>можно попробовать
    >> подобрать
    > Вот в этом "можно попробовать" и есть вся соль.

    AES уже попробовали.
    Слава богу, что каждый протокол нужно взламывать в частном порядке, и достаточно просто перейти на TLS 1.1/1.2.

     
     
  • 11.155, Аноним (-), 14:23, 24/09/2011 [^] [ответить]    [к модератору]  
  • +/
    > AES уже попробовали.

    Разве тут что-то было про aes?

     
     
  • 12.156, XoRe (ok), 16:20, 24/09/2011 [^] [ответить]    [к модератору]  
  • +/
    >> AES уже попробовали.
    > Разве тут что-то было про aes?

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

    Вы читали новость?

     
     
  • 13.157, Аноним (-), 17:29, 24/09/2011 [^] [ответить]    [к модератору]  
  • +/
    >>> AES уже попробовали.

    :E Уязвимость _в протоколе_ SSL. AES вполне себе живой. ;)

     

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


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