Пользователь
–1,6
рейтинг
15 октября 2013 в 23:39

Разработка → Ослабленный SSL в android устройствах?


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

Итак, по словам автора приложения APRSdroid, начиная с Android 2.3 при установке SSL-соединения вместо использовавшейся ранее комбинации алгоритмов шифрования и хэширования AES256 и SHA1 первой стала предлагаться значительно более слабая комбинация из RC4 и MD5.
Почитать пост с описанием этого открытия вы можете по ссылке.
Оставляя за скобками мотивы разработчиков android установить приоритет именно для этих алгоритмов, я хочу рассказать чем плох RC4 в качестве основного метода шифрования и чем это чревато для SSL.

Уязвимость шифра RC4


RC4 является потоковым шифром, с внутренним состоянием состоящим из 256 элементов. Фактически, RC4 состоит из двух частей:

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

В дальнейшем сгенерированная гамма суммируется по модулю два с открытыми данными и получается шифротекст.
Важнейшим условием предъявляемым к потоковым шифрам является абсолютная неотличимость производимой ГПСЧ гаммы от случайной последовательности байт.
Проблема в том, что RC4 не соответствует этому условию.
Было установленно, что каждый из первых 256 байт выходной последовательности RC4 имеет отличную от 1/256 вероятность оказаться равным нулю.
Это означает следующее. Предположим злоумышленник смог собрать достаточно большое количество одного и того же сообщения длиной 256 байт, зашифрованного различными ключами. Т.к. вероятность того, что каждый из 256 байт гаммы, используемой для шифрования, равен нулю выше среднего показателя 1/256, атакующий может проверить каждый байт всех имеющихся шифротекстов и с большой долей успеха предположить, что наиболее часто встречающийся байт и является исходным. Раскрывая байт за байтом атакующий сможет раскрыть все сообщение целиком.

Протокол записи SSL


Теперь поговорим о том насколько это все применимо к SSL.
Итак, после того как в результате протокола рукопожатия будет сформирован сеансовый ключ весь дальнейший трафик будет шифроваться с помощью RC4.
Первым шифруемым RC4 сообщением является блок данных называемый Finished. Finished служит для подтверждения установления связи. Он состоит из 36 байт, генерируемых каждый раз по новому. Соответственно для атакующего расшифровка этого блока не представляется возможной.
В итоге остается 220 байт полезной информации, которую можно раскрыть с помощью данной атаки. И это плохая новость, т.к. этого вполне достаточно чтобы восстановить ваш пароль или cookies.

К счастью, есть и хорошая. На сегодняшний день атака трудно реализуема на практике. Как я уже писал для вскрытия нужно собрать большое количество одного и того же зашифрованного текста. Создатели атаки утверждают, что для восстановления 80 байт из 256 необходимо 226 шифротекстов. Для вскрытия всего блока длиной 256 байт, понадобится 232.
Впервые успешную атаку на эту уязвимость удалось осуществить в марте 2013 года. Поэтому, можно сказать, что это очень новый и весьма перспективный тип атак, который весьма вероятно уже скоро будет усовершенствован.

В заключение я бы хотел вставить несколько слов обо всей этой ситуации которая сложилась вокруг протокола SSL в последнее время. Честно говоря, меня это все несколько удивляет. Криптография за последние годы очень сильно продвинулась вперед. Новый стандарт SHA-3 неотличим от случайного оракула. Разрабатываются асимметричные криптосистемы стойкие к атакам на квантовых компьютерах. Появляются режимы шифрования гарантирующие как аутентификацию так и конфиденциальность сообщения. Но при всем при этом мы до сих пор пользуемся протоколом 14 летней давности. Может быть пришло время попробовать что-нибудь поновее? В противном случае нас все чаще будут «радовать» заголовки о том, что кто-то, где-то использует ослабленный вариант SSL.

Ссылки


