Атака на SSL/TLS - конец близок?

Несколько удивился, не увидев этого в новостях КО. На прошлой неделе была презентована атака, по сути, позволяющая взламывать HTTPS-сессии (естественно, с ограничениями, куда без них). В качестве примера приводится расшифровка cookies и последующий «угон» сессии PayPal за 10 минут! Конец безопасному е-мейлу, онлайн-банкингу и шоппингу?! Паниковать или нет?! Будем разбираться.

Атака построена довольно хитро. Атакующий умудряется вбрасывать пакеты в зашифрованный канал, при этом перехватывая шифрованные пакеты. В результате умелого использования уязвимостей блочного шифрования SSL3.0/TLS1.0 атакующий расшифровывает необходимые ему данные. Потом – делает что хочет. Особенность этой атаки в том, что база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами) здесь требуется значительно меньшая (за счет умелого вброса правильно сгенерированных пакетов) – утверждается, что сессию можно вскрыть за 10-30 минут.

Для начала несколько интересных и волнительных фактов:

• Обычный пользователь проводит за онлайн-шоппингом/банкингом/платежами/почтой более 10-30 минут за сессию, так что угроза вполне реальна (достаточная база для криптоанализа).
• Атака производится на протоколы SSL 3.0 и TLS 1.0, используя ряд уязвимостей, известных начиная с 2006 года (5 с гаком лет!)
• Многие из этих уязвимостей в SSL3/TLS1.0 никогда не были закрыты
  • Потому и SSL и TLS 1.0 считаются устаревшими, TLS 1.1 (не подверженный этой уязвимости) был выпущен в 2006 году, TLS 1.2 – в 2008 и обновлен в 2011.
• Так что, получается, нет проблемы? Проблема есть!
  • Большинство браузеров не поддерживают TLS1.1+ (пока что – только IE8+/Win7 и Opera10+)
  • А те, что поддерживают, не включают по умолчанию. А почему?
    • А потому, что большинство веб-серверов не поддерживают TLS1.1+ (или он не включен по умолчанию, а админ не почесался).
• Кроме того, даже SSL3.0/TLS1.0 не подвержены этой атаке, при использовании потоковых шифров (RC4, тоже не самый надежный вариант, однако).
  • Но многие сайты не поддерживают и этот механизм! Плюс, так как RC4 слабее, скажем, AES, по умолчанию будет выбран блочный режим с AES, оказавшийся уязвимым (блочный режим, не AES).

В общем, получилась ситуация «верхи не могут, низы не хотят»: если бы проблема было только на стороне клиента – все бы решилось быстрым обновлением браузеров. Но тут, похоже, придется обновить «весь Интернет».  Вот выдержка из новости с красноречивой статистикой:

«Как обнаружили исследователи из компании Opera, только 0.25% сайтов поддерживают TLS 1.1, TLS 1.2 поддерживают 0.02%. Несмотря на то, что спецификации TLS 1.1/1.2 были разработаны достаточно давно, поддержка этих протоколов в некоторых популярных браузерах всё ещё не реализована. Это создаёт проблему для владельцев сайтов, которые хотели бы обновиться, но из-за боязни потерять клиентов делать этого не хотят»

Внизу поста есть секция с подробностями для любопытных, а пока разработчики браузеров, веб-серверов, библиотек SSL/TLS и прочие вебмастеры будут искать способ спасения мира, нам пользователям, необходимо решить важнейший вопрос:

К счастью, особого повода для паники нет. Атака опирается следующие факторы:

• Возможность перехвата трафика;
• Использование блочных шифров (CBC) в SSL3.0/TLS1.0;
• Достаточная база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами);
• Возможность вброса данных.

С первым фактором сделать ничего нельзя. Как только мы отправили пакет, мы его уже не контролируем. А вот с остальными – можно:

Администраторы веб-сайтов могут оперативно включить поддержку RC4 (или выставить ее более приоритетной, чем всякие блочные режимы). Google, как выяснилось, уже давно использует этот метод, так что GMail, GDocs, G+ и иже с ними – в относительной безопасности.

Аналогично, пользователи могут открутить поддержку всех блочных Cipher Suites (*_CBC_*) в браузере/ОС (и заодно поддержку SSL3/TLS1.0, если браузер позволяет). Правда, при этом некоторые сайты могут отказаться работать, но тут уже пользователю решать: или потенциальный риск, или потерпеть без данного ресурса.

Можно ограничить длительность сессии. С той же почтой можно работать не через браузер, а через почтовый клиент, а там TLS сессии будут покороче. На худой конец – периодически делать logout J.

И самое интересное – возможность вброса данных. Здесь используется всеми любимый XSS, но в новой форме. Как обычно, плагин NoScript для Firefox выручает.

Стараясь сохранить баланс между количеством подробностей, интересностью и краткостью изложения, завершу заметку здесь. Сухой остаток:

• Проблема есть, она реальна;
• Для реализации атаки не понадобилось открывать ни одной новой уязвимости – все было известно много лет;
• Неизвестно, сколько лет этот баг УЖЕ эксплуатировали;
• С проблемой можно бороться, если знать как.

В ближайшее время ожидаю всплеска постапокалиптических новостей на тему «конец Интернета», потом волны апгрейдов и глюков на веб-сайтах, потом все вернется на круги своя.

Ситуация на данный момент:

• Браузеры:
  • Поддерживают TLS1.1+ только Opera 10+ и IE8+/Win7;
  • «В работе» Chrome и Firefox;
  • Любой IE под WinXP и Vista – не поддерживает (т.к. IE полагается на средства ОС);
  • Safari/OSX – не поддерживает, и Джобс его знает, что будет дальше.
• Серверы:
  • Поддерживают TLS1.1+: IIS7+, mod_gnutls для Apache;
  • OpenSSL (наиболее популярный) поддерживает TLS 1.1 только в бетах;
  • NSS (Chrome, Firefox и серверные реализации для Apache, Java и т.д.) поддерживает TLS1.1+ очень ограниченно;
  • Все остальное – не поддерживает.

Сравнительно свежий документ, который расписывает, какие браузеры и веб-серверы что поддерживают (заодно приводит краткий экскурс в историю SSL/TLS).

Две подробных статьи с анализом:

• http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
• http://www.imperialviolet.org/2011/09/23/chromeandbeast.html