Полностью согласен с предложенным «идеальным» решением. Есть одно «но». GnuPG+Thunderbird+Enigmail — это очень сложно для обычного рядового пользователя, который хочет безопасную почту, поэтому и приходится искать компромиссы.
В принципе, поддержка S/MIME есть во всех основных почтовых клиентах. Проблема в настройки почтового клиента пользователем — не смогут это сделать большинство. В самих ОС хранение ключей реализовано достаточно надежно. Но в любом случае основная проблема безопасности в этом случае будет заключаться в «авторизации» пользователя. То есть, чтобы никакая malware не утащила ключ с паролем, а «злоумышленник» не смог зайти в почтовый ящик имея весь этот комплект. Для решения этой задачи требуется уже двухфакторная авторизация.
Но и даже в этом случае, обратившись с «просьбой» к владельцам сервиса, можно получить очередной одноразовый пароль.
Резюме: надо знать, от кого защищаться. Одно дело от NSA, другое — от правоохранительных органов локальных, а совсем другое — от конкурентов в бизнесе и прочих сомнительных личностей. В зависимости от этого и определять, каких мер должно быть достаточно.
1. Скорее всего, private key хранится на сервере. Для меня это делает использования сервиса для серьезных целей невозможным (да, есть пароль, но мне все равно неуютно).
Проверил по исходникам на JavaScript. Когда открываем сообщение для чтения, то в коде страницы в hidden полях формы передается private key, защищенный паролем почтового ящика. Далее из сессионного хранилища берется введнный пароль почтового ящика и запускается дешифровка сообщения.
2. Нельзя убрать/изменить private key (пароль от него). Я понимаю, это сделано для того, чтобы сохранить доступ к старым сообщениям, но иногда лучше наоборот — не допустить доступа к старым сообщениям.
Да, думаю сделано именно, чтобы сохранить доступ к старым сообщениям. Иначе придется каждое сообщение на стороне браузера в момент смены ключа дешифровать и заново шифровать новым ключом.
Хотя для смены пароля можно расшифровать приватный ключ и зашифровать его с новым паролем на стороне браузера. И отправить им зашифрованный новый приватный ключ для хранения на сервисе. Им надо будет только обновить у себя его (а старый удалить безвозвратно), чтобы в следующий раз новый пароль сработал. Вот почему это не реализовано я затрудняюсь сказать. Возможно, связано с тем, как они хранят данные. Но это решаемая задача. Приватный ключ не изменится, а изменится только пароль, которым он защищен.
3. Даже бэкап ключа сделать нельзя?
Официально нет такой возможности, да и импорта своего ключа тоже нет при регистрации. Но выдернуть его из кода страницы можно ;)
Зашифрованное сообщение получили — это не будет проблемой. А вот сопутствующие метаданные (кто и кому отправил письмо), прикрепленные файлы (они сейчас не шифруются) будут являться проблемой.
Еще самой большой проблемой будет, если попросят «исправить» немного код JavaScript их сервиса для конкретного пользователя, который их интересует, так как не найдут интересующей их информации в предоставленных зашифрованных данных. Скажут, что им пароля не хватает. А как его получить — сами думайте, ведь, это ваш сервис ;)
Необходимо, чтобы возможности получить удаленный доступ к незашифрованным сообщениям не было вообще. Разумеется, кроме физического доступа к конечному устройство. В этом случае уже ничего не поможет ;) А вот с возможностью относительно легкого перехвата доступа (в случае наличия желания у сервиса) у всех подобных сервисов как раз большая проблема.
Спасибо за комментарий! Помню сто лет назад у меня ради именно доступа почтовым клиентом был их платный аккаунт. К сожалению, давно не пользуюсь ими и не уследил момент, что они теперь предоставляют и POP3, и IMAP.
Большое спасибо за ссылку на эпизод подкаста! Прослушал данную часть — очень интересно. Если кому-то нужен в текстовом виде, то по ссылке https://www.grc.com/sn/sn-456.pdf есть PDF.
Как я его понимаю, то его выводы заключаются в том, что:
1. Необходимо шифрование устройство-устройство (к этому все и идет)
2. Проблема в том, что метаинформация (заголовки писем, кто и с кем общается) все так и остаются в открытом виде
3. Надежная авторизация, чтобы быть уверенным, что именно только получатель письма может получить доступ к содержимому, а не кто-то, кто смог перехватить пароль.
Именно эти 3 составляющих необходимы для надежного решения.
В данном вопросе можно только рассуждать о возможных событиях, наверное. К сожалению, не располагаю информацией о подобных прецедентах. Если в комментариях кто-то может подсказать, то было бы супер.
Самое простое решение я вижу в виде блокировки сервиса на уровне IP. До блокировки домена добраться так легко не получится, так как он не в зоне .com/.net/.org. Вопрос с доменами в этих зонах решается очень быстро, потому что корневые DNS-сервера в юрисдикции США. Но это уже сильно негативно скажется на гос. структурах, которые этого будут добиваться. Обострят отношения тоже просто так никто не будет. Особенно, на фоне всех последних скандалов.
Думаю, что самым логичным будет, что придумают какое-то решение, которое «заблокирует» данную сделку и/или очень усложнит жизнь сервису. Аналогично тому, как создают списки, с кем нельзя вести дел, так как угрожают национальной безопасности или противостоят интересам государства.
Я думаю, что это уже вопрос больше политический. В этом плане децентрализованные системы, конечно, имеют преимущество. Но, к сожалению, их вряд ли можно назвать дружелюбными для конечного рядового пользователя. А производители устройств типа Apple или Samsung я очень сомневаюсь, что добавят поддержку Tor в устройства :) Поэтому пользователю надо выбирать, насколько серьезную защиту и от кого он хочет. Чем больше уровень защиты — тем сложнее, как правило, все системы в использовании, как бы ни старались их упрощать, увы…
Веб-почта ;) У довольно многих сервисов веб-почты отсутствует imap/pop3 в бесплатных тарифах. Я сейчас не говорю про Gmail, помимо него есть масса других сервисов тоже. Например, Yahoo mail не предоставляет даже pop3 на бесплатном тарифе, но этой почтой пользуются миллионы людей по всему миру. Кому-то нужен доступ из почтового клиента, а кому-то и веб-почты хватает.
Так можно использовать практически любой сервис. Например, можно заархивировать с паролем текстовый файл и загрузить на файлообменник, сообщить пароль получателю — он прочитает. Но насколько это удобно конечному пользователю? А в данной ситуации ProtonMail решает данную задачу. Отправить сообщение быстро и легко, пароли сообщить друг другу не надо.
Основная проблема реализации ProtonMail в том, что это JavaScript и сам код/окружение скриптов ProtonMail никак не ограничено в браузере от содержимого писем, что делает его потенциально уязвимым для XSS-атак, как и любой другой веб-сервис, где есть загрузка пользовательского контента. И второй существенный момент тоже был рассмотрен в статье по поводу возможности внести изменения в программный код со стороны владельцев сервиса в любой момент.
Поиск работает только по содержимому писем, которые хранятся в незашифрованном виде. А это только полученные в открытом виде со сторонних сервисов. Еще поиск работает по теме писем и имени отправителя.
Вспомнил, что когда читал про Mailpile, то особо обратил внимание на то, что он умеет искать по сообщениям. Проверил по информации на их сайте сейчас. Клиент веб-почты Mailpile умеет искать по письмам. На https://www.mailpile.is/faq/ пишут, что создает индекс, а само содержимое индекса хранит в виде хешей.
Если письмо получено в открытом виде (со стороннего сервиса), то даже после его прочтения оно все равно остается в inbox в открытом виде. При повторном прочтение это сообщение передается в открытом виде (проверял по web inspector и содержимому ответа сервера).
Если отправить письмо на сторонний сервис в открытом виде, то оно сохраняется в отправленных письмах в зашифрованном виде.
ProtonMail является исключительно веб-почтой. Поддержки imap/pop3 нет. Веб-интерфейс, естественно, работает через HTTPS. Внутри используется реализация OpenPGP на JavaScript.
Спасибо за «наводящие» вопросы — обязательно добавлю в статью!
В принципе, поддержка S/MIME есть во всех основных почтовых клиентах. Проблема в настройки почтового клиента пользователем — не смогут это сделать большинство. В самих ОС хранение ключей реализовано достаточно надежно. Но в любом случае основная проблема безопасности в этом случае будет заключаться в «авторизации» пользователя. То есть, чтобы никакая malware не утащила ключ с паролем, а «злоумышленник» не смог зайти в почтовый ящик имея весь этот комплект. Для решения этой задачи требуется уже двухфакторная авторизация.
Но и даже в этом случае, обратившись с «просьбой» к владельцам сервиса, можно получить очередной одноразовый пароль.
Резюме: надо знать, от кого защищаться. Одно дело от NSA, другое — от правоохранительных органов локальных, а совсем другое — от конкурентов в бизнесе и прочих сомнительных личностей. В зависимости от этого и определять, каких мер должно быть достаточно.
Проверил по исходникам на JavaScript. Когда открываем сообщение для чтения, то в коде страницы в hidden полях формы передается private key, защищенный паролем почтового ящика. Далее из сессионного хранилища берется введнный пароль почтового ящика и запускается дешифровка сообщения.
Да, думаю сделано именно, чтобы сохранить доступ к старым сообщениям. Иначе придется каждое сообщение на стороне браузера в момент смены ключа дешифровать и заново шифровать новым ключом.
Хотя для смены пароля можно расшифровать приватный ключ и зашифровать его с новым паролем на стороне браузера. И отправить им зашифрованный новый приватный ключ для хранения на сервисе. Им надо будет только обновить у себя его (а старый удалить безвозвратно), чтобы в следующий раз новый пароль сработал. Вот почему это не реализовано я затрудняюсь сказать. Возможно, связано с тем, как они хранят данные. Но это решаемая задача. Приватный ключ не изменится, а изменится только пароль, которым он защищен.
Официально нет такой возможности, да и импорта своего ключа тоже нет при регистрации. Но выдернуть его из кода страницы можно ;)
Еще самой большой проблемой будет, если попросят «исправить» немного код JavaScript их сервиса для конкретного пользователя, который их интересует, так как не найдут интересующей их информации в предоставленных зашифрованных данных. Скажут, что им пароля не хватает. А как его получить — сами думайте, ведь, это ваш сервис ;)
Необходимо, чтобы возможности получить удаленный доступ к незашифрованным сообщениям не было вообще. Разумеется, кроме физического доступа к конечному устройство. В этом случае уже ничего не поможет ;) А вот с возможностью относительно легкого перехвата доступа (в случае наличия желания у сервиса) у всех подобных сервисов как раз большая проблема.
Как я его понимаю, то его выводы заключаются в том, что:
1. Необходимо шифрование устройство-устройство (к этому все и идет)
2. Проблема в том, что метаинформация (заголовки писем, кто и с кем общается) все так и остаются в открытом виде
3. Надежная авторизация, чтобы быть уверенным, что именно только получатель письма может получить доступ к содержимому, а не кто-то, кто смог перехватить пароль.
Именно эти 3 составляющих необходимы для надежного решения.
Самое простое решение я вижу в виде блокировки сервиса на уровне IP. До блокировки домена добраться так легко не получится, так как он не в зоне .com/.net/.org. Вопрос с доменами в этих зонах решается очень быстро, потому что корневые DNS-сервера в юрисдикции США. Но это уже сильно негативно скажется на гос. структурах, которые этого будут добиваться. Обострят отношения тоже просто так никто не будет. Особенно, на фоне всех последних скандалов.
Думаю, что самым логичным будет, что придумают какое-то решение, которое «заблокирует» данную сделку и/или очень усложнит жизнь сервису. Аналогично тому, как создают списки, с кем нельзя вести дел, так как угрожают национальной безопасности или противостоят интересам государства.
Я думаю, что это уже вопрос больше политический. В этом плане децентрализованные системы, конечно, имеют преимущество. Но, к сожалению, их вряд ли можно назвать дружелюбными для конечного рядового пользователя. А производители устройств типа Apple или Samsung я очень сомневаюсь, что добавят поддержку Tor в устройства :) Поэтому пользователю надо выбирать, насколько серьезную защиту и от кого он хочет. Чем больше уровень защиты — тем сложнее, как правило, все системы в использовании, как бы ни старались их упрощать, увы…
Так можно использовать практически любой сервис. Например, можно заархивировать с паролем текстовый файл и загрузить на файлообменник, сообщить пароль получателю — он прочитает. Но насколько это удобно конечному пользователю? А в данной ситуации ProtonMail решает данную задачу. Отправить сообщение быстро и легко, пароли сообщить друг другу не надо.
Основная проблема реализации ProtonMail в том, что это JavaScript и сам код/окружение скриптов ProtonMail никак не ограничено в браузере от содержимого писем, что делает его потенциально уязвимым для XSS-атак, как и любой другой веб-сервис, где есть загрузка пользовательского контента. И второй существенный момент тоже был рассмотрен в статье по поводу возможности внести изменения в программный код со стороны владельцев сервиса в любой момент.
Вспомнил, что когда читал про Mailpile, то особо обратил внимание на то, что он умеет искать по сообщениям. Проверил по информации на их сайте сейчас. Клиент веб-почты Mailpile умеет искать по письмам. На https://www.mailpile.is/faq/ пишут, что создает индекс, а само содержимое индекса хранит в виде хешей.
Если отправить письмо на сторонний сервис в открытом виде, то оно сохраняется в отправленных письмах в зашифрованном виде.
Спасибо за «наводящие» вопросы — обязательно добавлю в статью!