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

[sorhed.livejournal.com]

Для непростых есть I2P и Bitmessage. А так — ну разве что реализовать аналог Bitmessage внутри браузера на джаваскрипте посредством WebRTC.

[jsn.livejournal.com]

Я имел в виду решения для email конкретно, а не для коммуникации как таковой. Ну хотя бы в смысле to deliver on Lavabit promise (почтовый сервис с разумной forward secrecy, как минимум).

[vitus_wagner]

Ну предлагаю следующий вариант:

1. При сигн-ине пользователь штатными средствми браузера/операционной системы генерирует себе ключевую пару и запрос на выдачу сертификата. Сервер выдает ему сертификат с extendedKeyUsage содержащим OID E-mail protection (наряду с clientAuth). Ну и прикапывает этот сертификат у себя.

2. При получении письма его шифруют с использованием этого сертификата и эфемерного ключа. (совершенно штатная фича в CMS).. если оно не зашифровано отправителем с использованием S/MIME

3. Осталось добиться того, чтобы можно было отдать пользователю в браузер зашифрованное сообщение, а браузер бы его зашифровал. Если браузер IE то это делается с помощью ActiveX-элемента capicom, бесплатно раздаваемого с сайта Микрософт (но почему-то не включенного в дистрибутив). С другими браузерами придется, видимо, еxtension-ы писать. Потому что мозиловский объект window.cryto имеет метод signText но не имеет decryptText.

4. Исходящая (незашифрованная) почта пользователя подпис ывается с использованием этого сертификата. Вот тут как раз несложно извратиться и в JS сформировать корректное S/MIME письмо используя только signText Благодаря этому адресат письма, использующий нормальный S/MIME capablle клиент получает возможность закешировать сертификат данного пользователя и отправлямую ему почту на нем шифровать.

5.При заполнении пользователем поля To мы проверяем, а вдруг сервер знает сертификат этого пользователя и если да, предлагает зашифровать письмо на этом сертификате в браузере. Тут тоже понадобится либо Capicom либо extension какой.

[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, значит, придётся отказаться.

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

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

[jsn.livejournal.com]

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

[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]

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

[sorhed.livejournal.com]

Где-то в каком-то месте пользователю нужно будет всё же перепроверить отсутствие дырок в шапочке из фольги самому. Сравнить джаваскрипт из браузера с несколькими reference-имплементациями (для этого нужно, чтобы код был простым-простым — простота лучшая защита от вмешательства). Или самому запустить sha256 (или что там ещё не сломали)? Потому что любую зелёную кнопку «Connection is secure» может зажечь и противник, теоретически. Мало ли у них настоящих сертификатов, проходящих проверки в браузерах.

А значит, полностью прозрачное решение не получится. Security в случае advanced persistent threat требует сознательности.

[sorhed.livejournal.com]

Это называется "PGP". Его нужно просто переписать на джаваскрипте (заодно и на исходники можно будет в любой момент посмотреть). Но в вебе ни в чём же нельзя быть уверенным — может, проклятый NSA сделал закладки во всех браузерах, и чтобы такого не было, нужно собирать браузер самому (вряд ли, конечно, вон, TrueCrypt вроде прошерстили — чистый). Даже Шнайер, вон, не брезговал документы флешкой таскать на отключённый от интернета компьютер.

[jsn.livejournal.com]

Да нет же никакого смысла в переписывании чего-либо на javascript. Нужен PGP -- ну так надо брать готовый gpgme, и не возводить турусы на колёсах.

[talgaton.livejournal.com]

интересно это перечитать сейчас.
ваше представление о безопасности - немного излишне программистское.