Пользователь
0,0
рейтинг
21 сентября 2011 в 00:17

Разработка → Хакеры взломали SSL шифрование, используемое миллионами сайтов перевод

Исследователи обнаружили серьёзную слабость практически во всех сайтах, защищенных Secure Sockets Layer протоколом, которая позволяет злоумышленнику молча расшифровать данные, которые проходят между веб-сервером и браузером пользователя.

Уязвимость находится в версии 1.0, ранних версиях TLS и на транспортном уровне безопасности. Версии TLS 1.1 и 1.2 не восприимчивы к уязвимости, однако они почти не используются, что делает такие сайты как PayPal, GMail и множество других уязвимыми, если злоумышленник имеет возможность контролировать связь между пользователем и конечным сайтом.

На «Ekoparty security conference» в Буэнос-Айресе в конце недели, исследователи Thai Duong и Juliano Rizzo планируют продемонстрировать доказательства их концепции, которую они назвали BEAST (в переводе — зверь) от первых букв следующих слов Browser Exploit Against SSL/TLS.

Duong сказал, что на демонстрации будет показана расшифровка cookie для доступа к PayPal аккаунту.

BEAST отличается от большинства других опубликованных «нападений» на HTTPS. Другие попытки взлома сфокусированы на подмену свойства аутентификации в SSL. На сколько нам известно, BEAST — это первый в своём роде вид атаки, позволяющий фактически расшифровать HTTPS запросы.

На данный момент BEAST требуется около 2 секунд чтобы расшифровать байт зашифрованного cookie. Это означает, что аутентификационная cookie размером в 1000-2000 символов будет расшифровываться пол часа. Тем неменее, данная техника представляет угрозу для миллионов сайтов, которые используют ранние версии TLS.

Thai Duong и Juliano Rizzo заявили, что практически все приложения, использующие шифрование TLS 1.0 уязвимы, и дают возможность применить их технику для контроля и мониторинга приватных сообщений, посланных например через instant messenger или VPN.

«Проблема в том, что люди не начнут ничего улучшать, пока им не дашь хорошую причину» — сказал Ivan Ristic, директор компании Qualys, «это ужасно, не правда ли?»


График поддержки TLS 1.1 и 1.2

Пока Mozilla и разработчики OpenSSL должны внедрить TLS 1.2 вовсе, Microsoft имеет достижения чуть больше. Secure TLS версии доступны в браузере IE и IIS веб-сервере, но не по умолчанию.

Thai Duong: «Большинство браузеров и сайтов используют SSL 3.0 и TLS 1.0, соответственно если обладатель какого-либо сайта решится перейти на версии 1.1 или 1.2, он попросту потеряет значительную часть клиентов».

