Сегодня я хочу рассказать вам о новой технологии Яндекс.Браузера, которая защищает трафик при использовании публичного WiFi. А в ближайшее время в рамках конкурса на конференции ZeroNights любой желающий сможет попробовать найти в ней уязвимость. Но обо всем по порядку.
Небезопасный WiFi
Про риски, которые несет открытый или слабозащищенный WiFi, можно на Хабре и не рассказывать. Достаточно вспомнить самую крупную в истории утечку банковских данных, когда потеря миллионов номеров кредитных карт стала возможно во многом из-за использования ненадежного протокола WEP в WiFi-сетях. С тех пор прошло десять лет, но ситуация не стала лучше, ведь сейчас нас всюду окружают точки вообще без какого-либо шифрования. Их можно найти в кафе, в аэропортах и даже на автобусных остановках. При этом перехват такого WiFi может освоить любой школьник со сниффером. А простейшие устройства для взлома вообще продаются в интернете за считанные доллары.
Хотя зачем что-то взламывать, если мошеннику достаточно создать свою собственную открытую WiFi-точку в публичном месте с названием вида «Free WiFi». Причем, если ее имя совпадает с именем другой широко распространенной, то смартфон может автоматически подключиться к такой точке, как только окажется в радиусе действия. И в результате мошенники перехватят все незашифрованные данные. Или подменят DNS со всеми вытекающими последствиями. А могут ведь и наоборот встраивать в этот поток шок-рекламу или поддельные формы авторизации.
Риск перехвата данных хорошо известен. Именно поэтому использование HTTPS является негласным правилом для любого сайта, работающего с конфиденциальными данными. В браузерной индустрии обсуждается даже идея перейти от маркировки HTTPS к пугающим предупреждениям о небезопасности сайтов с HTTP. Но перемены происходят не так быстро. Например, по нашим данным, 68% всех загружаемых страниц в браузере все еще используют HTTP. Да и пользователи, признаемся сами себе, в массе своей не обращают внимание на замочки в адресной строке.
Эксперимент в Chromium
В какой-то момент, разбирая обращения в поддержку, мы задумались, а не включить ли нам шифрование трафика на стороне браузера? Тем более, что проксирующий сервер у нас уже есть, и работает на нем технология Турбо, отвечающая за оптимизацию страниц и видео. Вот только режим Турбо, вопреки распространенному мнению, не умел шифровать трафик. Несколько слов о том, как работала теперь уже старая версия технологии Турбо в нашем браузере.
Турбо 1.0
Серверная составляющая Турбо в свое время была написана еще Оперой на таком широко известном в очень узких кругах языке, как Pike. Поэтому сервер мы старались лишний раз не трогать, вспоминая сами знаете какую заповедь.
Обмен данными с клиентом осуществлялся через уже устаревшую версию SPDY без какого-либо TLS. Клиентский код в браузере, изначально ориентированный на простейший режим работы со сжатием (ВКЛ/ВЫКЛ), со временем оброс новыми фишками. Мы научили его включаться автоматически в зависимости от скорости. Причем учитывали даже статистику других пользователей с ближайших IP адресов, чтобы включать ускорение раньше, чем человек ощутит тормоза. А потом интегрировали такую крутую фишку, как сжатие потокового видео. Код от всего этого почему-то проще не становился, а очень хотелось.
Иными словами, для начала нужно было обновить всю технологию проксирования. К счастью, у нас был Тапок.
Проект Тапок
Тапок (TAPOC is Advanced Page Optimizer and Compressor) — это такой проект внутри команды разработчиков Яндекс.Браузера, который изначально возник практически на личной инициативе нескольких человек. Целью Тапка было обновление кода Турбо и приведение его к современным требованиям. Как минимум нужно было переписать серверную часть с использованием распространенных технологий. Это позволило бы более активно ее развивать. Плюс к этому нужно было навести порядок на клиенте, который становилось все труднее тестировать. И еще одна мелочь: было важно ничего не сломать.
К счастью, Тапок полетел (в хорошем смысле), и план был даже перевыполнен. Серверную часть переписали на чуть более распространенном C++ с использованием nginx в качестве ядра. Причем для сжатия страниц мы вместо старого кода решили использовать опенсорсную библиотеку PageSpeed Optimization. Благодаря этому наш режим Турбо научился минифицировать CSS/JS/HTML, а не только сжимать. Хотя кое-что добавили и от себя. Например, конвертирование тяжелых анимированных гифок в WebP. На клиенте не стали плодить велосипеды и по максимуму использовали уже существующий в Chromium код, отвечающий за связь с Data Reduction Proxy (это такой гугловский сервер, где тоже происходит сжатие контента). Нужно были только подружить этот код со сжатием видео и другими функциями Яндекс.Браузера.
Но самое приятное, что связь между браузером и сервером теперь работает по HTTP/2. А это и шифрование трафика, и приоритизация потоков, и поддержка server push'ов для критических ресурсов (кстати, в свое время помогли проекту Chromium с ними).
Безопасный WiFi
Вопрос шифрования был решен (а заодно мы обновили и всю технологию сжатия контента). Это защитило HTTP-трафик наших пользователей от перехвата и подмены DNS (HTTPS же и без нас защищен сертификатом). Но мы на этом не остановились, потому что цель у нас была более конкретной. Помните про защиту WiFi?
С самого начала всей этой истории мы хотели защитить данные пользователей, но при этом не вмешиваться в них, т.е. работать без какой-либо оптимизации и сжатия. Поэтому на этапе перестройки Турбо мы добавили «под капот» специальный режим «без сжатия». Если он активирован, то весь HTTP-трафик будет идти зашифрованным через наш проксирующий сервер, но сам контент никак не будет изменен. Но и этого мало.
Мы научили браузер анализировать соединение и включать режим безопасного WiFi только тогда, когда он действительно необходим. Современное шифрование с помощью протоколов WPA и WPA2 достаточно надежно. Чего нельзя сказать о WEP или тех точках, которые вообще не требуют пароля. Именно для них режим безопасного WiFi и будет включен автоматически. Проверка соединения будет проводиться вновь при каждом изменении одной из следующих характеристик: IP, Mac-адрес роутера, ESSID. Кстати, проверка включает в себя и выявление интранета, чтобы не пытаться пустить трафик через прокси без выхода в интернет.
Защита WiFi от перехвата уже сейчас доступна в Яндекс.Браузере для Windows, OS X и Android. Наша команда сейчас продолжает ее дорабатывать, поэтому ваши отзывы были бы очень полезны.
Яндекс.Браузер на ZeroNights
Мы понимаем, что невозможно работать над безопасностью в изолированной среде. Поэтому уже скоро Яндекс.Браузер станет доступен для поиска ошибок и уязвимостей в рамках специального конкурса. Проводиться он будет совместно с организаторами конференции ZeroNights, которая традиционно привлекает специалистов в области безопасности. Победителей будут ждать денежные призы. Следите за новостями!
Небезопасный WiFi
Про риски, которые несет открытый или слабозащищенный WiFi, можно на Хабре и не рассказывать. Достаточно вспомнить самую крупную в истории утечку банковских данных, когда потеря миллионов номеров кредитных карт стала возможно во многом из-за использования ненадежного протокола WEP в WiFi-сетях. С тех пор прошло десять лет, но ситуация не стала лучше, ведь сейчас нас всюду окружают точки вообще без какого-либо шифрования. Их можно найти в кафе, в аэропортах и даже на автобусных остановках. При этом перехват такого WiFi может освоить любой школьник со сниффером. А простейшие устройства для взлома вообще продаются в интернете за считанные доллары.
Хотя зачем что-то взламывать, если мошеннику достаточно создать свою собственную открытую WiFi-точку в публичном месте с названием вида «Free WiFi». Причем, если ее имя совпадает с именем другой широко распространенной, то смартфон может автоматически подключиться к такой точке, как только окажется в радиусе действия. И в результате мошенники перехватят все незашифрованные данные. Или подменят DNS со всеми вытекающими последствиями. А могут ведь и наоборот встраивать в этот поток шок-рекламу или поддельные формы авторизации.
Риск перехвата данных хорошо известен. Именно поэтому использование HTTPS является негласным правилом для любого сайта, работающего с конфиденциальными данными. В браузерной индустрии обсуждается даже идея перейти от маркировки HTTPS к пугающим предупреждениям о небезопасности сайтов с HTTP. Но перемены происходят не так быстро. Например, по нашим данным, 68% всех загружаемых страниц в браузере все еще используют HTTP. Да и пользователи, признаемся сами себе, в массе своей не обращают внимание на замочки в адресной строке.
Эксперимент в Chromium
В какой-то момент, разбирая обращения в поддержку, мы задумались, а не включить ли нам шифрование трафика на стороне браузера? Тем более, что проксирующий сервер у нас уже есть, и работает на нем технология Турбо, отвечающая за оптимизацию страниц и видео. Вот только режим Турбо, вопреки распространенному мнению, не умел шифровать трафик. Несколько слов о том, как работала теперь уже старая версия технологии Турбо в нашем браузере.
Турбо 1.0
Серверная составляющая Турбо в свое время была написана еще Оперой на таком широко известном в очень узких кругах языке, как Pike. Поэтому сервер мы старались лишний раз не трогать, вспоминая сами знаете какую заповедь.
Обмен данными с клиентом осуществлялся через уже устаревшую версию SPDY без какого-либо TLS. Клиентский код в браузере, изначально ориентированный на простейший режим работы со сжатием (ВКЛ/ВЫКЛ), со временем оброс новыми фишками. Мы научили его включаться автоматически в зависимости от скорости. Причем учитывали даже статистику других пользователей с ближайших IP адресов, чтобы включать ускорение раньше, чем человек ощутит тормоза. А потом интегрировали такую крутую фишку, как сжатие потокового видео. Код от всего этого почему-то проще не становился, а очень хотелось.
Иными словами, для начала нужно было обновить всю технологию проксирования. К счастью, у нас был Тапок.
Проект Тапок
Тапок (TAPOC is Advanced Page Optimizer and Compressor) — это такой проект внутри команды разработчиков Яндекс.Браузера, который изначально возник практически на личной инициативе нескольких человек. Целью Тапка было обновление кода Турбо и приведение его к современным требованиям. Как минимум нужно было переписать серверную часть с использованием распространенных технологий. Это позволило бы более активно ее развивать. Плюс к этому нужно было навести порядок на клиенте, который становилось все труднее тестировать. И еще одна мелочь: было важно ничего не сломать.
К счастью, Тапок полетел (в хорошем смысле), и план был даже перевыполнен. Серверную часть переписали на чуть более распространенном C++ с использованием nginx в качестве ядра. Причем для сжатия страниц мы вместо старого кода решили использовать опенсорсную библиотеку PageSpeed Optimization. Благодаря этому наш режим Турбо научился минифицировать CSS/JS/HTML, а не только сжимать. Хотя кое-что добавили и от себя. Например, конвертирование тяжелых анимированных гифок в WebP. На клиенте не стали плодить велосипеды и по максимуму использовали уже существующий в Chromium код, отвечающий за связь с Data Reduction Proxy (это такой гугловский сервер, где тоже происходит сжатие контента). Нужно были только подружить этот код со сжатием видео и другими функциями Яндекс.Браузера.
Но самое приятное, что связь между браузером и сервером теперь работает по HTTP/2. А это и шифрование трафика, и приоритизация потоков, и поддержка server push'ов для критических ресурсов (кстати, в свое время помогли проекту Chromium с ними).
Безопасный WiFi
Вопрос шифрования был решен (а заодно мы обновили и всю технологию сжатия контента). Это защитило HTTP-трафик наших пользователей от перехвата и подмены DNS (HTTPS же и без нас защищен сертификатом). Но мы на этом не остановились, потому что цель у нас была более конкретной. Помните про защиту WiFi?
С самого начала всей этой истории мы хотели защитить данные пользователей, но при этом не вмешиваться в них, т.е. работать без какой-либо оптимизации и сжатия. Поэтому на этапе перестройки Турбо мы добавили «под капот» специальный режим «без сжатия». Если он активирован, то весь HTTP-трафик будет идти зашифрованным через наш проксирующий сервер, но сам контент никак не будет изменен. Но и этого мало.
Мы научили браузер анализировать соединение и включать режим безопасного WiFi только тогда, когда он действительно необходим. Современное шифрование с помощью протоколов WPA и WPA2 достаточно надежно. Чего нельзя сказать о WEP или тех точках, которые вообще не требуют пароля. Именно для них режим безопасного WiFi и будет включен автоматически. Проверка соединения будет проводиться вновь при каждом изменении одной из следующих характеристик: IP, Mac-адрес роутера, ESSID. Кстати, проверка включает в себя и выявление интранета, чтобы не пытаться пустить трафик через прокси без выхода в интернет.
Защита WiFi от перехвата уже сейчас доступна в Яндекс.Браузере для Windows, OS X и Android. Наша команда сейчас продолжает ее дорабатывать, поэтому ваши отзывы были бы очень полезны.
Яндекс.Браузер на ZeroNights
Мы понимаем, что невозможно работать над безопасностью в изолированной среде. Поэтому уже скоро Яндекс.Браузер станет доступен для поиска ошибок и уязвимостей в рамках специального конкурса. Проводиться он будет совместно с организаторами конференции ZeroNights, которая традиционно привлекает специалистов в области безопасности. Победителей будут ждать денежные призы. Следите за новостями!
