Об ошибках Lavabit-а

[jsn]

(всем спасибо за поздравления!)

К другим новостям: популярно про Lavabit.. Для тех, кто не следил: Lavabit был коммерческим провайдером электронной почты, защищённой от перехвата и проч. Много кто пользовался, Сноуден, например. (предположительно из-за него) К Lavabit-у пришли из органов и потребовали воткнуть прослушку. Хозяин Lavabit-а отказался, и был вынужден закрыть сервис. Статья, впрочем, не об этом (об этом stas писал, например), а о том, почему технически Lavabit был устроен неправильно, и как это сделало возможным такой наезд со стороны органов.

Even though Lavabit’s security page went on at length about how, in the age of the PATRIOT act, users shouldn’t accept a Privacy Policy as enough to protect them, that is almost exactly what they implemented. The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though they advertised that they ”can’t” read your email, what they meant was that they would choose not to.

(и т.д.)

Насколько я понимаю, готовых решений для "простых людей"™, лишённых подобных недостатков, в природе не существует. Для непростых примерно понятно, как что должно быть устроено.

Comments

[jsn.livejournal.com]

Я тут не всё понял, наверное (я относительно далёк от текущего положения дел с crypto в броузерах).

шифруют ... если оно не зашифровано отправителем

Нет, шифруют в любом случае, и поверх конверта, потому что заголовки писем и всё такое.

Но в целом -- я совершенно не вижу смысла это делать в броузере, тем более если установка дополнительных компонент у клиента всё равно неизбежна.

[rblaze.livejournal.com]

Что делает всю историю тождественной установке standalone клиента с поддержкой S/MIME и использованию IMAP сервиса, вообще-то. Никакого смысла в web-based email при таком раскладе нет.

[jsn.livejournal.com]

Я это и сказал. IMAP, впрочем, нехорош тем, что даёт возможность хранить нешифрованное на сервере; этого хорошо бы не допускать, на самом деле.

[vitus_wagner]

Не совсем.
1. Это создает давление на производителей браузеров чтобы о ни в конце концов выпихнули в Javascript полноценный интерфейс к все равно имеющимся в браузере криптографическим библиотекам.

2. Это превращает сайт в сервер обмена сертификатами. Что существенно увеличивает количество end-to-end зашифрованных писем.

[rblaze.livejournal.com]

Производители браузеров не при делах, обращайтесь в комитет по стандартизации. А сервер обмена сертификатами отличное место для mitm атак.

[vitus_wagner]

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

Смысл это делать в браузере есть.

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

[jsn.livejournal.com]

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

Шифровать поверх конверта необходимо. Его с очень хорошей вероятностью НЕ видели интересующиеся, unless you are dealing with global adversary. Типичный ордер на прослушку отдаст противнику все будущие конверты, но не отдаст предыдущие. Если для шифрования конвертов придётся отказаться от индекса ящика на сервере -- tough luck, значит, придётся отказаться.

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

Если всё равно писать новый софтвер, то ничто не мешает оснастить его удобствами для переноса ключей.