Исследователи из французского института INRIA (https://ru.wikipedia.org/wiki/INRIA) разработали новый метод атак на системы шифрования, применяющие 64-битные блочные шифры 3DES и Blowfish, получивший кодовое имя Sweet32 (https://sweet32.info/). Метод позволяет в ходе MITM-атаки, подразумевающей наличие контроля за транзитным трафиком, восстановить значение небольших идентификаторов, передаваемых внутри шифрованного сеанса, например сессионных Cookie в HTTPS-соединениях. Метод также применим для восстановления аутентификационных токенов OpenVPN (используется Blowfish). Для защиты от выявленного метода атаки рекомендуется использовать шифры с размером блока, превышающим 64 бита, например, AES.
Для успешного совершения атаки сайт должен поддерживать создание защищённых соединений с использованием симметричного блочного шифра 3DES, а также допускать передачу большого числа запросов через одно установленное соединение. По оценке исследователей данному условию соответствуют 0.6% от 100 тысяч самых популярных сайтов в рейтинге Alexa. Для применения атаки также требуется чтобы клиент подключился с использованием 3DES (используется примерно 1-2% клиентских запросов), после чего атакующему необходимо добиться выполнения JavaScript-кода в браузере клиента.
Так как атака подразумевает наличие возможности перехвата трафика клиента, для выполнения JavaSсript-кода атакующий может подставить его при запросе клиентом незащищённого ресурса. JavaSсript-код нужен для отправки проверочных запросов на целевой сайт, которые отслеживаются в перехваченном трафике (данные запросов известны за исключением скрытого идентификатора сеанса в Cookie). Для успешной расшифровки Cookie в HTTPS в ходе эксперимента потребовалось 38 часов и отправка 785 Гб проверочных данных. Для восстановления 16-байтного аутентификационного токена в OpenVPN потребовалось 18 часов и генерация 705 Гб данных.
Метод основан (https://sweet32.info/SWEET32_CCS16.pdf) на применении описанного в теории вероятности парадокса дней рождений (https://ru.wikipedia.org/wiki/%D0%9F%D0%... для поиска коллизий. Генерируя большую последовательность запросов оценивается появление двух одинаковых результирующих зашифрованных блоков, свидетельствующих об обнаружении коллизии. Учитывая то, что вызвавший коллизию запрос изначально известен, а в режиме CBC применяется XOR-наложение двух различных блоков, для воссоздания ключа шифрования требуется выявление нескольких коллизий.Несмотря не то, что атака требует достаточно специфичных условий и мало применима на практике, выявление проблемы уже подтолкнуло разработчиков средств шифрования для перевода 64-битных шифров в разряд устаревших. В частности, уже выпущен OpenVPN 2.3.12 (https://www.mail-archive.com/openvpn-announce@lists.sou... в котором прекращено применение 64-битных шифров. В ожидаемом на днях релизе OpenSSL 1.1.0 проблему планируется решить путём отключения 3DES. В ветках OpenSSL 1.0.2 и 1.0.1 для сохранения совместимости 3DES будет оставлен, но переведён в менее приоритетную группу (из high в medium).
URL: http://arstechnica.com/security/2016/08/new-attack-can-pluck.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=45023
>Для успешной расшифровки Cookie в HTTPS в ходе эксперимента потребовалось 38 часов и отправка 785 Гб проверочных данных. Для восстановления 16-байтного аутентификационного токена в OpenVPN потребовалось 18 часов и генерация 705 Гб данныхНЕЗАМЕТНЕНЬКО!
18 часов - реально не проблема. Припарковался где-нибудь рядом с офисом жертвы или хороший смартфон с хорошим powerbank-ом в заныкал и на следующий день готово. Траффик для современных локальных сетей тоже не проблема.
Да. Совсем не проблема.700 гигабайт за 18 часов. это около 90 мегабит в секунду.
никто не заметит.
> 700 гигабайт за 18 часов. это около 90 мегабит в секунду.мое 4G железо дает 150. При этом, если бы мы не были связаны всякими идиотскими ограничениями - оно бы было реально доступно обычным владельцам обычных китайских мабил.
Инфраструктура выдержит, она под такое строилась, китайская мабила - вполне осилит (правда, сядет наверное, за 18 часов, но это лечится павербанкой).и это - серийное оборудование, устаревшее уже лет на пять. Китайцам доступны скорости и в 300 мегабит (правда, в виду их количества, вряд ли оно все не упирается в магистрали).
Но я бы больше боялся не китайской мобилы, а человечка засланного, внутри корпоративной вафли. Опять же, современное железо да, вполне может обеспечить те самые 300 мегабит, и да, "никто не заметит", если специально не контролирует аномалии в сети.
А заметит, так пожмет плечами "наверное, это бэкап"(c).
> 700 гигабайт за 18 часов. это около 90 мегабит в секунду.Машины не торопятся - у них времени много.
Слить семьсот-восемьсот гигов трафика, чтобы выковырять 16 байт... :-) Провайдер раньше позвонит узнать, как дела. ;-)
> 3DES будет оставлен, но переведён в менее приоритетную группу (из high в medium)Почему не low?
Не прогнулись перед рабами и клиентами.
Не стоит прогибаться ПОД изменчивый мир...
Сорь, не удержался.
Ну, вместо BlowFish уже давно рекомендован TwoFish.
> атака требует достаточно специфичных условий и мало применима на практикеНу и что, зато у этой атаки есть красивое название, домен и логотип — все как положено.
ага, не хватает только выхода на IPO
>>> атака требует достаточно специфичных условий и мало применима на практике
>> Ну и что, зато у этой атаки есть красивое название, домен и логотип — все как положено.
> ага, не хватает только выхода на IPOКстати, да -- надо ж вВВП хоть так подымать.
гост89 тоже имеет блоки по 64 бита.
Ты говоришь про Магму, но уже давно нужно использовать Кузнечик: https://ru.wikipedia.org/wiki/%D0%9A%D1%...
Да, с кузнечиком будет проблематично отправить полтерабайта, он же тормозной как мой трактор.
> Да, с кузнечиком будет проблематично отправить полтерабайта, он же тормозной как мой
> трактор.Хз, не пробовал его имплементировать.
Может на sse/axv он будет вполне сносно пахать.
>> Да, с кузнечиком будет проблематично отправить полтерабайта, он же тормозной как мой
>> трактор.
> Хз, не пробовал его имплементировать.
> Может на sse/axv он будет вполне сносно пахать.Да точно также как старый гост -- никак. Там каждое следующие вычисление зависит от результата предидущего, нечего там параллелить. Разве что несколько отдельных потоков шифрования, как это делали для старого госта.
магма от гост89 отличается только порядком следования байт в блоке 64 бита.
Нахера это было делать я не понимаю, авторы ничего объяснить не могут или не хотят, мучал их ещё этой зимой, после НГ.
> метод атак на системы шифрования, применяющие 64-битные блочные шифры 3DES и BlowfishВау, какие новости. Ребятки взяли топовые и самые актуальные алгоритмы шифрования. Может ещё шифр Цезаря попробуют взломать, в 2016-ом году-то?
Хотя не, сарказм тут не к месту. Передаю привет всем цисководам, у которых для IPsec-а до сих пор стоит 3DES с MD5. Судя по новости, атака их не затрагивает, но им в любом случае стоит обновить настройки шифрования.
Это они так забивали ентепрайзеров, из-за обратной совместимости
Кто сказал, что Cisco не затрагивает? Может просто пока не экспериментировали со взломом конкретно их.
Да. Цисковкие должны уже давно призадуматься о смене шифрования!