Об ошибках 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

[vitus_wagner]

Яваскрипт мы будем отдавать тоже подписанный.

[jsn.livejournal.com]

Естественно. Это совершенно никак не отменяет всего вышесказанного, а именно: клиент должен будет поверить на честное пионерское, что сервер не отдал ему *подписанный* злокачественный яваскрипт.

[vitus_wagner]

Скрипт будет подписан подписью разработчика, а не только адмиристратора сервера. То есть для того чтобы подменить скрипт на злокачественный, потребуется одновременно подвергнуть терморектальному криптоанализу двух людей в разных юрисдикциях, да еще и ухитриться скрыть этот факт.

[rblaze.livejournal.com]

Делов-то, подписать ключом другого разработчика.

[jsn.livejournal.com]

Хех, мы буквально в одном шаге от изобретения web of trust :) К моменту, когда мы опишем удовлетворительно работоспособную концепцию, все или почти все преимущества от имплементации in-browser будут утрачены. В частности, к настоящему моменту, мы утратили:

1. Способность работать без установки дополнительного софтвера (для криптографии, и, что гораздо ужаснее, для верификации рантайма вебприложения целиком [не только ваш яваскрипт, и даже не только вообще яваскрипт на странице, а также DOM и всё прочее]).
2. Способность к instant upgrades (потому что ваша схема уже требует подписи не только разработчика, но и независящего от него верификатора -- администратора сервера или ещё кого, не суть -- это человек, который должен вычитывать и обдумывать все правки в яваскрипте, html-е и css-ах / картинках / прочем).
3. Гибкость разработки (сделать, чтобы вот эта иконка мигала в полтора раза медленнее, теперь требует такого же workflow от всех участников, как замена кода crypto).

...и при этом по-прежнему не прикрыли некоторые очевидные минусы от имплементации in-browser, например:

4. Если противник таки смог обойти ваши механизмы противодействия изменениям в javascript-коде, свой выигрыш он получает моментально и неизбежно (в отличие от ситуации с не-броузерной имплементацией, когда у противника в лучшем случае будет шанс попробовать что-то, если/когда пользователь решит поапгрейдиться).

...что-то ещё осталось от плюсов использования броузера? https://news.ycombinator.com/item?id=6637915 и http://www.matasano.com/articles/javascript-cryptography/ пусть будут здесь для чеклиста.

С другой стороны, если бы вместо remote webapp вы бы рассматривали, скажем, local webapp, или local smtp/imap proxy (hell, why don't we do both in the same product?) --- --- --.

[sorhed.livejournal.com]

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