Краткое описание атаки.
Брюс Шнайер об атаке.
Подробное описание(pdf)
Алексей @NeverWalkAloner
карма
178,7
рейтинг –1,6
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (25)

  • –7
    Может, дело в том, что они так решили позаботиться о производительности на мобильных-то устройствах?
    • +2
      А до версии 2.3 они об этом значит не заботились?
      В любом случае, пост не об этом, а о самом протоколе SSL и одной из его множества уязвимостей.
      • 0
        А до версии 2.3 они об этом значит не заботились?

        Ну, не всё же сразу.
    • +37
      Или PRISM решил позаботиться о производительности своих вычислительных центров и приложил лапу.
    • +15
      Это первый комент на HN кстати!

      There's interesting technical content here, but it suffers from its alarmist tone.
      The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them both). Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken.

      RC4 is horribly broken, and is horribly broken in ways that are meaningful to TLS. But the magnitude of RC4's brokenness wasn't appreciated until last year, and up until then, RC4 was a common recommendation for resolving both the SSL3/TLS1.0 BEAST attack and the TLS «Lucky 13» M-t-E attack. That's because RC4 is the only widely-supported stream cipher in TLS. Moreover, RC4 was considered the most computationally efficient way to get TLS deployed, which 5-6 years ago might have been make-or-break for some TLS deployments.

      You should worry about RC4 in TLS — but not that much: the attack is noisy and extremely time consuming. You should not be alarmed by MD5 in TLS, although getting rid of it is one of many good reasons to drive adoption of TLS 1.2.

      И ответ:

      There is another technical angle; RC4 is usually quite a lot less CPU intensive than the alternatives available. Not using RC4 can easily mean stuttering video playback, greatly diminished battery life, and even lock ups. Very few users are open to accepting that issues like that are «better» for them.
      Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded devices (think TVs, Cars and phones) with comparatively weak CPUs.
      • 0
        Значит не я один так сначала подумал :)
    • +1
      Речь не о производительности, а о совместимости, о чём, о боги, собственно и повествует статья по ссылке.

      Что как бы и отвечает на вопрос: почему при всем при этом мы до сих пор пользуемся протоколом 14 летней давности — потому, что софт обновляется небыстро!

      Более осмысленный список cipher'ов появился в Java7 совсем «недавно» (всего-то пару лет назад), так что Android его её не подхватил. Я думаю ещё несколько лет пройдёт и список обновится (ну там ещё пара лет уйдёт на то, чтобы все телефоны перешли на эту новую версию), так что без паники.
      • 0
        Каюсь, статью по ссылке не читал.
  • +3
    По ссылке и по ссылке по ссылке:

    1) Проблема касается не «самых новых андроидов», а практически всех андроидов, т.к. в статье идёт речь про android > 2.3, то есть, читай, всех современных.
    2) Багофича была добавлена во имя совместимости с оракловской реализацией в яве.
    • 0
      Про «новые» погорячился я конечно.
      Про смысл фичи тут много вариантов. Вот vittore а своем комментарии приводит достаточно правдоподобное объяснение.
      • 0
        Вообще-то как указывает статья, которую вы, вроде как, обсуждаете, сами разработчики Android'а пишут ясно и недвусмысленно:
        — We now have a well defined list of the supported cipher suites which are sorted in priority order as specified in JSSE documentation so that callers doing: s.setEnabledCipherSuites(s.getSupportedCipherSuites()) will get something reasonable.
        — We now have a default cipher suite list that is chose to match RI behavior and priority, not based on OpenSSLs default and priorities.

        Так что рассказы про какой-то «особенно ослабленный SSL в Android'е» выглядят дико на фоне того, что ровно этот список использовался (и используется!) тучей серверного софта (далеко не все ещё перешли на Java7 на серверах, поверьте).
        • +3
          Ну почему же дико? Оттого что этот же список использует другой софт уязвимость не становится менее опасной. Я вообще прошу абстрагироваться от конкретных решений. Android не более чем иллюстрацию того, что пора проститься уже с TLS 1.0.
  • +2
    Слово «новых» наверно нужно либо убрать либо взять в кавычки, ибо если я правильно понял то коммиту уже три года :)

    Что показательно, не смотря на open source, это вскрылось так же как вскрылось бы и в закрытом софте — через анализ трафика, что на мой взгляд достаточно забавно

    • +1
      Да как то забавно выглядело согласен. Чуть чуть откоректировал заголовок. Стало еще «желтее»:)
  • +2
    Серверный список шифров имеет приоритет над клиентскими, разве нет? По крайней мере в каждом первом гайде по настройке ssl советуется выставлять prefer server ciphers.
    • +3
      У меня debug логи ssl в nginx включены, поискал android клиентов, видны строки типа «ECDHE-RSA-AES256-SHA returns» и значение хэш функций, явно длиннее MD5 (что именно точно значит написанное в логах — не берусь утверждать).
      MD5, RC4 вообще нет. AES, SHA — есть. Так же все запросы TLS 1.2 или 1.1, в статье же идёт речь про 1.0,
      Есть так же коммент к статье «RC4 is the recommended cipher for TLS 1.0»

    • +1
      Не совсем.
      Клиент присылает список (более предпочтительные идут первыми), сервер выбирает. Я навскидку не нашел в стандарте рекомендаций для сервера, как, собственно, выбирать.
      • +1
        Возможно эта статья поможет community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

        Примеры конфигов
        Apache

        SSLProtocol all -SSLv2 -SSLv3
        SSLHonorCipherOrder on
        SSLCipherSuite «EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
        EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
        EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS»

        Nginx

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers «EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
        EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
        EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS»;


        Думаю TLSv1 TLSv1.1 тоже надо выключать.
  • +7
    TLS 1.0/1.1 уязвим к BEAST, а использование RC4 рекомендовалось как решение.
    • +1
      Если ничего не путаю, то Android 2.3 был выпущен примерно 6 декабря 2010, а PoC на BEAST показан 23 сентября 2011.
  • +2
    Не совсем верное утверждение, что «Новый стандарт SHA-3 неотличим от случайного оракула». это Sponge схема неотличима при идеальной F, а вот про саму F у них никто такого не доказал )
    • –4
      Дьявол кроется в деталях:) Хотя ты прав конечно.
      Как там фортуна кстати, не решился еще?
      • –3
        не, пока диплом пишу )
  • +1
    А что там на цианогене? И можно ли закрыть багофичу патчем?

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