Google предложит пользователям GMail использовать end-to-end шифрование

    Корпорация Google готовится выпустить специальное расширение для браузера Google Chrome, которое позволит пользователям сервиса GMail зашифровывать сообщения перед отправкой, чтобы исключить возможность перехвата сообщений. Расширение под простым названием End-to-End использует стандарт OpenPGP, но пока не готово к выпуску, так как Google просит помощи у сообщества.

    Команда Google Security приняла решение выпустить сначала исходный код расширения под лицензией Apache 2.0, прежде чем расширение будет опубликовано в Chrome Web Store. Причина этому проста — Google пришлось столкнуться с целым рядом трудностей, поэтому в компании пока не уверены, что их реализация OpenPGP надёжна. В Google отмечают, что рантайм JavaScript архитектурно не отличается надёжностью, так как не может контролировать то, что происходит на нативном уровне, поэтому есть риск утечки данных. Отмечая причины появления данного проекта, в компании заявили, что в настоящее время существуют GnuPG и PGP, но они требуют от пользователя знаний в области шифрования, тогда как расширение от Google попытается провести процесс шифрования как можно более дружелюбно к пользователю. Что касается собственно JavaScript, то в FAQ Google даёт некоторые пояснения.

    Чтобы исправить по возможности все изъяны в проектировании расширения, Google включает свой новый продукт в список доступных для вознаграждения за нахождение и эксплуатацию уязвимостей. Таким образом, помощь Google просит не безвозмездную, а с возможностью получить награду от $500 до $20 тысяч.

    Google также просит пользователей при использовании расширения отключить отправку анонимной статистики в компанию, так как в некоторых случаях (как падение браузера) в Google могут отправиться данные, позволяющие восстановить приватный ключ пользователя.

    FAQ
    Раз вы опубликовали исходный код, то я мог сам опубликовать расширение в Webstore?
    Пожалуйста, не делайте этого.
    Команда разработчиков понимает, что потенциально этим расширением могут пользоваться журналисты, борцы за права людей и другие, кто могут не быть технически подкованными, следовательно это расширение может стать причиной неприятных последствий.
    Мы выпускаем исходный код в надежде выявить уязвимые места, которые могла пропустить наша компанда. Поэтому как только мы получим достаточно подтверждений, что наша реализация надёжна, мы сами выпустим расширение в каталог и обеспечим дальнейшую поддержку.


    Работает ли шифрование с вложениями или только с самим текстом письма в GMail?
    Только с текстом. Помните также, что тема письма и список получателей также не будут зашифрованы.

    Почему вы используете генерацию ключей только на эллиптических кривых?
    RSA-генерация медленнее, чем на эллиптических кривых.

    Будет ли End-to-End работать на мобильных устройствах?
    На данный момент Chrome на Android и iOS не поддерживают расширения, поэтому нет.

    Какие спецификации вы используете в расширении?
    RFC4880 — формат сообщений OpenPGP
    RFC6637 — OpenPGP-криптография на эллиптических кривых

    К сожалению, расширение пока не поддерживает спецификации по MIME-защите с OpenPGP и по алгоритму Camellia.

    У меня крякозябры!
    Мы пытались избежать отображения крякозябр для не-романских языков, но не удивляйтесь, если встретите крякозябры, особенно в служебных областях. Автоматические проверки кодировок мы реализовывать не стали.

    Находятся ли приватные ключи в памяти, очищаются ли они после каждой операции, или есть кэш для кодовой фразы?
    Приватные ключи хранятся незашифрованными в памяти. Мы рекомендуем, чтобы ваш «брелок» обладал кодовой фразой. В этом случае приватные ключи хранятся в зашифрованном localStorage.

    Ну и насколько они там защищены?
    Так как ключи находятся в localStorage, то необходимо их шифровать. Если просто в памяти незашифрованными, то полагайтесь только на песочницу Chromium.

    JavaScript? SRSLY?
    Да, когда мы начинали работу над End-to-End, все предыдущие JS-либы нам не подходили, поэтому пришлось нагородить свою. Мы прекрасно понимаем все угрозы, что таит в себе JS для шифрования, поэтому приняли все пришедшие нам в голову меры по смягчению и устранению рисков.

    В javaScript нет поддержки многих ключевых возможностей криптографии. Куда же без них в шифровании?
    Современные движки, такие как V8 в Chrome, поддерживают типизированные массивы, а WebCrypto обеспечивает криптостойкий генератор псевдослучайных чисел.

    Крипто-проекты на JavaScript в прошлом уже не раз ломались, уменьшив доверие к языку для реализации таких серьёзных вещей.
    Верное утверждение. Но на практике ни один распространённый язык программирования не даёт 100% защиты от уязвимостей.
    Мы прекрасно знаем обо всех примерах, поэтому мы с самого начала поставили для себя высокую планку качества. Мы начали с нуля создали современную криптографическую либу, покрытую тестами. В ней обеспечена поддержка методов BigInteger, модулярной арифметики, эллиптических кривых, как и симметричного и на открытых ключах шифрования. Сделав это, мы разработали OpenPGP-оболочку поверх библиотеки. Часть кода библиотеки используется внутри нашей компании в продакшене
    .

    Полный FAQ на Google Code.


    Для справки. Ранее на Хабре уже обсуждался пример похожего расширения от сторонних разработчиков.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 42

      +9
      Очень интересно по поводу отправки анонимной статистики в компанию…
        +1
        Они исходя из текста писем показывают рекламу. Зачем стрелять себе в ногу?
          +2
          В клиенте тот же JS у них будет иметь доступ к исходному тексту писем.
            +16
            И отсылать на сервер, для более точного таргетинга.
              +1
              А в чем проблема? Письма — они не для того, чтобы наедине!
            +20
            Массово пользователи не станут включать шифрование, а для параноиков улучшит репутацию Google.
              0
              Верно. Лень и неповоротливость станут (или уже стали?) бэкдором в частную жизнь: пользователей будут обязывают скидывать кучу галок о «сборе статистики, которая используется для улучшения бла-бла» 95% юзеров пропустят шаг с мыслью «да ладно, кому я нужен».
              Мне думается, лень заботливо взращивается как раз чтобы делать людей беспомощными в нетривиальных ситуациях. Когда необходимо долго вникать и читать мелкий шрифт. Чтобы впаривать готовые решения и невыгодные правила оказания услуг. «Вы только поставьте подпись» и все будет окей.
                +1
                Уже стали.
                90% моих знакомых ленятся почитать все пункты настроек в яндекс/гугл/мейл/...-почте чтобы найти ту самую галку «показывать мне рекламу» и снять её. Они знают что галка есть, их бесит реклама, но снять её лень.
                  0
                  Это пугает. Хотя понимание дает отличные перспективы в росте.
                  0
                  о «сборе статистики, которая используется для улучшения бла-бла»

                  Перевод: «для увеличения бабла».
              –2
              Ну конечно… Вот прям взяли и озаботились конфиденциальностью переписки пользователей.

              Лучше б в доработку gpg вложились, если оно для них недостаточно с человеческим лицом.
                0
                Ничего и делать не нужно, openpgpjs же. И расширение (правда только для почты) есть: Mailvelope.
                –3
                А с Андроидом что? Нативный клиент будет поддерживать? А поиск как? Много непонятного пока. Если не будет поиска и клиента, то зачем этот gmail нужен, с таким же успехом молоко использовать любой сервис, хоть самоподнятый на VPSке.
                  +5
                  не очень понятно где будут генерироваться и храниться ключи? В браузере клиента? Чуть что не так и вместо почты безвозвратный набор байтиков?
                    0
                    Я не смотрел эту конкретную реализацию, но можно сделать классическое хранение ключей на файловой системе. Чтение делается через FileReader API, запись — либо через window.saveAs (но его, вроде бы, пока еще нет в браузерах), либо генерация data:-ссылки и эмуляция клика по ней. Конечно, при такой реализации файл с ключами придется просить выбирать каждый раз — но можно «кэшировать» ключи в DOM storage.
                      0
                      я бы сделал хранение в виде сертификатов в браузере, если JS может получить к ним доступ.
                        +1
                        Офтоп — похоже за первую маленькую букву хабр только что предложил пройти мне курс грамотности.
                          +1
                          Мне кажется это у какого-то модератора «пунктик», я за несколько лет раза 3 уже попадал на эту проверку из-за маленькой буквы в начале предложения.
                        +2
                        Ключи будут храниться на серверах Гугла. Собсно это было одно из условий ФБР и АНБ
                          0
                          Что-то масло масленное получается. Зачем они тогда вообще нужны? Сейчас https сертификат так же лежит на серверах гугля и отлично все шифрует по дороге. Я думал это такой красивый ход чтобы оставить спецслужбы с носом. Собственно странно что спецслужбы выставляют условия частному бизнесу — как ему делать свои продукты…
                            +1
                            Мне кажется, прошлый комментатор пропустил тег <sarcasm /> =) Ибо если ключи действительно лежат на серверах гугла, то смысла в этом всем ~0.
                              +1
                              Ессесно «смысла ноль». Скорее небо упадет на землю прежде чем Гугл начнет заботиться о приватности юзера. Вообще «Google» и «приватные данные» в одном предложении выглядят смешно и нелепо.
                                +1
                                Мне кажется, что тут дело в том, что Гуглу не выгодно отдавать NSA и прочим агенствам данные своих пользователей, потому что тогда пользователи могут подумать о том, что бы перейти к тем, кто вне юристикции США. Но Гугл не может не выполнять законов США, которые заставляют его выдавать такие данные, вот они и нашли компромис: Те, кто хотят — пусть прозначно все шифруют на стороне клиента, а Гугл в свою очередь радостно службам отдаст зашифрованные данные, а ключей у него нет, так что облом.
                                Ну так скажем я надеюсь, что все примерно так и состоит, а не так, что в реальности гугл всю эту переписку все равно видит и хранит в незашифрованном виде.
                            0
                            Как мне кажется, как раз наоборот. Из текста новости я сделал вывод, что приватные ключи будут храниться на компьютерах пользователей
                          0
                          Если шифрование на стороне клиента, а судя по всему, это так, то как будет работать Gmail во всяких Турциях, Египтах и остальных Объединенных Северокорейских Эмиратах? Ведь тогда выдача информации по запросу суда становиться бессмысленной. Gmail готов потерять определенный сегмент рынка?
                            0
                            Просто этой фичи не будет на тех рынках, где крипто регулируется.
                              0
                              Что мешает жителю Северокорейского Эмирата поменять страну в гуглопрофиле на Багамские Острова? Или Гугл решил уйти с рынков стран с подцензурным интернетом? Ведь его тупо заблокируют по решению Пхеньянского Народного Суда и ЭмиратГосКомНадзор-а.
                                0
                                Обычно это делается по IP. И да, пользователю ничто не мешает настроить прокси или Тор, но законодательство подобных стран обычно не требует от гугла железобетонного ограничителя — достаточно такого, который отрежет 99% нетехнарей.
                              +6
                              В смысле, бессмысленной? Пришла subpoena, выдали все его архивы. А что там кракозябры какие, или бинарники — это гугла не волнует. Что есть, то и выдали.
                            • UFO just landed and posted this here
                                –1
                                Так вся переписка и так доступна тулам, которые используются для шифрования у Васи. Вас это не волнует?
                                  0
                                  Это симметричное шифрование, в отличие от GPG.
                                  Второй момент в том, что раз расширение от Гугла, то они будут его поддерживать при каждой смене верстки GMail, а то раз и опять все сломалось.
                                • UFO just landed and posted this here
                                    0
                                    А что, если данные отправляются не по сабмиту формы?
                                    • UFO just landed and posted this here
                                        0
                                        отправляются по какому-нибудь событию

                                        но разве после SSL рукопожатия… — возможно незаметно вклиниться

                                        Ловко писю к носу притянули.
                                    +1
                                    Неужели так сложно было добавить шифрование вложений?
                                    Они зачастую важнее, чем текст письма.
                                    • UFO just landed and posted this here
                                        +2
                                        Если действительно важно, то отправляйте шифрованные вложения.
                                          –1
                                          В качестве костыля — вложение пересылать зашифрованным zip или rar архивом, а пароль от архива — в тексте сообщения.

                                          Хочу отметить, что все браузерные PGP плагины типа Mailvelope не поддерживают шифрование вложений. Только связка Thundebird + GnuPG + Enygmail позволяет шифровать вложения без лишних телодвижений.
                                          0
                                          Vendor-lock какой-то получается. Плохо что только для хрома.

                                          Only users with full accounts can post comments. Log in, please.