Разработчики Firefox проанализировали (https://blog.mozilla.com/security/2011/09/27/attack-against-.../) подверженность браузера недавно анонсированному (http://www.opennet.me/opennews/art.shtml?num=31797) методу атаки против SSL/TLS, позволяющему на промежуточном шлюзе организовать перехват передаваемого в рамках зашифрованного соединения Cookie с параметрами аутентификации пользовательской сессии. В итоге, был сделан вывод, что несмотря на использование TLS 1.0, Firefox не подвержен данной проблеме, так как без задействования дополнительных плагинов невозможно обеспечить необходимые для проведения атаки условия (полный контроль за содержимым соединения). Тем не менее, сообщается, что атака теоретически может быть совершена в случае наличия у пользователя Java-плагина. Поэтому в настоящее время разработчики рассматривают возможность отключения Java-плагина для существующих установок.Разработчики проекта Tor также опубликовали заметку (https://blog.torpr...
URL: https://blog.mozilla.com/security/2011/09/27/attack-against-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=31883
> и применяет шифр RC4...у которого своих проблем хватает, как то утечка ключевого материала в начальных байтах потока. По поводу чего RC4 не советуют в новых дизайнах а тем где он нужен - советуют скипнуть первые 1024 байта от его PRNG генератора, и ксорить уже с дальнейшим выводом оного - тогда проблема не возникает. Торент кстати так и делает, честно скипая. А в SSL до этого скипания 1024 не-совсем-рандомных байтов доперли? А то вроде его разрабатывали еще до того как утечка ключевых байтов была засечена.
Это называеться RC4-drop[n] (MARC4) и уже давно применяеться..
> Поэтому в настоящее время разработчики рассматривают возможность отключения Java-плагина для существующих установок.Давно пора лишний вектор атаки убрать по умолчанию.
печалька: интернет-банкинг всех^Wнекоторых банков живет аккуратно на java-плагине
да......только точка наложения печальки -- здесь именно в том что эти банки реализованны на Java-плугине (а не в том что Java-плугин подвержен какойто-там *очередной* уязвимости...)
так как тут уж особого секрета нет что постоянно в этих плугинах находят те-или-иные дыры :-) , тоже мне новость :-)
установил [какойнибудь] плугин(?) -- получи новую дыру :-D
# p.s.: а некоторые банк-клиенты так вообще работают как native-приложения... для Microsoft Windows.... так чтож теперь -- начнём обсуждать безопасность Windows-компьютеров? :-) :-) все помнят неособо-давний случай когда нашли дыру в обработчике-значков-ярлыков, когда принеся ярлычок на флэшке можно было заразить комп (или засунув ярлык внутрь Microsoft-Word-документа, как какойто-там-встроенный-объект)?
"Если бы строители строили свои здания, как программисты пишут свои программы, первый залетевший дятел разрушил бы цивилизацию". (С)
>"Если бы строители строили свои здания, как программисты пишут свои программы, первый
>залетевший дятел разрушил бы цивилизацию". (С)Хватит уже с этим шаблоном всех мазать. Не все программисты одинаковые и не весь софт плохой. (Далее должен последовать ответ от любителей "жить просто": "Всех грести под одну гребенку удобнее, чем рассматривать много случаев."
В крайнем случае (и вообще-то так правильней) можно завести отдельный профиль или даже браузер для работы с банком. Java не столь вотстребована, что б с ней ходить по всем сайтам.
> печалька: интернет-банкинг всех^Wнекоторых банков живет аккуратно на java-плагинеЭто ещё хорошие банки. У некоторых интернет-банкинг до сих пор живёт на ActiveX…
Завести второй профиль с включенной явой и использовать его ТОЛЬКО для работы с банком - это, конечно, невозможно.
при чем тут второй профиль, если нужно безопасное соединение с банком? рано или поздно откроешь случайно стороннюю страничку не в том браузере и привет.
прийти ногами в банк понадежнее будет
Вдруг тебе денег фальшивых дадут в банке? Натуральный обмен надёжнее будет...
> Вдруг тебе денег фальшивых дадут в банке? Натуральный обмен надёжнее будет...а если тушёнка просроченая?
это хорошо, если тушенкой брать, а то можно и по вен-диспансерам набегаться
хм. то есть, криптографически более сложный (и стойкий) метод на эллиптических кривых заменяют на намного более простой RC4 — и ОПА! внизапна, улучшается секурность.только я вижу в этом какую-то на…ку?
> ...более сложный (и стойкий) метод на эллиптических кривых...это вы про AES Rijndael? %) :-)
...вообщето алгоритм AES Rijndael -- это шифр простой с алгебраической структоруй... что кстате говоря ставит под сомнение его безопасность :-)
но что касается темы-новости -- то думаю тут всё дело в CBC-режиме-шифрования (реализованном несовсем правильно), а не в самом шифре
>> …более сложный (и стойкий) метод на эллиптических кривых…
> это вы про AES Rijndael? %) :-)
> …вообщето алгоритм AES Rijndael — это шифр простой с алгебраической структоруй…хм. кажется, да — меня проглючило.
не очень понятно:
> частности, в Tor применяются дополнительные методы рандомизации, а именно
> используется возможность библиотеки OpenSSL по вставке пустых фрагментов перед
> отправкой каждой записи.
> достаточно добавить пустой блок перед каждой передаваемой порцией данных, что
> создаст необходимый уровень рандомизации, достаточный для того чтобы атака
> оказалась неэффективной. Добавив в один из выпусков Chrome тестовый код для
> оценки работы данного метода, разработчики пришли к выводу, что к сожалению его
> использовать нельзя,у разработчиков тора и хрома разное содержимое пустых блоков? :)
Нет, разные методы рандомизации пустых блоков.