В различных реализациях протоколов SSL, TLS и DTLS, в том числе в OpenSSL, GnuTLS, PolarSSL, OpenJDK, CyaSSL, MatrixSSL, yaSSL и NSS, обнаружена (http://arstechnica.com/security/2013/02/lucky-thirteen-attac.../) возможность совершения атаки (http://www.isg.rhul.ac.uk/tls/), позволяющей в процессе длительного перебора восстановить содержимое предсказуемых отрывков контента, передаваемого внутри отдельных блоков защищённого соединения. В целом атака достаточно труднореализуема, но интересна своим подходом к решению задачи.
Суть метода сводится к тому, что вначале осуществляется перехват зашифрованных блоков, после чего, используя известные проблемы TLS-режима CBC (Cipher Block Chaining), атакующий заменяет несколько последних блоков на подставные блоки, отправляет изменённую перехваченную последовательность и измеряет время реакции сервера. Проблемные реализации SSL отличаются тем, что преданный атакующим зашифрованный блок обрабатывается заметно быстрее, если он заполнен корректно (корректное padding-заполнение, используемое для выравнивания зашифрованного блока по границе 8 или 16 байт, определяется быстрее). TLS после каждой неудачи разрывает соединение и требует создания новой сессии.
Таким образом атакущий может организовать отправку большого числа пробных TLS-сообщений, накапливая статистику о времени ответа сервера на каждый запрос. В конечном счёте с определённой вероятностью можно понять (http://nmav.gnutls.org/2013/02/time-is-money-for-cbc-ciphers...), что попытка подбора оказались успешной. С практической стороны атака может применяться для восстановления содержимого значения аутентификационной Сookie или других небольших предсказуемых данных.Для успеха подбора аутентификационной Сookie типового сайта требуется отправка колоссального числа пробных запросов (нужно создать порядка <small>2<sup>23</sup></small> сессий), что придаёт атаке в основном умозрительный характер. Тем не менее, чем более предсказуемо содержимое, тем меньше попыток требуется, например, если используется BASE64-кодирование, то число попыток уменьшается до <small>2<sup>19</sup></small>, а если содержимое байта в последних двух позициях блока заранее известно - <small>2<sup>13</sup></small>. Для увеличения эффективности атаки до <small>2<sup>13</sup></small> также предлагается использовать элементы несколько лет назад представленной техники BEAST (http://www.opennet.me/opennews/art.shtml?num=31797), основанной на использовании JavaScript-кода в браузере жертвы для генерации блоков с заранее известным содержимым.
В настоящее время проблема уже устранена в OpenSSL (http://www.openssl.org/news/secadv_20130205.txt) (1.0.1d, 1.0.0k и 0.9.8y), GnuTTL (http://gnutls.org/security.html#GNUTLS-SA-2013-1) (3.1.7, 3.0.28 и 2.12.23), PolarSSL 1.2.5 (https://polarssl.org/tech-updates/releases/polarssl-1.2.5-re...), CyaSSL 2.5.0 (http://www.yassl.com/yaSSL/Docs-cyassl-changelog.html), MatrixSSL 3.4.1 (http://matrixssl.org/news.html) и в браузере Opera 12.13.URL: http://arstechnica.com/security/2013/02/lucky-thirteen-attac.../
Новость: http://www.opennet.me/opennews/art.shtml?num=36056
Угадать нужно значение аутентификационной Сookie, а не размер. Как в этом поможет выравнивание?
Не понятно другое, что время ответа реального сервера,
мало зависит от данных, но пропорционально его загруженности.Для российских провайдеров, особенно МТС, это техника ваще бесполезна,
ибо искать закономерность в хаосе с задержками - нереально.
> Не понятно другое, что время ответа реального сервера,
> мало зависит от данных, но пропорционально его загруженности.
> Для российских провайдеров, особенно МТС, это техника ваще бесполезна,
> ибо искать закономерность в хаосе с задержками - нереально.Тащемта, цель МТС - телефония, а не провайдерство тырнета.
> Тащемта, цель МТС - телефония, а не провайдерство тырнета.Из любопытства хотябы на их сайт зашёл, в услуги посмотрел.
МТС никого не спросив купила МТУ-Информ, а с ним и пару мильонов
юзеров ADSL-,Ethernet-сетей. Подсосала под себя Комстар с юзерами WiMax,
и там же кормится МГТС. Объединилаи всех в один канал, включая старых
мобильных и теперь связь стала полное говно. Потомуша у мобильного
трафика приоритет больше, качают раз в 100 меньше, при этом стоит
в три раза дешевле. (или в 30 раз дороже).
>проблема уже устраненаТ.е проблема не существует, но её уже побороли?
Одна (практическая) половина моей шизофренической личности говорит, что код был бесполезно усложнён, а другая (параноидальная) половина говорит: "Грр... У-у-у!...Бр-бр-бр..."
Да, я вот тоже думаю... Если проблема состояла в том, что неправильные данные обрабатываются дольше чем правильные... они ускорили обработку неправильных или замедлили обработку правильных? :)
Мне кажется, что это не так уж и важно.
2^13 это много. Это неимоверно много. Так что эта так называемая "атака" представляет лишь академический интерес. Вряд ли какая-либо сессия будет длиться дольше, чем будет собираться статистика из как минимум 2^13 запросов.
Я считаю, что в ответ на подобные изыскания разработчики библиотек должны были бы лишь улыбнуться и заняться чем-то более полезным.
Я так и знал, они тормознули крутейший memcmp! Теперь он при совпадении и при несовпадении работает с одинаковой скоростью.При запросах через сеть - может быть и много, а перебором - раз плюнуть. Подходы можно разные найти.
8192 это много ???
>8192Тьфу ты. Пишу одно, думаю другое...
Я на изначальные 2^23 смотрел.А так да. 8192 пакетов не так уж и мало, но ничего особенного.
2^13 это всего лишь 8192. А это очень мало.
Неправильные данные обрабатывались быстрее, что есть логично :)
md5 тоже когдато был трудноломаем
> md5 тоже когдато был трудноломаемЭто было давно и неправда.
это известный тип проблем. она сродни взлома кода на смарткартах анализируя ток потребления. Также можно получать информацию смотря на cachemiss, если имееш логин на сайте.поправят
> это известный тип проблем. она сродни взлома кода на смарткартах анализируя ток
> потребления. Также можно получать информацию смотря на cachemiss, если имееш логин
> на сайте.
> поправятВеликий и могучий, о русский языка. А по каковски-это?