ProtonMail или что же это на самом деле?

    ProtonMail




    История ProtonMail, сервиса защищенной веб-почты, о котором уже было довольно много написано (в том числе и здесь), началась летом 2013 года, когда группа ученых из CERN (Европейская организация по ядерным исследованиям) объединила усилия в работе над улучшением ситуации с безопасностью в Интернете. Их стартап ProtonMail вышел в полуфинал 2014 MIT 100K. С этого момента и началось очень бурное развитие проекта. Именно данная победа послужила серьезным шагом для того, чтобы о них заговорили по всему миру.

    История развития


    15 мая 2014 г. началось открытое бета-тестирование. Но желающих зарегистрироваться оказалось настолько много, что им пришлось закрыть регистрацию и разместить форму для сбора заявок на получение аккаунта. Планируется отправлять приглашения на регистрацию по мере наращивания серверных мощностей.

    17 июня команда ProtonMail запустили кампанию по сбору средств на развитие проекта на indiegogo.com — https://www.indiegogo.com/projects/protonmail/. Целью кампании являлся сбор US$ 100 000, которые пойдут на закупку серверов и позволят команде полностью сконцентрироваться на разработке сервиса. Были разосланы письма с предложением поддержать их всем пользователям, оставившим заявку на регистрацию. Всего за несколько дней цель была достигнута. На момент написания данной статьи собрано US$ 231 088 (за первые 7 дней). Основным бонусом в благодарность за поддержание проекта является незамедлительное получение доступа к сервису.

    Получение доступа к ProtonMail


    Мне было очень интересно узнать, что все же представляет из себя ProtonMail. К сожалению, я не успел получить аккаунт, когда регистрация была открыта, и оставил заявку. Чтобы получить заветный аккаунт, я с удовольствием поддержал ребят через Indiegogo.

    Через 6 часов на мой почтовый ящик поступило сообщение со ссылкой, по которой я активировал аккаунт. Регистрация заняла около минуты.

    Создание аккаунта ProtonMail


    Для создания аккаунта предлагается задать два пароля: для доступа к аккаунту и почтовый пароль.

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

    Почтовый пароль не отправляется за пределы компьютера пользователя и используется в процессе генерации ключа для шифрования в последующем. Данный пароль не подлежит “восстановлению”. Если он утерян, то доступ к содержимому почтового ящика будет утерян вместе с ним. Забегая немного вперед, следует отметить, что изменить данный пароль не представляется возможным, о чем сказано на странице вопросов-ответов.

    Can I change or reset my Mailbox password? 
