Разработчики Firefox проанализировали подверженность браузера недавно анонсированному методу атаки против SSL/TLS, позволяющему на промежуточном шлюзе организовать перехват передаваемого в рамках зашифрованного соединения Cookie с параметрами аутентификации пользовательской сессии. В итоге, был сделан вывод, что несмотря на использование TLS 1.0, Firefox не подвержен данной проблеме, так как без задействования дополнительных плагинов невозможно обеспечить необходимые для проведения атаки условия (полный контроль за содержимым соединения). Тем не менее, сообщается, что атака теоретически может быть совершена в случае наличия у пользователя Java-плагина. Поэтому в настоящее время разработчики рассматривают возможность отключения Java-плагина для существующих установок.
Разработчики проекта Tor опубликовали заметку в которой подробно разобрали принцип совершения атаки и пришли к выводу, что при использовании приложений от проекта Tor пользователи защищены от данного вида атаки. В частности, в Tor используются дополнительные методы рандомизации, используя возможность библиотеки OpenSSL по вставке пустых фрагментов перед отправкой каждой записи.
Браузер Chrome частично подвержен уязвимости, но проблемы будут решены в ближайшем обновлении. Серверы Google не подвержены проблеме, так как не используют режим CBC и применяет шифр RC4 вместо AES (атака возможна только при использовании CBC в комбинации с AES). В Chrome для полного контроля за передаваемыми через SSL данными можно использовать API WebSockets, поддержка которого по умолчанию активирована в последнем выпуске Chrome 14. Но более простым способом выглядит использование функций таких плагинов как Java. Возможность использования Java подтверждена создателями метода атаки, но по умолчанию в Chrome блокируется использование плагина Java. Сама по себе атака достаточно сложна и требует получения контроля за промежуточным шлюзом и наличия высокоскоростного канала связи с жертвой. Подобных условий можно достичь получив контроль за используемой жертвой точкой беспроводного доступа, но по мнению разработчиков Chrome нет смысла в проведении столь сложной атаки, когда можно использовать более легкие способы - например эксплуатировать критическую уязвимость во Flash или использовать атаку SSL stripping (в HTTP трафике осуществляется подмена HTTPS-ссылок) при получения контроля над шлюзом.
Также упоминается о процессе разработки обходных путей для защиты продуктов, использующих SSL 3.0 и TLS 1.0. TLS 1.1 и TLS 1.2 не подвержены проблеме, но несмотря на то, что TLS 1.1 был представлен в 2006 году, в настоящее время он до сих пор не поддерживается большинством типовых SSL/TLS библиотек. Кроме того, даже повсеместное внедрение TLS 1.1/1.2 не смогло бы решить проблему, так как все браузеры поддерживают автоматический откат до использования SSL 3.0 при работе с проблемными серверами. Даже если клиент и сервер поддерживают TLS 1.1, злоумышленник может легко создать ситуацию при которой вместо TLS 1.1 будет использован SSL 3.0.
Дополнительно был придуман простой и эффективный метод защиты - достаточно добавить пустой блок перед каждой передаваемой порции данных, что создаст необходимый уровень рандомизации, достаточный для того чтобы атака оказалась неэффективной. Добавив в один из выпусков Chrome тестовый код для оценки работы данного метода, разработчики пришли к выводу, что к сожалению его использовать нельзя, так как в сети оказалось достаточно много проблемных реализаций SSL/TLS, которые некорректно реагировали при наличии подобных пустых блоков.
Второй обходной путь защиты, который имеет меньше проблем из-за несовместимости с проблемными реализациями SSL/TLS, в настоящее время проходит тестирование в dev- и beta-ветках Chrome и скоро будет задействован в стабильной версии браузера. Суть метода в отправке только одного байта данных в первой зашифрованной CBC-записи, что приведет к возможности перехвата атакующим только одного байта. Метод позволит блокировать для совершения атаки протокола WebSockets, но не поможет от использования сторонних плагинов для проведения атаки.
Компания Microsoft также представила свой план решения проблемы, который связан с использованием в своих серверных продуктах в первую очередь алгоритма RC4 или протокола TLS 1.1. В настоящее время уже выпущен специальный инструментарий для активации поддержки TLS 1.1 в Internet Explorer и серверное ПО Windows.
