Компания
310,24
рейтинг
17 сентября 2015 в 12:43

Разработка → Безопасный WiFi в Яндекс.Браузере. О защите для тех, кто ещё не успел HTTPS

Сегодня я хочу рассказать вам о новой технологии Яндекс.Браузера, которая защищает трафик при использовании публичного 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, которая традиционно привлекает специалистов в области безопасности. Победителей будут ждать денежные призы. Следите за новостями!
Автор: @BarakAdama
Яндекс
рейтинг 310,24

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

  • 0
    Мы научили браузер анализировать соединение и включать режим безопасного WiFi только тогда, когда он действительно необходим. Современное шифрование с помощью протоколов WPA и WPA2 достаточно надежно. Чего нельзя сказать о WEP или тех точках, которые вообще не требуют пароля. Именно для них режим безопасного WiFi и будет включен автоматически.

    Аяяяй. arp spoofing отлично работает и в хорошо шифрованных сетях, и ой как далеко не все сети от него защищены.
    • +6
      Проспуфить можно либо локальный хост, либо шлюз. Но от спуфинга шлюза хттпс замечательно помогает.
      • +1
        https и так защищены, и без яндекса. Они позиционируют себя как добавившие защиты для НЕ https ресурсов, когда доступ к ним осуществляется через открытые сети. Так вот я говорю что независимо от шифрования сети, если подключиться к ней может любой желающий, злоумышленник может осуществить arp spoofing легально находясь внетри WPA2 защищённой сети и осуществить атаку на не защищённые https ресурсы и яндекс в данном случае не поможет.
        • 0
          Это если Wi-Fi на точке D-Link раздается. В нормальных решениях на хотспотах включают изоляцию клиентов, рубают неавторизованные ARP-ответы (да, виртуалки не работают, ну и фиг с ними) и много еще чего творят. Правда, зная PSK и обладая значительной страстью к извращениям, можно всё равно вбрасывать любые пакеты не глядя на настройки точки ВООБЩЕ (ну и подделывать любые заголовки как следствие). Но это уже редкий изврат, от которого защищаются (если действительно нужно) с помощью WPA2-Enterprise с EAP-TLS и каким-то onboardng.

          Могу описать решение, но и оно проламывается. Всё проламывается, вопрос только — какой ценой и за сколько времени :)
  • –48
    Эту «безопасность» обещает компания которая пишет все с микрофонов мобильника в файл, а потом отправляет себе?
    Хорошая попытка Яндекс, но нет.
    • +13
      >а потом отправляет себе

      Нет, не отправляет. Они хранились локально. Прочитайте, пожалуйста, пост с описанием проблемы habrahabr.ru/company/yandex/blog/266465.
      • –9
        Ага, в приложении метро тоже была ошибка? Я лично этой конторке вообще не верю. А если говорить про их браузер отношение примерно как к антивирусу Попова — взяли готовый chromium, сверху нескучные обои, налепили пару сомнительных плагинов, логотип в виде трусов — пользуйтесь граждане, мы лучшие! Сами то не в состоянии браузер с нуля сделать.
        Можете и далее минусовать товарищи, хабр уже не торт, даже свое мнение высказать не дают, обязательно заминусуют.
        • +4
          Не думал, что когда-нибудь брошусь защищать Яндекс и его Браузер, но вы им сами-то пользовались или только логотип в виде трусов на скриншотах разглядывали?
          Думаю, вас минусуют за то, что вы пытаетесь выдать желаемое за действительное. Если бы гигабайты записей куда-нибудь передавались, кто-нибудь бы точно это заметил и сообщил об этом. Но таких вот не нашлось почему-то, ага.
        • +4
          Когда мнение больше похоже на бессвязный бред, аргументы не проверены и, откровенно говоря, лживы, а манера речи и доводы имеют пренебрежительный характер… То дело, безусловно, в сайте, это сайт «не торт», это люди плохие, но не я.
          • –2
            Какой еще бессвязный бред? Сайт разделился на какие то куски, кусок который хабр теперь блог компании arduino. Geektime кусок — космос. Тостер вот еще хоть как то отдает старым хабром. Раньше посты мейла ру и яндекса как минимум жестко критиковались, теперь же с упоением идет обсуждение яндекс трусов. Я так например не понимаю как тру админы и программисты могут использовать яндекс трусы? Раньше можно было почитать как написать подобный велосипед для https самому. Раньше можно было в лицо спрашивать почему используете исходники чужого браузера, почему не пишите свои. Где открытые куски кода ваших наработок? Почему это уже не первый косяк в мобильных приложениях, вспоминает следилку в яндекс метро.
            Короче, хабр скатился, яндекс тоже скатился.
            • 0
              Раньше можно было в лицо спрашивать почему используете исходники чужого браузера, почему не пишите свои

              Так и сейчас можно. Но только когда есть какие-то аргументы, а беспочвенные обвинения вроде как никогда не любили нигде.

              Где открытые куски кода ваших наработок?

              https://www.google.ru/search?q=yandex+chromium&oq=yandex+chromium&aqs=chrome..69i57j0j69i64l3.4209j0j7&sourceid=chrome&es_sm=93&ie=UTF-8#newwindow=1&q=yandex-team.ru+site:git.chromium.org
              code.google.com/p/chromium/issues/list?can=1&q=reporter%3Ayandex-team.ru
              • +1
                На всякий случай добавлю свои комментарии. В Chromium мы отправляем исправления, оптимизацию, некоторые доработки, такие как реализация server-push в HTTP/2 или новая сборочная система всего проекта Chromium для Windows. Продуктовые фишки не отправляем. Потому что в этом нет смысла. Продуктовая команда по ту сторону создает свой браузер со своими фишками. Ты не можешь просто взять и загрузить туда свой код. Его не включат в проект. Не секрет ведь, что Chromium создается так, чтобы максимально быстро собирать из него Chrome. Мы пробовали доработать в проекте тот же предзагрузчик, но там это никому не было интересно. А еще у нас на многие компоненты права принадлежат не только нам, поэтому их нельзя публиковать в опенсорсе.

                Раньше можно было в лицо спрашивать почему используете исходники чужого браузера, почему не пишите свои


                Иногда, чтобы получить ответ на вопрос, достаточно просто спросить. Мы участвуем в проекте Chromium и используем открытый код, потому что нет никакого смысла изобретать велосипед. По этой же причине для Chromium выбрали движок webkit.
            • +2
              >Я так например не понимаю как тру админы и программисты могут использовать яндекс трусы?
              Потому что «тру» — смотрят в первую очередь на функционал. И если он оказывается для них удобным — почему бы им не пользоваться? У меня вот есть коллега, который пренебрежительно относился к ЯБ, но когда хром в очередном обновлении отключил NPAPI — он попробовал ЯБ — и ему понравилось. И куча подобных примеров.
  • 0
    У меня дома точка работает по белому списку. Тоже включится https?)
    • 0
      Если она открытая и есть доступ в сеть, то включится. Функцию, конечно же, можно отключить.
      • 0
        Она открыта узкому кругу устройств. Пароли были отключены что бы вайфай на несколько мегабит в секунду работал шустрее)
        • +3
          А если чужое устройство будет использовать такой же Mac-адрес (специально скопирует)?
          • 0
            Ну ещё через забор надо перелезть и познакомиться с собачкой, милой кавказкой собачкой)))
            • +4
              с тарелочкой не надо через забор лазить.
              • 0
                не факт, что тарелочка услышит ответ роутера, но шанс далеко не 0
            • +2
              Есть более продвинутые клиентские wifi карточки, который смогут словить ваш wifi за забором без каких-либо проблем. Защита по MAC это = нет защиты, вот и всё.
          • +2
            Да и клонировать MAC не надо, лишняя работа и привлечение внимания. Трафик не шифрованный ведь — достаточно добыть карточку с режимом мониторинга и запустить Wireshark.
        • +5
          То есть у вас ради скорости пакеты не шифруются?
    • +4
      Уточните — а сеть при это открытая?

      Если так, почему Вы ее не настроите на действительно безопасную работу?

      Белый список — это и не защита от подмены клиента (обмануть его и правда нетрудно), и не защита летящих в канале данных.
  • +6
    Привет! Хотелось бы немножко вопросов задать.

    Я правильно понял, что в результате все HTTP страницы будут пролетать через Тапок?

    Что будет со статистикой и аналитикой на HTTP ресурсах, которые вместо клиентов с разнообразных IP получат теперь много подключений из пула Яндекса? Не сломается ли у них профилирование по GeoIP-и-так-далее?

    Хранит ли Тапок логи клиентов? Если раньше пользователь рисковал потерять данные на куче чужих промежуточных (может быть даже и зловредных) проксях/маршрутизаторах, то теперь он от этого защищен. Его данные увидите только вы. Будут ли добавлены в пользовательское соглашение соответствующие строки?

    • +2
      UA и IP пробрасываются до конечной точки, как и раньше. Аналитика не пострадает. По всем этим пунктам изменений и нет в сравнении с Турбо, которая и раньше у нас была.
      • 0
        Я можно для понимания, как IP пробрасывается?
        Ой. А где можно почитать на счет логов в Турбо? Хранятся или нет, и использует ли их как-то Яндекс?
    • +1
      И на всякий случай скажу про логи. На Турбо логируются только обезличенные урлы (для технических целей оценки нагрузки, гео-распределения серверов).
  • 0
    А как браузер определяет что используется достаточно надёжное соединение? Используются какой-то интерфес ОС для запроса типа шифрования?
    • +2
      Да, стандартные для каждой ОС способы получения такой информации.
  • +2
    уже сейчас доступна в Яндекс.Браузере для Windows, OS X и Android

    Linux? iOS?
    • +2
      Для Linux чуть позже. Для iOS пока не получится сделать из-за ограничений платформы.
      • –1
        BlackBerry?
        • 0
          В ближайшее время для BB не стоит ждать браузера.
        • 0
          Android-версия должна работать, если у вас 10.3+
      • 0
        А можно подробнее про ограничения? Точнее, почему они не помешали реализации Турбо (или этот режим там реализован сильно ограниченно?), но помешают реализовать эту штуку?
        • 0
          Мы перешли на новый системный компонент WKWebView на iOS. Он быстрее, стабильнее. Но именно у него появились ограничения в сравнении со старым webview. Например, Турбо теперь не умеет включаться автоматически, анализируя скорость. Только руками через настройки. Для WiFi нужна и автоматизация, и анализ сети, а с этим там плохо.
  • –1
    Как минимум нужно было переписать северную часть с использованием распространенных технологий

    Вероятно, тут ошибка
    • +1
      Спасибо, исправили.
  • 0
    Панелька эта для обычных пользователей выглядит пугающе, особенно выбор между «оставить» и «отключить». Может «оставить» следует заменить на «ок», или вообще сделать не панель, а балун от значка замка с уведомлением?
    • +1
      Главное, чтобы пользователь не отключал эту фишку без явного понимания последствий. Но работа над интерфейсом идет по всем фронтам (тот же Калипсо), поэтому будем пробовать разные варианты.
  • +12
    Спасибо за реализацию еще одного инструмента обхода блокировок!
    Заблокированные в РФ сайты стали намного лучше открываться
    Наверное, вот это вот главное конкурентное преимущество для российских пользователей.
    • +12
      Тсс…
    • +8
      Да здравствует импортозамещение!
      Вместо Opera Turbo — Яндекс Тапок!
  • +1
    А это дело можно как-то в настройках включить даже не в WiFi сети? Иногда подключаюсь по LAN в сетях, где такая функция очень бы пригодилась.
    • 0
      Можно будет принудительно включить Турбо, где и работает шифрование по умолчанию (пишу в будущем временем, потому что сейчас у нас новая Турбо (не WiFi, а именно для сжатия) в эксперименте и доступна не всем 100% пользователей). Да, при этом будет еще и сжатие трафика.
  • –3
    То есть яндекс будет знать ещё больше о активности пользователей?
    • 0
      Это круто, молодцы
  • +1
    По сути яндекс какбэ говорит нам:
    Что бы никто вам не сделал человека в середине, человека в середине вам сделаем мы!
    В принципе это, конечно, гораздо лучше чем MiM от соседа. Уровень доверия яндексу выше. Зато расширяются возможности контекстной рекламы и таргетинга…
    • 0
      Насчет последнего не уверен. Обезличенные урлы ведь.
      • 0
        Обезличенность очень хитрая штука. Можно не записывать какой-то идентификатор пользователя типа имени, но при этом собирать весь контент в один набор данных, помеченный уникальным идентификатором. Для таргетинга хватит и по закону о ПДн это будут обезличенные данные.
  • 0
    1. Для того, чтобы избежать проблем с типичными атаками на Wi-Fi сети очень неплохо строить эти сети на нормальном оборудовании, которое с ними умеет справляться.
    Вопрос, конечно, не к пользователям, а к тем, что Frer Wi-Fi предоставляет.
    2. Наличие прокси между мной и сайтом, мягко говоря, доверия не вызывает. Конечно, есть СОРМ и все дела — тайное никакое не тайное вовсе. Но ловить себе везде соответствующую рекламу и без того утомляет.
    • 0
      1. Мошенник может и сам поднять точку. И к нему подключатся.
      2. Простите, какую рекламу?

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

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