No. Your MailBox Password is tied to all of your emails because it’s used to encrypt all of your messages. If you were allowed to change this, then all of your current and past messages would be undecryptable and unreadable.

    Пароль для входа в аккаунт можно изменить на странице настроек в личном кабинете.

    Для входа необходимо сначала авторизоваться с использованием основного пароля, а затем ввести почтовый пароль, который будет использоваться для дешифровки содержимого писем уже прямо на вашем компьютере. Это позволяет обеспечить отсутствие доступа к содержимому писем со стороны сервиса и делает это физически невозможным. Здесь стоит скептически отметить, что это “в теории”, а “на практике”…

    Как же выглядит и работает ProtonMail?


    ProtonMail является исключительно веб-почтой. Поддержки POP3/IMAP/SMTP нет, так как вся криптография реализована на стороне веб-браузера на JavaScript.

    Заходим в аккаунт и видим приветственное сообщение от команды ProtonMail. В нем кратко объясняется, какая информация шифруется, можно ли использовать ProtonMail для общения с пользователями других почтовых сервисов (например, Gmail или Hotmail).



    Из основных моментов следует отметить:
    • Письма между пользователями ProtonMail шифруются всегда и автоматически.
    • Прикрепленные файлы не шифруются, о чем говорится в приветственном письме, но пишут, что планируют добавить такую возможность в будущем.
    • Наличие возможности отправить зашифрованный email любому получателю за пределами ProtonMail. В этом случае получателю приходит письмо со ссылкой, перейдя по которой он видит предложение ввести пароль для доступа к содержимому письма. Данный пароль задает отправитель перед отправлением письма с сервиса ProtonMail.
    • Возможность задать время хранения письма. Данная возможность доступна при переписке с другими пользователями ProtonMail и отправке шифрованных писем на сторонние почтовые сервисы (получателю приходит ссылка для чтения письма на сайте ProtonMail). По истечению данного времени письмо удаляется.
    • Возможность получать письма от сторонних сервисов. В данном случае содержимое писем должно быть в открытом виде, как и в случае использования обычной веб-почты.

    Интерфейс


    Поддерживаются базовые опции форматирования писем: жирный шрифт или курсив, заголовки, списки и возможность редактирования письма непосредственно в HTML.

    Все письма распределяются по папкам: полученные, отправленные и черновики. Просмотреть можно только отдельно выбранное письмо. Отображение отдельной переписки целиком (в виде списка) отсутствует.

    Можно задать получателей копии письма: CC (все видят, кому отправлена копия) и BCC (получателей из данного списка другие получатели не видят в списке копий).


    Стоимость сервиса


    Сервис предоставляется бесплатно, но имеются ограничения на объем хранимых писем (100 мегабайт) и ежемесячное общее количество писем (500 писем). Планируется запустить платные бизнес-аккаунты, у которых будет доступен 1 гигабайт для хранения писем и не будет ограничений на количество писем. В будущем планируется добавить возможность использовать собственный домен для бизнес-аккаунтов.

    Интеграция с другими сервисами и приложениями


    Интеграция с другими сервисами и приложениями отсутствует. Весь функционал реализован на стороне веб-браузера на JavaScript. Открытого API нет.

    Хранение писем


    Полученные и отправленные письма между пользователями ProtonMail хранятся на сервере в зашифрованном виде. На стороне клиента ничего не кешируется и не сохраняется.

    Если письмо получено в открытом виде со стороннего сервиса, то даже после его прочтения оно все равно остается в Inbox в открытом виде.

    Если письмо отправлено на сторонний сервис в открытом виде, то оно сохраняется в папке с отправленными письмами сразу в зашифрованном виде.

    Возможность экспорта писем в архив для скачивания отсутствует.

    Поиск


    Поиск по письмам ищет по имени отправителя, теме письма и по тексту писем, которые хранятся в открытом виде. Напомню, что в открытом виде хранятся только письма, полученные со сторонних сервисов (в незашифрованном виде).

    Хранение ключей шифрования


    Закрытый ключ хранится на серверах сервиса, но защищен вашим почтовым паролем. Это требуется, чтобы была возможность использовать различные устройства (и/или веб-браузеры) для доступа к почте ProtonMail. На стороне веб-браузера клиента в Local Storage ключ не сохраняется.

    Возможность импорта / экспорта ключа отсутствует.

    Техническая реализация


    Основой сервиса стала библиотека OpenPGPjs. На время рабочей сессии почтовый пароль хранится в полностью открытом виде (без обфускации) в Session Storage.

    Сервис использует асимметричное шифрование (систему шифрования с использованием открытых ключей), реализованную на стороне веб-браузера пользователя на JavaScript.

    На Wikipedia есть подробная статья про шифрование с использованием открытых ключей, но, к сожалению, довольно тяжело читается для обычного пользователя без специальных технических знаний.

    Безопасность


    Про безопасность подобных решений на стороне пользователя, когда программный код выдается сервисом при каждом обращении, в интернете можно найти массу обсуждений и статей. Например, статья на английском http://matasano.com/articles/javascript-cryptography/ от Matasano security.

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

    Команда ProtonMail подчеркивает, что они находятся в Швейцарии, где, как они пишут, законодательно их не могу обязать установить backdoor. Полный текст их объяснения доступен по адресу https://protonmail.ch/blog/switzerland/. Но это “в теории”, а “на практике” пока нет широко известных публичных прецедентов.

    В любом случае возможность изменить программный код в любой момент со стороны сервиса является очень серьезным недостатком, так как эти изменения могут быть нацелены на конкретных пользователей. В случае, когда криптография реализована в программном продукте или вообще на уровне операционной системы, то подобные обновления, нацеленные на конкретных пользователей намного менее вероятны и намного тяжелее в реализации. Хотя, как известно, нет 100% безопасных решений, но надо стремиться к максимально возможному необходимому в данной ситуации уровню безопасности.

    Исполняемый код Javascript на стороне браузера может быть подвержен XSS-атакам. В случае с ProtonMail, как и любой другой веб-почтой, можно отправить специально сформированное письмо в обход встроенной защиты от XSS-атак и исполнить вредоносный код, который получит доступ к почтовому паролю пользователя или просто будет перехватывать расшифрованное содержимое сообщений.

    ProtonMail в защите от XSS-атак полагается на библиотеку js-xss. Но помимо фильтрации содержимого письма есть еще и служебные почтовые заголовки, которые можно аналогично сформировать специальным образом при отправлении писем со сторонних сервисов пользователю ProtonMail. А возможность получать письмо со сторонних сервисов есть у всех аккаунтов ProtonMail и запретить ее в настройках аккаунта нельзя.

    В начале июня была найдена уязвимость у сервиса ProtonMail, позволяющая исполнить произвольный JavaScript код на компьютере ничего неподозревающего пользователя и получить полный доступ к его почтовому ящику.

    Данную уязвимость нашел Mike Cardwell, о чем сообщил команде ProtonMail. После исправления уязвимости он опубликовал информацию об этом на ycombinator.com. ProtonMail разместил его имя в списке благодарностей на своем сайте — https://protonmail.ch/blog/protonmail-security-contributors/, что подтверждает данный факт.

    Сейчас данная проблема в безопасности ProtonMail уже исправлена, но сколько еще таких возможностей для хакеров таит в себе реализация криптографии на стороне браузера на JavaScript?

    Подобные проекты


    Mailpile — проект с открытым исходным кодом, активно развивается, является почтовым веб-клиентом (аналогично ProtonMail работает в веб-браузере на JavaScript), который должен сделать доступным использование криптографии пользователям без специальных технических навыков.

    Отдельно следует отметить уникальную возможность данного проекта — поддержку полноценного поиска по зашифрованным сообщениям. На https://www.mailpile.is/faq/ пишут, что создается индекс, а само содержимое индекса хранит в виде хешей.

    Не уточняется, это обычные MD5/SHA хеши или MAC. В случае обычных хешей данное решение по поиску может быть крайне небезопасным из-за возможности установить, какое ключевое слово встречается в зашифрованном тексте, посчитав хеши слов по словарю. Безопасность очень зависит от реализации данного способа.

    Lavaboom — сервис безопасной веб-почты аналогично ProtonMail. Криптография реализована на JavaScript, код исполняется в веб-браузере.

    Scramble — открытый исходный код, реализован на базе OpenPGPjs (аналогично ProtonMail), но относительно молодой проект и не так бурно развивается. Я указал его в этом списке, чтобы дать более полное представление о имеющихся сервисах на рынке.

    OpenMailBox — шифрование реализовано при помощи плагина OpenPGP к проекту почтового веб-клиента Roundcube. Закрытый ключ сохранятся в Local Storage браузера.

    Unseen — использует свою собственную реализацию, есть сервис обмена текстовыми сообщениям и голосовые звонки. Имеются клиенты для мобильных платформ и десктопов.

    Unseen используется также Roundcube с плагином OpenPGP.
    Из десктопных клиентов смотрел версию для Ubuntu и Mac. Это нативные приложения-обертки, в которые внутри встроен “веб-сайт”.

    Что же делать?


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

    Кто сможет реализовать использование криптографии с открытыми ключами в доступном (легком) виде для обычных рядовых пользователей с использованием известных почтовых клиентов (Apple Mail, Microsoft Outlook, встроенные в мобильные ОС почтовые клиенты и другие), тот завоюет любовь пользователей и, безусловно, станет самым успешным сервисом!

    UPD: Большое спасибо за комментарии к статье и вопросы! Дополнил статью.
    Поделиться публикацией
    Комментарии 58
      +1
      Это всё конечно хорошо, но как у него с imap/pop3, gpg, ssl и прочим? Не всем же через веб-клиент сидеть.
        +3
        ProtonMail является исключительно веб-почтой. Поддержки imap/pop3 нет. Веб-интерфейс, естественно, работает через HTTPS. Внутри используется реализация OpenPGP на JavaScript.

        Спасибо за «наводящие» вопросы — обязательно добавлю в статью!
          +8
          Тогда это не email вовсе, а просто защищённый сервис передачи сообщений. С тем же успехом я могу делиться шифрованными файлами (в том числе текстовыми) через seafile, например. При этом сам файл на сервере зашифрован и каждый раз для его прочтения и, соответственно, расшифровки потребуется вводить пароль. Ожидал большего от громких сообщений о нём.
            0
            Веб-почта ;) У довольно многих сервисов веб-почты отсутствует imap/pop3 в бесплатных тарифах. Я сейчас не говорю про Gmail, помимо него есть масса других сервисов тоже. Например, Yahoo mail не предоставляет даже pop3 на бесплатном тарифе, но этой почтой пользуются миллионы людей по всему миру. Кому-то нужен доступ из почтового клиента, а кому-то и веб-почты хватает.

            Так можно использовать практически любой сервис. Например, можно заархивировать с паролем текстовый файл и загрузить на файлообменник, сообщить пароль получателю — он прочитает. Но насколько это удобно конечному пользователю? А в данной ситуации ProtonMail решает данную задачу. Отправить сообщение быстро и легко, пароли сообщить друг другу не надо.

            Основная проблема реализации ProtonMail в том, что это JavaScript и сам код/окружение скриптов ProtonMail никак не ограничено в браузере от содержимого писем, что делает его потенциально уязвимым для XSS-атак, как и любой другой веб-сервис, где есть загрузка пользовательского контента. И второй существенный момент тоже был рассмотрен в статье по поводу возможности внести изменения в программный код со стороны владельцев сервиса в любой момент.
              +2
              Для меня это звучит дико, наверно потому что не сталкивался, по крайней мере яндекс и гугл адекватны в этом плане. Ещё адекватнее собственный сервер.
                +1
                Например, Yahoo mail не предоставляет даже pop3 на бесплатном тарифе,


                Уже где-то год как Yahoo предоставляет POP3 на бесплатных аккаунтах. А IMAP4 и SMTP у Яху на бесплатных аккаунтах есть уже лет семь.
                  +1
                  Спасибо за комментарий! Помню сто лет назад у меня ради именно доступа почтовым клиентом был их платный аккаунт. К сожалению, давно не пользуюсь ими и не уследил момент, что они теперь предоставляют и POP3, и IMAP.
                +2
                Почему это «не email»? Сообщения, отправленные на емейл-адреса и получаемые с емейл-адресов ходят? Ходят. Тогда в чем суть отрицания принадлежности к эл.почте?
                0
                Я правильно понял — это делает клиента такой почты отличной мишенью для sslstrip атаки?
                  0
                  Если осуществить Man-in-the-middle аттаку, то достаточно пользователю показать приглашение для ввода его почтового пароля и получить ответ. Ну или встроить в JavaScript код, который этот пароль отправит.

                  Такой атаке подвержен любой веб-сервис, так как надежность авторизации держится на том, что у злоумышленника не может быть доступа к паролю в открытом виде. Если даже пароль не передается в открытом виде или вообще, как в случае с ProtonMail, не покидает пределы компьютера, то имея возможность вклиниться в поток данных, можно изменить JavaScript и получить заветный пароль.

                  Именно поэтому реализация криптографии на стороне браузера является плохим решением с точки зрения безопасности. Надо, чтобы у злоумышленника не было способа изменить исполняемый код, как минимум. А это значит, что реализация криптографии должна быть вынесена или в отдельное ПО, или хотя бы в плагин к браузеру. Но от социальной инженерии с просьбой ввести почтовый пароль на сайте, а не в ПО это не поможет.
              0
              Если пользователь другого сервиса прислал мне письмо, конечно в открытом виде, я загрузил его в своем браузере с почтовым паролем, после этого полученное в открытом виде письмо удаляется с сервиса ProtonMail и заменяется на свою шифрованную версию?

              Если я отправил письмо на сторонний сервис в открытом виде, сервис удаляет его открытую копию в момент отправки?
                +1
                Если письмо получено в открытом виде (со стороннего сервиса), то даже после его прочтения оно все равно остается в inbox в открытом виде. При повторном прочтение это сообщение передается в открытом виде (проверял по web inspector и содержимому ответа сервера).

                Если отправить письмо на сторонний сервис в открытом виде, то оно сохраняется в отправленных письмах в зашифрованном виде.
                  0
                  Кстати. вот это зря. Могли бы и шифровать =(
                0
                А что там с поиском?
                  +1
                  Поиск работает только по содержимому писем, которые хранятся в незашифрованном виде. А это только полученные в открытом виде со сторонних сервисов. Еще поиск работает по теме писем и имени отправителя.

                  Вспомнил, что когда читал про Mailpile, то особо обратил внимание на то, что он умеет искать по сообщениям. Проверил по информации на их сайте сейчас. Клиент веб-почты Mailpile умеет искать по письмам. На https://www.mailpile.is/faq/ пишут, что создает индекс, а само содержимое индекса хранит в виде хешей.
                    0
                    интереснейший вопрос: как индексировать зашифрованный контент, не разрушая при этом секретности
                      0
                      Есть несколько решений данной задачи. Основное и самое простое — это построить индекс исходного текста, но значения индекса не должны выдавать исходные ключевые слова. На первый взгляд захочется использовать обычную hash-функцию типа MD5/SHA, но это позволит атакующему подобрать ключевые слова, посчитав значения hash-функций для всех слов в словаре. Данное решение не подходит. Но! Есть MAC (http://ru.wikipedia.org/wiki/Имитовставка). Если очень упростить объяснение, то MAC работает как hash-функция, но требуется еще и пароль для ее работы.

                      Соответственно, индексируем письмо на стороне клиента и на сервер отправляем посчитанный индекс для поиска, который пропущен через MAC с почтовым паролем. Когда надо найти что-то, то клиент считать MAC от введенной строки для поиска и отправляет серверу. Сервер не может догадаться, что ищет клиент по этому значению, и выдает список документов из индекса, в которых встречалось введенное ключевое слово.

                      Получаем, что:
                      1. Сервер не знает, что в индексе
                      2. Сервер не знает, что просят искать
                      3. Нельзя восстановить содержимое индекса путем расчета значения hash-функции для всех слов по словарю
                      4. У всех пользователей одно и то же слово даст разный hash. Имея значения для одного пользователя нельзя получить доступ к данным другого пользователя.

                      Упрощенный пример реализации на SQL (демонстрация идеи):
                      http://blogs.msdn.com/b/raulga/archive/2006/03/11/549754.aspx
                    0
                    Меня вот интересует другой вид «атаки». Предположим, IBM Switzerland принимает решение купить сервис ProtonMail вместе с производящей компанией. Что будет дальше? Ведь спецслужбы «демократических» государств типа США могут поставить под вопрос деятельность компании на территории США, если компания не предоставит данные, пусть они и хранятся в другой стране.
                      0
                       В данном вопросе можно только рассуждать о возможных событиях, наверное. К сожалению, не располагаю информацией о подобных прецедентах. Если в комментариях кто-то может подсказать, то было бы супер.

                      Самое простое решение я вижу в виде блокировки сервиса на уровне IP. До блокировки домена добраться так легко не получится, так как он не в зоне .com/.net/.org. Вопрос с доменами в этих зонах решается очень быстро, потому что корневые DNS-сервера в юрисдикции США. Но это уже сильно негативно скажется на гос. структурах, которые этого будут добиваться. Обострят отношения тоже просто так никто не будет. Особенно, на фоне всех последних скандалов.

                      Думаю, что самым логичным будет, что придумают какое-то решение, которое «заблокирует» данную сделку и/или очень усложнит жизнь сервису. Аналогично тому, как создают списки, с кем нельзя вести дел, так как угрожают национальной безопасности или противостоят интересам государства.

                      Я думаю, что это уже вопрос больше политический. В этом плане децентрализованные системы, конечно, имеют преимущество. Но, к сожалению, их вряд ли можно назвать дружелюбными для конечного рядового пользователя. А производители устройств типа Apple или Samsung я очень сомневаюсь, что добавят поддержку Tor в устройства :) Поэтому пользователю надо выбирать, насколько серьезную защиту и от кого он хочет. Чем больше уровень защиты — тем сложнее, как правило, все системы в использовании, как бы ни старались их упрощать, увы…
                        0
                        Америка даже Швейцарские банки нагнула… (правда пока только для граждан США, но это пока) Надо будет накрыть ITшную компанию — и её нагнут…
                        www.audit-it.ru/news/finance/691278.html

                        Я думаю не стоит обольщаться. Бесплатного сыра не бывает. Хочешь безопасности — устрой её себе сам или спонсируй деньгами того, кто её тебе устроит…
                          0
                          Да, кстати, во многих случаях решение, размещающееся на собственных серверах, и при этом правильно организованное, будет иметь несомненно массу преимуществ для компаний. Хотя бы дать полный контроль над тем, как работает сервис и что на нем когда изменяется и зачем. Во многих случаях это будет уже больше напоминать паранойю, но надо отталкиваться от задачи (от кого защищаются).
                        0
                        А в чём проблема предоставления данных? Вот получили в ЦРУ ваше зашифрованное сообщение, и что дальше?
                          +1
                          Зашифрованное сообщение получили — это не будет проблемой. А вот сопутствующие метаданные (кто и кому отправил письмо), прикрепленные файлы (они сейчас не шифруются) будут являться проблемой.

                          Еще самой большой проблемой будет, если попросят «исправить» немного код JavaScript их сервиса для конкретного пользователя, который их интересует, так как не найдут интересующей их информации в предоставленных зашифрованных данных. Скажут, что им пароля не хватает. А как его получить — сами думайте, ведь, это ваш сервис ;)

                          Необходимо, чтобы возможности получить удаленный доступ к незашифрованным сообщениям не было вообще. Разумеется, кроме физического доступа к конечному устройство. В этом случае уже ничего не поможет ;) А вот с возможностью относительно легкого перехвата доступа (в случае наличия желания у сервиса) у всех подобных сервисов как раз большая проблема.
                            +1
                            Все верно. Поэтому почтовый сервер вообще не должен участвовать в процессе шифрования-дешифрования. Включая javascript, который хоть и исполняется локально, но генерируется сервером.

                            Поэтому, идеальное решение на сегодня — GnuPG+Thunderbird+Enigmail. Заодно и файлы шифруются.
                            Менее идеальное — расширение mailvelope. Почтовый сервер в теории не участвует в его работе. Хотя в некоторых случаях mailvelope не срабатывает именно из-за конфликта с javascript-ом от сервера, что наводит на мысль, что злобный хакер от северокорейской службы безопасности может как-то перехватить процесс шифрования-дешифрования от mailvelope именно с помощью javascript-a сгенерированного compromised емаил сервисом…
                              0
                              Полностью согласен с предложенным «идеальным» решением. Есть одно «но». GnuPG+Thunderbird+Enigmail — это очень сложно для обычного рядового пользователя, который хочет безопасную почту, поэтому и приходится искать компромиссы.

                              В принципе, поддержка S/MIME есть во всех основных почтовых клиентах. Проблема в настройки почтового клиента пользователем — не смогут это сделать большинство. В самих ОС хранение ключей реализовано достаточно надежно. Но в любом случае основная проблема безопасности в этом случае будет заключаться в «авторизации» пользователя. То есть, чтобы никакая malware не утащила ключ с паролем, а «злоумышленник» не смог зайти в почтовый ящик имея весь этот комплект. Для решения этой задачи требуется уже двухфакторная авторизация.

                              Но и даже в этом случае, обратившись с «просьбой» к владельцам сервиса, можно получить очередной одноразовый пароль.

                              Резюме: надо знать, от кого защищаться. Одно дело от NSA, другое — от правоохранительных органов локальных, а совсем другое — от конкурентов в бизнесе и прочих сомнительных личностей. В зависимости от этого и определять, каких мер должно быть достаточно.
                                0
                                Для обычного пользователя пользоваться почтовым клиентом тоже сложно. Где-то видел статистику: 95% домашних пользователей читают почто через веб интерфейс. С другой стороны, я не согласен насчет сложности: хотя-бы потому, что настройка — одноразовое действие. Я своему пожилому папе настроил Thunderbird с Enigmail-ом и теперь он этого GPG даже не замечает. Мне это было нужно, чтобы он посылал мне всякие отсканированные документы, счета и т.д.
                                  0
                                  Настройка — одноразовое действие, если не происходит смена устройства, переустановка операционной системы (что очень любят делать многи компании по технической поддержке в любом удобном случае), потенциально может что-то измениться в программном комплексе, что потребуется от пользователя какой-то реакции. А первый вопрос вызовет в большинстве случаев нажатие первой попавшейся кнопки или ступор.

                                  Все это становится в разы сложнее, когда устройств много в компании. И чем сложнее обслуживание, тем больше вероятность нарушение регламента работы с ПО. Еще есть «хотелки» в стиле том, что кто-то привык использовать XYZ для чтения почты, и ZYX ему вообще не нравится. К сожалению, в компаниях с подобными трудностями приходится сталкиваться постоянно.

                                  И довольно тяжело произвести такую настройку удаленно. Да, есть удаленный рабочий стол и т.п. Но объяснить недоверчивому и технически плохо представляющему пользователю, как это все работает (который слышал про безопасные веб-сервисы), зачем ему это все делают, является очень сложной задачей.
                          0
                          Спецслужбы США ни секунды не совмневаясь изымут все сервера с паролями этого сервиса, если на то будет определенная необходимость.

                          Не «просто захотелось», а «действительно нужно».

                          Фирменная швейцарская банковская тайна без особого шума канула в Лету, когда США сказали: хватит секретничать, давайте сюда отчетность.
                            0
                            Именно поэтому сервис может считаться «безопасным» только в случае, если даже изъятие серверов не нарушит безопасность пользователей. То есть не должно быть никакой потенциальной возможности получить доступ к данным пользователей. А в подобной реализации достаточно добавить одну строку кода на JavaScript, чтобы отправить почтовый пароль пользователя куда-то за пределы его компьютера.

                            В противном случае это напоминает игру в кошки-мышки. Сегодня они в Швейцарии, так как туда «не доберутся» по их словам, завтра — на околоземной орбите спутник :)

                            Несомненно, такое криптографическое решение имеет право на существование, но не думаю, что стоит его описывать столь громкими заявлениями, как это делается ими в пресс-релизах. Надо отметить, что PR-команда у них работает на «отлично».
                          +1
                          добрый дядечка Стив Гибсон очень мило описал этот сервис в Episode #456 подкаста security now. Основной вывод: это не TNO: сами они могут получить содержание писем, а вся их серьёзная позиция протмв NSA держится на том, что они просто не в USA
                            0
                            Большое спасибо за ссылку на эпизод подкаста! Прослушал данную часть — очень интересно. Если кому-то нужен в текстовом виде, то по ссылке https://www.grc.com/sn/sn-456.pdf есть PDF.

                            Как я его понимаю, то его выводы заключаются в том, что:
                            1. Необходимо шифрование устройство-устройство (к этому все и идет)
                            2. Проблема в том, что метаинформация (заголовки писем, кто и с кем общается) все так и остаются в открытом виде
                            3. Надежная авторизация, чтобы быть уверенным, что именно только получатель письма может получить доступ к содержимому, а не кто-то, кто смог перехватить пароль.

                            Именно эти 3 составляющих необходимы для надежного решения.
                            +2
                            Я бы посоветовал еще два сервиса: runbox.com (платный, $20 в год, сервера в Норвегии) и бесплатный (openmailbox.org, сервера во Франции). У обоих есть поддержка OpenPGPjs в roundcube Larry интерфейсе (есть разные интефейсы у них). Генерируешь пару private-public key (или импoртируешь существующие ключи с компьютера), ключи сохраняются в persistent storage браузера и можно спокойно шифровать сообщения. Аналог расширения enigmail для Thunderbird.

                            Нет привязки к конкретному компьютеру — главное иметь PGP/GPG ключи под рукой. Хотя в опеределенных ситуациях это может быть и недостатком.

                            Я пользуюсь обоими сервисами. Имейте ввиду — openmailbox существует менее года, с техподдержкой — не очень, но функционально он чуть лучше, ИМХО (пользовательские фильтры намного лучше), чем runbox. С другой стороны, Runbox — заслуженный устоявшийся сервис с отличной техподдержкой.

                            Еще два сервиса, построенные по этому принципу (Roundcube/OpenPGPjs):

                            autistici.com — при регистрации требуется указать политические взгляды — нужно быть антифашистом, антирасистом, любить животных и бороться со всемирным потеплением. Иначе не прийдет емаил с линком активации.

                            unseen.is — в топку, т.к. они закачивают ваш private key на свои сервера. Я спросил техподдержку «вы что, совсем охренели?», но ответа не получил.

                            Ну и расширение для Хрома и Файрфокса Mailvelope: работает с большинством сервисов webmail и даже с форумами, досками объявлений, pastebin, Фейсбуком и одноклассниками. K сожалению, не так удобно, как встроенный PGP в Roundcube или enigmail в Thinderbird, но вполне юзабельно.

                            Недостаток всех подобных сервисов: они не поддерживают шифрование прикрепленных файлов, и, в большинстве случаев (зависит от сервиса) не поддерживают (не шифруют) HTML текст. Решение: только Thunderbird +Enigmail + GnuPG.
                              0
                              Соберу вместе весь список сервисов и обязательно обновлю статью. Большое спасибо за данную информацию!
                                0
                                Главное не забывать в thunderbird черновики хранить ЛОКАЛЬНО, потому как по умолчанию если включен IMAP оно не зашифрованный текст сохраняет в черновиках на сервере и толку от такого шифрования никакого. Случайно это заметил недавно, почувствовал себя идиотом.

                                А так да, шифровать лучше всё локально на компьютере и лишь потом отправлять. А уж доверять секретные ключи браузерам в которых багов больше чем функций — тем более. Хотя и thunderbird не самый лучший вариант. Намного лучше mutt+openpgp, но не всем так удобнее.
                                  0
                                  Главное не забывать в thunderbird черновики хранить ЛОКАЛЬНО, потому как по умолчанию если включен IMAP оно не зашифрованный текст сохраняет в черновиках на сервере и толку от такого шифрования никакого. Случайно это заметил недавно, почувствовал себя идиотом.


                                  Хммм. Что я делаю не так

                                  image

                                  насчет Mutt: он же text-based email client. мягко говоря, очень неудобно
                                    0
                                    Ну а вы попробуйте набирать сообщение долго (пару минут) и посмотрите в «черновики» на gmail (если вы его используете).

                                    Проблема в том, что в момент написания письма оно не шифруется, шифруется лишь когда написано, перед самой отправкой. А thunderbird если работает через IMAP производит по умолчанию автосохранение удалённо, поэтому всё что вы пишете сохраняется без шифрования в черновиках. Для того чтобы этого не было нужно отключить удалённое автосохранение и поставить локальное.

                                    По поводу mutt. Не знаю, мне редко когда письма с хтмл приходят. Если и приходят то обычно спам, или подписки, которых я не заказывал. Но большинство любит html в письмах, поэтому mutt отпадает.
                                      0
                                      В данном примере я использую IMAP account на runbox.com с автосохранением через 5 минут. Как вы видите, Thunderbird c Enigmail спрашивают, в каком виде сохранить сообщение. С gmail-ом не пробовал — мне что-то не хочется синхронизировать свои гигабайты локально.В случае с «ручным» save Thunderbird предлагает то же самое — шифроваться или нет.
                                        0
                                        Странно, у меня такого сообщения не было ранее. Либо добавили недавно, либо у меня какой-то баг тогда был.
                                  0
                                  runbox.com не предоставляет шифрование почты, как я понял из его описания и пробного аккаунта. Только обычное HTTPS соединение. Но зато самая навороченная админка. Можно очень много чего настроить.
                                    0
                                    И них есть «скрытый интерфейс» с PGP шифрованием. Runbox просит его не афишировать, поэтому я даю ссылку вам в ЛС.
                                      0
                                      А, да, Roundcube с OpenPGP аналогично openmailbox.org
                                  0
                                  Наличие возможности отправить зашифрованный email любому получателю за пределами ProtonMail. В этом случае получателю приходит письмо со ссылкой, перейдя по которой получателю предлагается ввести пароль для доступа к содержимому письма. Данный пароль задает отправитель перед отправлением письма с сервиса ProtonMail.


                                  Очень неудобно — проверено неоднократно. Во-первых, остается вопрос, как передать этот пароль адресату. Во-вторых, секретарши в этой ситуации входят в ступор. Тем не менее, такая опция есть как минимум еще у одного сервиса safe-mail.net (сервера в Израиле)

                                  Возможность задать время хранения письма. Данная возможность доступна при перепискке с другими пользователями ProtonMail и отправке шифрованных писем на сторонние почтовые сервисы (получателю приходит ссылка для чтения письма на сайте ProtonMail). По истечению данного времени письмо удаляется.


                                  А это как раз очень удобно и я часто этим пользуюсь. Пользуюсь этим для пересылки финансовой и другой важной информации: если компьютер у секретарши/бухгалтера/Васи Пупкина взломают, то к этой информации доступа не будет. Но насколько ю понимаю, в этом случае получатель должен на что-то кликнуть в теле письма, чтобы получить текст письма (ведь текст хранится на сервере). И тут секретарши опять входят в ступор.

                                  Опять-таки, такая опция есть у сервиса safe-mail.net
                                    0
                                    Очень неудобно — проверено неоднократно. Во-первых, остается вопрос, как передать этот пароль адресату. Во-вторых, секретарши в этой ситуации входят в ступор.

                                    Да, проблема передачи пароля ставит данное решение в один ряд с загрузкой архива с паролем на любой общедоступный сервис (или пересылку его по email). Но уверен, что с точки зрения маркетинга это является хорошим ходом, так как легко использовать в качестве invite'ов — своеобразного завлечения на сервис новых пользователей.

                                    А это как раз очень удобно и я часто этим пользуюсь. Пользуюсь этим для пересылки финансовой и другой важной информации: если компьютер у секретарши/бухгалтера/Васи Пупкина взломают, то к этой информации доступа не будет. Но насколько ю понимаю, в этом случае получатель должен на что-то кликнуть в теле письма, чтобы получить текст письма (ведь текст хранится на сервере). И тут секретарши опять входят в ступор.


                                    Здесь может быть две ситуации:
                                    1. Письмо самоудаляющееся было отправлено на сторонней сервис. Пришла ссылка на сайт ProtonMail. По истечению срока жизни письма сервис удаляет его у себя. По ссылке получить доступ к письму становится более невозможным. Данный сценарий полностью аналогичен отправлению зашифрованных паролем писем на сторонний сервис, когда получателю приходит ссылка на сайт ProtonMail.

                                    2. Письмо отправляется от одного пользователя ProtonMail другому. В этом случае после истечения времени оно будет удалено на сервисе. Работа с таким письмом никак не отличается от работы с письмом без даты уничтожения для пользователей ProtonMail. Никаких лишних кликов.
                                    0
                                    Почтовый пароль не отправляется за пределы компьютера пользователя и используется в процессе генерации ключа для шифрования в последующем. Данный пароль не подлежит “восстановлению”. Если он утерян, то доступ к содержимому почтового ящика будет утерян вместе с ним. Забегая немного вперед, следует отметить, что изменить данный пароль не представляется возможным, о чем сказано на странице вопросов-ответов.


                                    A вот это — плохо. По этому же принципу, кстати, работал unseen.is. До недавнего времени он тоже не позволял менять сгенерированный private key и пароль от него.

                                    Плохо вот почему:

                                    1. Скорее всего, private key хранится на сервере. Для меня это делает использования сервиса для серьезных целей невозможным (да, есть пароль, но мне все равно неуютно).
                                    2. Нельзя убрать/изменить private key (пароль от него). Я понимаю, это сделано для того, чтобы сохранить доступ к старым сообщениям, но иногда лучше наоборот — не допустить доступа к старым сообщениям.
                                    3. Даже бэкап ключа сделать нельзя?
                                      +1
                                      1. Скорее всего, private key хранится на сервере. Для меня это делает использования сервиса для серьезных целей невозможным (да, есть пароль, но мне все равно неуютно).

                                      Проверил по исходникам на JavaScript. Когда открываем сообщение для чтения, то в коде страницы в hidden полях формы передается private key, защищенный паролем почтового ящика. Далее из сессионного хранилища берется введнный пароль почтового ящика и запускается дешифровка сообщения.

                                      2. Нельзя убрать/изменить private key (пароль от него). Я понимаю, это сделано для того, чтобы сохранить доступ к старым сообщениям, но иногда лучше наоборот — не допустить доступа к старым сообщениям.

                                      Да, думаю сделано именно, чтобы сохранить доступ к старым сообщениям. Иначе придется каждое сообщение на стороне браузера в момент смены ключа дешифровать и заново шифровать новым ключом.

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

                                      3. Даже бэкап ключа сделать нельзя?

                                      Официально нет такой возможности, да и импорта своего ключа тоже нет при регистрации. Но выдернуть его из кода страницы можно ;)
                                      0
                                      Проверил по исходникам на JavaScript. Когда открываем сообщение для чтения, то в коде страницы в hidden полях формы передается private key, защищенный паролем почтового ящика. Далее из сессионного хранилища берется введнный пароль почтового ящика и запускается дешифровка сообщения.


                                      Я так и думал (точно так же работает unseen.is). Мне трудно судить, насколько надежен такой поход (защищенный паролем ключ, не поддающийся уничтожению/замене, хранящийся на сервере), но моя паранойя говорит, что это плохо по двум причинам:

                                      1. Если пароль и сертификат скомпрометированы, то всё — ничего сделать нельзя. Что в этом случае — менять почтовый адрес?
                                      2. Злоумышленник, имеющий доступ к серверу (и приватному ключу) может модифицировать javascript и перехватить пароль.

                                      И тут моя паранойя выходит на новый уровень: я упоминал сервисы runbox.com и openmailbox.org. Oни хранят ключи на не на сервере, а локально. Но что мешает злобному хакеру, имеющему контроль над сервером, изменить javascript и получить private key из local storage с паролем впридачу?

                                      Тут вопрос web разработчикам: возможно ли получить private key в этом сценарии без дополнительных подтверждений со стороны пользователя? Для исследования можно зарегистрировать <бесплатный> аккаунт на openmailbox.org.

                                      Вопрос принципиальный: если это возможно, то все подобные решения (runbox, openmailbox) ничего не стоят.

                                      Mailvelope в этом смысле более надежный — сервер по определению не имеет доступа к его коду (по крайней мере, не должен иметь доступ, если нет какой-то уязвимости в браузере).
                                        0
                                        1. Если пароль и сертификат скомпрометированы, то всё — ничего сделать нельзя. Что в этом случае — менять почтовый адрес?

                                        В данном решение от ProtonMail на текущем этапе получается именно так. Причем, о том, что пароль нельзя сменить они пишут еще при регистрации, чтобы, видимо, не ставили временных тестовых паролей в надежде поменять позднее.

                                        2. Злоумышленник, имеющий доступ к серверу (и приватному ключу) может модифицировать javascript и перехватить пароль. И тут моя паранойя выходит на новый уровень.

                                        Совершенно согласен. Об этом я как раз в статье и писал, что проблема всех подобных решений в том, что достаточно встроить перехват пароля (и/или приватного ключа) из сессионного хранилища веб-браузера (одна строка кода) либо на стороне сервера, либо через XSS, либо через malware.

                                        Про openmailbox.org отвечу отдельным комментарием. Пойду посмотрю сейчас.

                                        Но до тех пор пока сама система, выполняющая шифрование, пересекается «пространством» со сторонним кодом, эта является самый большой дырой в безопасности. Именно поэтому решения с плагинами или отдельным специальным ПО являются единственным правильным путем, так как криптографическое ПО работает по принципу черного ящика для содержимого страницы.
                                          0
                                          Про openmailbox.org.

                                          Является решением на базе Roundcube и плагина к нему OpenPGP. Данный плагин хранит ключи в Local storage браузера. Отличие от Session storage, которое использует ProtonMail в том, что данные в Local Storage сохраняются между сессиями. Это требуется для постоянно хранения ключей там.

                                          Но доступ к данному хранилищу (Local и Session storage) есть из любого JavaScript и, безусловно, malware на компьютере пользователя. Единственное ограничение доступа same-origin-policy. То есть, чтобы получить доступ к данным в local или session storage бразуера, скрипт должен быть получен с того же домена и протокола (http / https), но путь к скрипту при этом может быть другой.

                                          Соответственно, браузер никаких вопросов не задаст пользователю, если получит кусок кода для извлечения данных оттуда с этого же домена. Браузер не сможет отличить вредоносный код от реального кода сервиса. Это же применимо и к XSS-атакам. Если удастся воткнуть зловредный JavaScript в страницу каким-либо способом, то на этом вся безопасность заканчивается.

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

                                          Ссылки по теме:
                                          1. https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage
                                          2. http://www.drdobbs.com/web-development/the-localstorage-api/240000682
                                            0
                                            Тогда все эти сервисы очень проблематичны с точки зрения криптографии. По крайней мере, они не защищают от человека или группы людей имеющих контроль над сервером. Возможно, с юридической точки зрения они лучше, чем mail.ru или yahoo.com, но мы сейчас обсуждаем техническую стороны дела.
                                              0
                                              Совершенно верно! У всех подобных сервисов слишком много потенциальных проблем. Их надо стараться минимизировать. Но такие сервисы востребованы и будут существовать, так как пользователи хотят «простых» решений. Найти грань очень тяжело — уж очень она тонкая в этих вопросах. Все зависит от задачи.
                                            0
                                            Тогда подход должен быть: не использовать web mail для защищенной почты (имеется ввиду PGP шифрование), не хранить ключи в браузере и, тем более, на сервере. Остаются решения типа GnuPG в связке с Enigmail и Thunderbird как наиболее легкие (хотя все равно не простые) для конечного пользователя (а также кроссплатформенные и опенсорсные).
                                              0
                                              Да, именно так.

                                              В статье приводил ссылку http://matasano.com/articles/javascript-cryptography/ , где очень хорошо последовательно даются ответы на все потенциальные вопросы, объясняя, что все подобные решение на стороне браузера, где код скрипта отдается сервисом, имеют массу недостатков.

                                              Нативные приложения (почтовые клиенты, встроенные в ОС, и отдельные приложения) и, естественно, open-source решения. Если мы говорим только про атаки со стороны хакеров, а не государственных служб, то потенциальные «закладки» в закрытом ПО можно не рассматривать. Подобные закладки имеют практическое применение только у тех, кто про них знает, а это очень узкий круг людей. Хотя, как показывает практика, и до open-source тоже добрались. Из последних примеров — реализация проверки сертификата в openssl. Хотя может быть и обычной ошибкой ;) Это тема для отдельной дискуссии.
                                          0
                                          Вы меня простите, может быть я что-то не понимаю, но в чём проблема использовать любой почтовый сервис и шифровать письма через PGP? Или вся соль «Протона» в простоте для пользователя? Оно конечно хорошо, да только вряд ли домохозяйкам нужно шифровать рецепты пирогов.
                                            0
                                            Решения для криптографии уже давно существуют. Проблема, как вы совершенно справедливо заметили, именно в том, что очень тяжело научить среднестатистического пользователя их использовать.

                                            Домохозяйкам шифровать рецепты пирогов, наверное, не требуется. Если нет паранойни у них ;) А то всякое бывает…
                                            А вот во многих компаниях большая часть документаоборота осуществляется по email без шифрования. Далее воображение может очень далеко зайти в том, какие беды и несчастья могут причинить те, кто завладеют конфиденциальной информацией.

                                            Еще существенный момент во всей истории — установить подлинность отправителя письма. Именно поэтому так важно сделать грамотно и механизм авторизации, чтобы нельзя было злоумышленнику создать и отправить письмо от имени скомпрометированного почтового ящика. Например, одна компания ждет реквизиты для оплаты, а злоумышленник отправляет свое письмо со своими реквизитами, так как ранее получил доступ к паролю почтового ящика отправителя.
                                            0
                                            Где же видео с процессом регистрации?
                                              0
                                              Я решил, что читателям не будет интересно смотреть на появляющиеся «звездочки» пока я заполняю поля для установки паролей. А вот видео использования сервиса, наверное, будет интересно читателям. Если будет интерес у сообщества, и получится по времени у меня, то постараюсь сделать. Может быть в интернете уже есть? Поделитесь ссылками, если кто знает.
                                              0
                                              Невозможность сменить пароль от ящика — это критический недостаток. Стоит один раз скомпроментировать свой пароль и все — неограниченный доступ злоумышленника к почте, а вам останется лишь в панической спешке наперегонки с ним удалять свои тайны с сервиса.
                                                0
                                                У них есть пароль для авторизации на сайте. Он изменяется. Достаточно его изменить и получить доступ на сайт станет невозможным. Но, получив почтовый пароль, злоумышленник сможет расшифровать сообщения, доступ к которым у него будет в силу каких-либо причин.

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

                                              Самое читаемое