обновление
От пользователя alist:
Эксплойт работает как Man-in-the-middle в сочетании с внедрением JavaScript-кода на страницу. Злоумышленник слушает https-трафик и вносит на страницу клиента JavaScript. Затем этот скрипт продолжает слать запросы по тому же соединению с известным злоумышленнику содержимым. Зная содержимое тела запроса, злоумышленник может расшифровать HTTP-заголовки, в том числе cookie пользователя.
Это означает, все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript.
Перевод: Dan Goodin
Дмитрий @uglymeta
карма
31,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +44
    График невольно ассоциируется с Google Chrome.
    • +2
      *Вернее диаграмма ^)
    • +19
      Несколько моментов:

      1. Уязвимости подвержены все версии SSL и TLS 1.0. Только TLS 1.1 и TLS 1.2 остались безопасными. Это означает, что чтобы действительно оставаться в безопасности, нужно в настройках IE или Opera убрать галки для SSL и TLS 1.0 и поставить галки для TLS 1.1 и TLS 1.2. НО: после этого почти весь интернет по HTTPS будет для вас недоступным — я не нашел ни одного крупного сайта, который бы поддерживал последние версии TLS, ни Google, ни Facebook, ни PayPal, ни Microsoft, ни Twitter — никто не поддерживает соединений по этим версиям.

      2. Эксплойт работает как Man-in-the-middle в сочетании с внедрением JavaScript-кода на страницу. Злоумышленник слушает https-трафик и вносит на страницу клиента JavaScript. Затем этот скрипт продолжает слать запросы по тому же соединению с известным злоумышленнику содержимым. Зная содержимое тела запроса, злоумышленник может расшифровать HTTP-заголовки, в том числе cookie пользователя.
      Это означает, все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript.

      Таким образом, у пользователей есть два варианта: либо просто продолжать пользоваться интернетом и надеяться, что их не успеет никто взломать, пока проблему не устранят, либо продолжать пользоваться https, но выключить на защищенных страницах JavaScript. Чего не стоит делать, так это выключать в браузере TLS 1.0, оставляя включенным SSL 3 — так вы делаете себя менее защищенным, т.к. для SSL 3 известны и другие эксплойты, а браузеры оставляют его поддержку включенной только из-за того, что в интернете полно сайтов, которые еще не мигрировали на TLS. При создании соединения браузер пытается использовать самый безопасный протокол, и только потом переключается на более ранние протоколы.

      Теперь вопрос, почему никто в интернете не пользуется последними версиями TLS протокола. Ответ: потому что его реализации нет в OpenSSL, которым в свою очередь пользуются все серверы: Apache, Nginx и т.п — и браузеры — Chrome, Safari, Firefox. (см. en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support) От том, почему ребята из OpenSSL их не реализуют, мне неизвестно. Зато я знаю, что Opera тоже использует OpenSSL (см opera:about), но в ней также есть своя реализация протоколов TLS 1.1 и TLS 1.2 — которые они по всей видимости не могут передать в руки опен-сорс сообщества.
      • +2
        Злоумышленник не может внедрить javascript в https-трафик, если он может это сделать, то ему не требуется вскрывать TLS чтобы получить куки.

        На самом деле, эксплуатация выглядит чуть-чуть по-другому: злоумышленник вносит javascript в любой нешифрованный трафик (например в результат поиска на google.com), а javascript начинает выдавать запросы к атакуемому сайту (например ebay.com). Злоумышленник анализируя https трафик с этими запросами расшифровывает cookie от ebay.com. То, что пользователь отключит на ebay.com джаваскрипты никак не скажется на его защищенности, т.к. в примере джаваскрипт работает на google.com.
        • 0
          Да, не разобрался, признаю ошибку. Получается, что чтобы оставаться в безопасности, JavaScript нужно отключать совсем.
  • +6
    Прошу, скажите, что все будет хорошо. :)
    • +13
      Всё будет хорошо. Сайты обновятся до TLS 1.2, пользователи повыкидывают старые браузеры, и наступит счастье.
      • –18
        Расскажите об этом пользователям IE
        • +38
          Вроде как IE c 8 версии поддерживает TSL 1.1, а вот мозилла и хром нет. Так что ирония по поводу IE не совсем уместна.
          • –8
            Windows 7 and Windows Server 2008 R2 поддерживают TLS 1.2 по специфике, данной в RFC5246 с дополнениями из RFC4366 и RFC4681 и дополнительными наборами шифрований из RFC3268, RFC4492, RFC5289
            © MSDN
            Глазам своим не верю я
            • +9
              Я не понимаю откуда у вас такая ирония. MS всю жизнь работала в корпоративном секторе, а там без хорошего шифрования никуда.
          • +2
            Я полагаю, речь шла не о пользователях восьмой версии. А о тех дремучих миллионах, которые никак с шестого не могли перейти.
            • 0
              В точку. Про IE6, не знаю чего так взбесились.
            • +1
              По некоторым данным, пользователей интернета около 2,08 млрд. человек на начало 2011 года. Хотя, думаю, что реально уникальных пользователей гораздо меньше. Будем, однако, считать, что их 2 млрд.

              По статистике с w3schools, доля IE6 в августе составляла 2.0%:



              Несложный расчёт показывает, что дремучих миллионов на самом деле примерно 40.
              • +2
                Не лучший источник для статистики, ведь на w3c ходят учится хорошему уже выбрав браузер.
                Если смотреть обобщенную статистику из разных источников — en.wikipedia.org/wiki/Usage_share_of_web_browsers то % IE сильно выше, и значит миллионов еще больше.
                • 0
                  Я не думаю, что это статистика только по посещению их сайта, мне казалось, у них другие источники.
                  • +1
                    Нет, это именно статистика посещения их сайта, причем w3schools не имеет никакого отношения к w3c. Также вы должны понимать, что любое обращение к w3schools — моветон. Рекомендуется к прочтению: w3fools.com/
                    • +2
                      Ничего этого не знал — спасибо большое за ссылку, сижу сейчас читаю!
        • +3
          Проверил сейчас IE8, там и TLS 1.1 и 1.2 присутствуют.
          А в последней версии FF кроме TLS 1.0 галочки больше не увидел.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Странно, кажется, Opera версии так с 9.5 не поддерживает SSLv2 — я не помню деталей, но у меня была проблема с ней при использовании некой древней hp-шной вебморды. И никаких тебе user-friendly сообщений, тупо и грубо чистый лист вместо вебморды.
    Как и всегда, могу грубо ошибаться и буду рад быть поправленным.
  • +9
    Chrome:
    Настройки -> Расширенные -> Убираем галочку «Использовать TLS 1.0»
    • +4
      Отключение TLS 1.0 как-то включит неподдерживаемый Хромом 1.1 или 1.2? Или я чего-то не понимаю?
      • +9
        С отключенной галочкой Gmail работает по SSL 3.0
        • 0
          Ясно, спасибо.
        • +1
          Вроде нигде не говорится о том, что SSL 3.0 не уязвим, только о TLS 1.1 и 1.2.
          • 0
            Вообще, пишут что «Различия между SSL 3.0 и TLS 1.0 незначительны», непонятно есть ли уязвимость в SSL 3.0
            • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Не могу найти эту опцию в dev версии хрома (
    • +3
      Firefox:
      Настройки → Шифрование → Убираем галочку «Использовать TLS 1.0»

      • +2
        * Настройки → Дополнительно → Шифрование
        • +1
          А если сайт поддерживает только его?
  • 0
    Забавный факт. Из всех браузеров, только Opera поддерживает TLS 1.2 по умолчанию.
    В тексте оригинальной статьи говорится совсем противоположное: «Opera also makes version 1.2 available but not be default in its browser».
    • 0
      В самом конце статьи стоит пометка об исправлении неточности, что опера не поддерживает 1.2 по умолчанию. По крайней мере я так понял.
      • 0
        It was also corrected to reflect the fact that Opera doesn't support TLS 1.2 by default.
        Перевод:
        Статья была откорректирована, чтобы отразить тот факт, что Опера не поддерживает TLS 1.2 по умолчанию.
        • –3
          Согласитесь смысл двоякий. Однако вы меня убедили. Перечитал и вдумался. Будет исправлено.
          • +1
            Я не вижу двоякого смысла. В тексте оригинальной статьи стояло, что есть поддержка по умолчанию. Ошибку исправили, и в конце статьи сделали об этом приписку.

            BTW, в почту ещё загляните. Там ещё пара замечаний по переводу.
            • 0
              Что значит «does not support by default»? custom builds для оперы вроде как немае. Поэтому надо либо 'support' заменить на 'use', либо 'by default' заменить на 'with default settings'.
              • 0
                В настройках по умолчанию более поздние версии TLS отключены. Можно и 'use', и 'with default settings' сказать.
                • 0
                  Тогда понятно. А то 'does not support' звучит как принципиальная неподдержка, что выглядит странно рядом с 'by default'.
  • +1
    На «Ekoparty security conference» в Буэнос-Айресе в конце недели…
    «Конец недели» — это среда-четверг-пятница, так что можно уже начинать беспокоиться.
    • +2
      Доклад запланирован на 23, 18:30 (судя по всему по местному времени, так что добавьте еще несколько часов на разницу часовых поясов).
  • +7
    В оригинале статьи говорится, что это атака класса chosen-plaintext, для успешной атаки на клиенте работает javascript, который выдает серию запросов с небольшой модификацией, используется тот факт, что куки в этих запросах остается неизменным. Т.е. если я правильно понимаю, речь идет исключительно о возможности дешифровать и перехватить куки, о дешифрации произвольного HTTPS-трафика, а тем более произвольного SSL/TLS-трафика, речи не идет.
    • +4
      И если так, то, видимо, речь идет об активном M-i-t-M, пассивно атака не реализуется. Впрочем, данных пока не достаточно чтобы точно сказать.
      • +1
        Наоборот, это скорее всего пассивная атака. M-i-t-M в HTTPS не возможен. Javascript'а который выдает серию запросов с небольшой модификацией на сайтах полно без всяких модификаций сайта.
  • +1
    Информация интересная, но зачем такой жёлтый заголовок?
    «Взломали SSL» в заголовке и «Взломали старую версию SSL» в статье это же совсем не одно и тоже?
    Фу.
    • +11
      Взломали (если взломали конечно) актуальную версию TLS, использующуюся чуть ли не везде, где используется какой-либо TLS. А по поводу SSL пока не очень понятно, уязвим SSL3 или нет, но явных высказываний о его неуязвимости я не нашел (в отличие от TLS 1.1 и 1.2).
    • –2
      Ну а как же паника? Какая ж паника будет без правильного заголовка? Зачем вообще писать на Хабр, если не кошмарить IT-хомячков? [/irony]
  • +1
    Opera
    Инструменты → Общие настройки → Расширенные → Безопасность → Протоколы безопасности
    Галочки увидите сами :)
    • +4
      Я правильно понимаю, что и сайт должен поддерживать 1.2?
  • +9
    >> Пока Mozilla и разработчики OpenSSL должны внедрить TLS 1.2 вовсе, Microsoft имеет достижения чуть больше.

    Хороший перевод.

    И кстати снова в переводе нет личного мнения переводчика. Что делать-то со взломом? Куда бежать, как спасаться? «Thai Duong и Juliano Rizzo заявили» — кто это вообще такие, им стоит верить?
    • +5
      «Thai Duong и Juliano Rizzo заявили» — кто это вообще такие, им стоит верить?

      Можно, нормальные пацаны. ASP.NET в прошлом году взломали.
    • +3
      Ага, чудовищная фраза, ощущение, что это пословный перевод :(
  • +3
    Любопытно было бы глянуть на техническое описание атаки. Но что-то мне подсказывает, что это продолжение вот этой истории с уязвимостью в ASP.Net. И в таком случае вероятнее всего что атакующие в очередной раз применили классическую атаку схем дополнений. Если это действительно так, то отличие из-за которого TLS 1.1 невосприимчив к данной угрозе заключается в том, что, если верить wiki, в данной версии протокола была исправленна обработка ошибок дополнений. Во всей этой истории один плюс, сейчас все быстро начную отказываться от устаревшего TLS 1.0
  • +3
    Зачем такие заголовки с зашкаливающей желтизной??
    Хакеры ломают что-то конкретное, а в данном случае речь о научном исследовании, которым занимались математики. Математик не обязан быть хакером и наоборот.
    • +4
      Вообще не понимаю моду на желтые заголовки на Хабре, если ты не ализар.

      Провинциальная газетёнка делает себе такие заголовки, чтобы прохожие ее купили, ибо внутри они узнают «Страшный секрет %username%» или про то, что «Интернет смогут отключить ногой три программиста».

      Но в профессиональном сообществе?..
    • –5
      забавные чувачки тут тусуются. тебя плюсанули, меня минусанули. написано одно и тоже.
      ок.
  • +1
    Убрал в Google Chrome галочку с «использовать TLS 1.0», а к GMail всё равно по TLS 1.0 коннектится. :(
  • +11
    Я как посмотрю все перешли на SSL 3.0, а может они социальные инженеры и этого добивались. И на самом деле взломали не TLS 1.0, а ssl :-)
  • 0
    Объясните кто-нибудь в чем сложность внедрить TLS 1.2 если уже есть TLS 1.0?
  • 0
    ну вот и пришла пора elinks собранного без поддержки ява скрипта )
  • +3
    А как внедряется JS на страницу, если все идет поhttps?
    • 0
      Эммм… ну какбэ очень просто — если мы с вами, например, ведем в каком-то корп. портале переписку, вы ниипический ночальнег ацкого уровня доступа к супер-секретной информации, то я легко могу разместить где-нибудь сообщение с нужным JS-кодом для вас, а вы потом, прочитав его «нечаянно» передадите мне все свои печеньки. Ну а что мне сделать с полученными печеньками я уж разберусь сам, ага.
      • 0
        Не думаю, что хоть одна серьезная система разрешит размещать пользователям выполняемый JS-код в сообщениях, это серьезная уязвимость, даже без учета описанной проблемы. Если можно разместить JS-код и выполнить его в браузере другого пользователя, то незачем запариваться с https, можно просто отправить его куки на свой сервер.
        • 0
          «JavaScript-код не требуется запускать в контексте атакуемого сайта, его достаточно открыть в новой вкладке, например, путем встраивания через iframe в какой-нибудь сторонний сайт» © www.opennet.ru/opennews/art.shtml?num=31797
          • 0
            Но все равно JS-код должен быть размещен на атакуемом сайте, а потом уже с помощью iframe одна из страниц атакуемого сайта внедряется в страницу стороннего. На практике это трудно осуществимо.
            • 0
              А какая разница трудно или нет? Трудно и невозможно абсолютно различные понятия.
            • 0
              Хм, а такой вариант не прокатит: на своём сайте создаём iframe, содержащий произвольный урл атакуемого сайта, потом со вкладки на своём сайте заменяем содержимое iframe на произвольный JS. Или родительский документ не имеет доступа к DOM фрейма?
              • 0
                Думаю, нет, в противном случае возня с SSL не потребовалась бы. Если вы можете внедрить свой JS-код в iframe и он будет выполняться в контексте этого iframe, то вы можете просто отправить себе все куки атакуемого сайта.
  • 0
    ИМХО, нужно https-соединение засунуть в sandbox (скажем, в окно incognito). В этом случае его куки не передадутся в атакованное http-соединение и атакующий нифига не получит.

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