Вчера Mozilla довела до финальной версии один из своих экспериментальных проектов Firefox Send: простой и безопасный сервис обмена зашифрованными файлами. Поддерживаются файлы до 1 ГБ (до 2,5 ГБ после авторизации в Firefox Account).
Сервис выглядит просто, но под ним работает движок, который обеспечивает настоящее end-to-end шифрование, то есть вы никуда не передаёте файлы в открытом виде — они шифруются конкретно на вашем ПК, а расшифровываются на компьютере получателя (JS в браузере). Как это работает, можно посмотреть на примере Firefox Sync, здесь реализована похожая архитектура.
Демонстрационный ролик Firefox Send.
Кроме непосредственно шифрования, файлы можно защитить паролем, а также двумя ограничениями:
- Количество скачиваний
- 1
- 2
- 3
- 4
- 5
- 20
- 50
- 100
- Время действия ссылки
- 5 минут
- 1 час
- 1 день
- 7 дней
По умолчанию стоит ограничение в 1 скачивание и 1 день. То есть если получатель не перешёл по ссылке за сутки, то она деактивируется. А если перешёл, то она всё равно деактивируется.
Разработчики пишут, что сервис идеально подходит для обмена презентациями или другими рабочими файлами с коллегами. Те просто получают ссылку, щёлкают по ней и скачивают файл, не нужен доступ в Firefox Account или специальные знания криптографии (как в случае, если вы шифруете файл программой PGP и отправляете по почте).
В течение нескольких дней выйдет ещё и Android-приложение Firefox Send (когда вы читаете эту статью, оно уже могло выйти).
Кстати, пока сервис находился на стадии бета-тестирования, для него написали open-source CLI-интерфейс, чтобы легко шифровать файлы из командной строки. Он позволяет автоматизировать эту процедуру и бесшовно встроить в свои рабочие инструменты.
Программа поддерживает ещё кучу полезных функций вроде архивации каталогов, истории файлов и разных хостов для отправки (то есть можно использовать свой сервер или self hosted, а не сервер Mozilla).
Стоит заметить, что в данный момент уже есть несколько облачных решений для обмена зашифрованными файлами, в том числе от Microsoft. Что касается последней, то её решения поддерживаются всеми членами Ассоциации информационной безопасности Microsoft (Microsoft Intelligent Security Association), куда в феврале этого года для усиления мобильной аутентификации вступил удостоверяющий центр GlobalSign, сделав цифровые сертификаты легкодоступными для мобильных пользователей.
Комментарии (60)
MetaDone
13.03.2019 12:55+2теперь на вопрос «каким файлообменником ты пользуешься?» буду отвечать «конечно же мозиллой»
0xf0a00
13.03.2019 13:36-1Ага, презентации для коллег я буду шифровать и давать только сутки на скачивание и одну попытку… смешно и неудобно.
ZurgInq
13.03.2019 13:51Это может быть персональная презентация-предложение продукта.
А ещё логами с чувствительной инфой можно перекидываться0xf0a00
13.03.2019 15:47-1Логи с чувствительной инфой, на сторонний сервис… Б-безопасность. Я к чему клоню, шифруют люди все самое вкусное, а здесь еще и складывают в одну корзину…
amphasis
13.03.2019 14:08Вообще-то до 100 попыток и до 7 дней на скачивание. По-моему вполне достаточно именно для файлообмена.
saipr
13.03.2019 15:18-5А чем проблема обмена шифрованными файлами? Зачем нужен какой-то сервис? Берите OpenSSL, NSS, Gpg и т.д., шифруйте и обменивайтесь. А то доверять какому-то сервису стремно.
worldxaker
13.03.2019 15:48+3угу, попробуйте чтонибудь своим родителям зашифровонное скинуть
saipr
13.03.2019 16:27-4Еще как! И это будет намного для них проще чем общение с каким-то сервисом. Я уж постараюсь им все настроить, чтобы было комфортно, не сомневайтеся.
dartraiden
13.03.2019 22:07+2А можно не стараться, не настраивать, а использовать сабж с примерно тем же результатом.
Но если ваша цель не файлами обмениваться, а понастраивать (как в анекдоте про секс в гамаке с противогазом), то конечно.
vsespb
13.03.2019 17:29-2Из статьи непонятно как оно шифруется, какой форкфлоу, как собственно оно работает. Соответственно, зачем оно нужно тоже.
nrgch
13.03.2019 19:52+2И ни одного отзыва о реальном использовании. Удивительно! И это IT-ресурс?
А по факту — 1 загрузка и 1 сутки или менее (1 час или 5 минут) для тех, у кого нет аккаунта ФФ, а все остальные радости только для зарегистрированных.
Мне стыдно. И за публикацию, не раскрывшую эти особенности, и за вас, хабралюди.
wtpltd
14.03.2019 00:48+1Не надо стыдиться, особенно за других.
Вы можете пойти на гитхаб, взять репу, развернуть реальный проект, написать статью на хабр и получить много всего.
И, что самое замечательное, при подобном подходе, вам не придется нести тяжкий груз стыда за всех — только личный.
abar
13.03.2019 20:16Забавно что буквально неделю назад я сходил на презентацию стартапов из местной программы-акселлератора, и самый адекватный стартап из них был «надежное хранилище для зашифрованных файлов». Когда я поинтересовался «А что у вас с безопасностью?», презентующий с надежной спросил, а не эксперт ли я по безопасности и не ищу ли я работу в стартапе, что, в принципе, было ответом.
wtpltd
14.03.2019 01:00+2Молодец презентующий.
Эк он вас тонко, изящно и по самые гланды.abar
14.03.2019 13:37Так, вот теперь это уже интересно, и давайте по-подробнее.
Существует неписаный свод правил презентаций стартапов, который я нарушил, когда спросил у лидера группы «молодых и энергичных fullstack-developer'ов» (которые делают проект с закрытым кодом и не проводили ни одного аудита безопасности) про «что у вас с безопасностью»? Признать, что даже после пары раундов инвестиций в свой продукт команда так и не озаботилась ключевой проблемой (которую продукт вообще-то и должен был решать) — это «по самые гланды»?
И да, чтоб избежать додумываний, сразу уточню, что на презентации было продемонстрированно несколько красивых картинок со схемами вроде «ваш бизнес <-> мы <-> бизнес ваших партнеров», но никаких конкретных деталей не было даже упомянуто, что, собственно, и побудило меня задать мой вопрос.
Мне это показалось просто забавной особенностью современного мира стартапов, теперь же оказывается что тут был целый подтекст, который прошел мимо меня.wtpltd
14.03.2019 14:13Я имел в виду, что безопасность, понятие очень масштабное.
Это может быть омон с ружьем, который сторожит сервер от бандитов. А может быть юрист, который сторожит сервер от омона. А может быть резервное копирование на 100500 дисков во всех датацентах планеты. Т.е. аспектов безопасности очень много.
Вы свой вопрос процитировали, т.е. это именно то, что вы спросили. И этот вопрос, он ни о чем. Вот что на него по вашему надо было ответить? Если бы вы задавали вопросы о каких-то конкретных рисках, это была бы другая ситуация. А так, на вопрос ни о чем вам сказали — умник?, ну приходи тогда к нам работать.
спойлер— Доктор Флойд, — тоном, не допускающим отказа, спросила хрупкая, но весьма решительная дама из газеты, — чем объясняется полное прекращение информационных передач с Луны? Это связано с политической обстановкой?
— Какую именно политическую обстановку вы имеете в виду? — сухо бросил Флойд.
В группе журналистов послышались смешки.
shumaher86
13.03.2019 21:48народ, а как в него зайти? ввожу данные Firefox Account, открываются его настройки, ок, сам нажимаю Назад, обновляю страницу, а ничего не меняется.
AC130
13.03.2019 22:25А оно точно работает?
Kocmohabt314
14.03.2019 10:36безопасный сервис обмена зашифрованными файлами
Только роскомнадзору не говорите.
vyo
14.03.2019 10:51Пробовал, когда крутилось в бете. В итоге лиса съела всю память на мобильном (файл ~1ГБ, всего памяти 2ГБ) и была прибита OOM-killer'ом.
Если я правильно понял, они пихают весь файл разом в память? Или даже два файла — шифрованный и нешифрованный?
unwrecker
14.03.2019 12:35А пароль при распаковке он как проверяет? Что-то не могу придумать методику (кроме предварительной скачки всего архива, чего не происходит) которая не снизит взломостойкость.
Tangeman
14.03.2019 22:17Метод описан в документации.
Отправитель:
1. Генерируется случайный мастер-ключ (на клиенте, разумеется);
2. Он используется для создания ещё трёх:
— ключ для самого файла;
— ключ для метаданных;
— ключ для подписи nonce;
3. Файл с метаданными шифруются первыми двумя;
4. Их зашифрованные версии передаются на сервер вместе с третьим ключом;
5. Сервер отдает токен владельца и URL для отправки (они записываются в local storage);
6. Вы получаете URL (сгенерированный сервером) с мастер-ключём (как #фрагмент в URL).
Получатель:
1. Запрашивает у сервера URL, в ответ сервер включает nonce.
2. Берет мастер-ключ из фрагмента (который, разумеется, на сервер не попадает);
3. Получает из него 3 ключа как в шаге 2 у отправителя;
4. Отданный в шаге 1 nonce подписывается третьим ключём (HMAC SHA-256) и отправляется на сервер вместе с запросом на метаданные;
5. Сервер отдает метаданные (если nonce подписан правильно), которые дешифруются клиентом с помощью второго ключа и показываются пользователю;
6. Клиент отправляет запрос на сам файл (тоже с подписанным nonce);
7. Собственно, файл отдается и дешифруется клиентом с помощью первого ключа;
8. Profit :)
Griboks
Вопрос: зачем мне использовать сторонний сервис, если я могу самостоятельно зашифровать файлы и передать их через любое хранилище? Ответ: чтобы можно было
посмотреть мои файлысэкономить 10 секунд времени.Вопрос: зачем коммерческая компания тратит много денег на этот сервис, который не окупается? Ответ: чтобы
посмотреть мои файлы и заработать денегпомочь нуждающимся.kSx
Почитайте про асиметричное шифрование. А ещё про то, что Mozilla — некоммерческая организация.
Griboks
Возможно, вы сможете ответить на мои вопросы в первом комментарии, потому что я не умею читать.
Tangeman
На первый вопрос ответить легко — это экономит не 10 секунд, а минимум 10 минут времени, потому что (для обычного, не продвинутого пользователя):
— не нужно искать и ставить приложение для шифрования (получателю тоже);
— не нужно его использовать;
— не нужно искать сервис который позволяет надежно обмениваться файлами «без регистрации и смс».
Те, кто этим занят постоянно и круг получателей постоянный, могут конечно использовать заранее согласованные способы и сервисы, но вот так «вдруг» — сервис удобнее, не говоря уже о том что далеко не все достаточно продвинуты чтобы правильно выбрать нужные способы.
Что касается второго вопроса — поскольку шифрование end-to-end, и это легко проверяется на стороне клиента, то «посмотреть файлы» не получится. Компания тратит «много денег» (на самом деле не очень) по как минимум одной простой причине — это формирует положительный образ компании, о ней говорят, она становится более известной.
Griboks
Спасибо за мнение. Очень радует, что хоть два человека умеют читать.
athacker
Если рассматривать вопрос с точки зрения ИБ, то «ассимметричное шифрование» и «некоммерческая организация» не гарантируют ничего.
Т. к. шифрование может быть реализовано с ошибками, либо параметры работы алгоритма подобраны таким образом, чтобы его проще было вскрыть.
А то, что некоммерческая организация… Если придут люди из трёхбуквенной конторы, то без разницы, коммерческая это организация или нет.
Andrey_Volk
Ах, как жаль, что «шифрование с ошибками» нельзя никак проверить, ведь исходников нет на гитхабе :(
acsent1
А откуда ты знаешь, что у них на сервере развернуто именно из этих исходников?
Tangeman
Сервер хранит уже зашифрованную версию, всё шифрование — на стороне клиента, в браузере.
kvghabr
А браузер джаваскрипт с функцией шифрования откуда берет? ;)
Tangeman
А что вам мешает изучить исходник того что берет браузер и сравнить его с выложенным на github кодом сервера?
Конечно, чисто теоретически, можно представить что кто-то и поставит бэкдор в js, но это кто-нибудь да обнаружит (js ведь не скрыть) — рано или поздно. Теперь вопрос — рискнет ли Mozilla своей репутацией?
kvghabr
То, что в любой момент, для определенного айпи или иной метки, которыми браузер нашпигован по самое нехочу, сервер может выдавать самый разный код ;)
Вот решили вы проверить исходники, отследили запрос, проверили на гитхабе — все нормально, начали применять в своих делах.
А вот уже вас решили «проверить». На сервере приняли запрос на js-файл, сняли с него метрики, чтоб подтвердить что это именно вы, (есть куча разных способов это сделать), и отправили вам «правильный» js)))
К чему это? Если прятать некритичную инфу, а так — фото из окон соседнего дома, то сервис подойдет. Для чего-то более менее серьезного — весьма так себе способ.
Функции шифрования работают только когда они загруженны оффлайн, проверенны хэшсуммами, скомпилированны и загружаются только со стороны клиента.
Tangeman
Нет «кучи способов», если не следить за отправителем. Я могу это сделать откуда угодно — к примеру, интернет-кафе, из гостей etc — и если кто-то физически не отслеживает мои перемещения, определить что я это я — нереально. Но если за мной реально следят, то у меня гораздо более серьезные проблемы.
Так он для этого и создавался — вовсе не для отправки жутко важных и секретных данных, за которыми будут следить трёхбуквенные организации.
Если уж вы так глубоко копаете — не останавливайтесь на этом. Сами создайте все компоненты, на которых эти функции выполняются, а то ж нет гарантий что процессор, память, монитор, клавиатура или SSD/HDD не содержат в себе закладок, которые тайно, с помощью нейтринной связи (чтобы не обнаружили) передают всё куда надо ещё до шифрования. Причём вам придётся убедится, что получатель тоже пользуется вашими «чистыми» компонентами, и что каналы связи по дороге абсолютно защищены, и ещё… ну вы понимаете :)
kikiwora
А вы думаете что в браузере только JS работает?
kvghabr
Нет, конечно)
athacker
Вы правы, риски невелики. Но они, тем не менее, есть.
Например, есть класс атак, называемый «атака на цепочку поставки». И комментаторы выше правы — в результате вам в браузер может прилетать несколько модифицированный Javascript, не такой, как выложен в репозитории.
Отдельным клиентам, в которых заинтересованы
трёхбуквенныетретьи лица, сам сервер может отдавать модифицированный код. Вы же не будете каждый раз перед заливкой файла проверять, с какими параметрами шифруется файл, правда? А всем остальным клиентам, к которым нет интереса, будет отдавать ровно то, что в гитхабе лежит. Трудно такое поймать, если это разовые, адресные акции.Также есть атаки на сам браузер, и потенциально есть возможность изменить код прямо в клиентском браузере, ослабив шифрование
или заменив его на XOR.В общем, обмениваясь реально значимой секретной информацией, нужно подобные риски иметь в виду. В целом, для меня анонс такого сервиса выглядит несколько странным, т. к. есть штуки типа Seafile, Ownckoud/Nextcloud, где этот функционал тоже есть, среди прочего, а также есть возможность отправки шифрованных сообщений по e-mail, да даже зашифрованные архивы, в конце концов, которые тоже расколоть не так уж просто.
Плюс если раздавать зашифрованные архивы, они не скапливаются на каком-то одном конкретном стороннем сервисе, а пользователь можей выбрать любой файлообменник (или почту), поди ещё слови этот архив. А тут — заявляется, что «вот, у нас секурная организация файлообмена, кидайте нам свои файлы!». И к бабке не ходи, файлы не будут физически удаляться после истечения срока их размещения, т. к. это накладная операция на больших объёмах. Фейсбук или VK не удаляют, например. Точнее, удаляют, но в рамках процедур housekeeping, и по факту «удалённые» файлы физически лежат на месте и теоретически могут быть доступны по несколько месяцев.
Tangeman
Это нужно делать и у получателя тоже — иначе он не сможет расшифровать и, как следствие, обратит на это внимание. Если же кто-то настолько крут что может это сделать вовремя и с отправителем, и получателем, только с ними и именно тогда когда нужно — возникает естественный вопрос — а не проще ли ему получить доступ к файлу другим способом, с такими возможностями?
Нет, я не утверждаю что риска нет — просто это ну очень маловероятно.
end-to-end между отправителем и получателем? Разве? Не говоря уже о том что эти сервисы нужно где-то разворачивать и поддерживать, что имеет смысл только если кто-то регулярно раздаёт что-то стабильному кругу лиц.
Сервис мозиллы же, с другой стороны, вряд-ли расчитан на тех кто профессионально (если можно так выразиться) хочет секретно что-то передавать — это скоре для обычных пользователей, которые шибко секретные вещи не передают, делают это спонтанно и из любой точки.
Удаление файла по любому на порядки быстрее чем его закачка и передача, а хранилище явно не резиновое — зачем на нём просто так держать петабайты зашифрованных данных?
Я бы ещё понял если бы расчёт был на то что сервис создан для (к примеру) шпионов, которых будут убеждать передавать с его помощью секретные данные, но он явно не на таких расчитан, поэтому минимизация расходов будет далеко не на последнем месте — а это, с высокой вероятностью, приведет к удалению всего что просрочено сразу как оно просрочено.
Есть пруфы или это так, предположения?
vvadzim
Вообще, я очень рад подобному сервису и точно буду им пользоваться.
Но всё же указание на отсутствие пруфов
могло бы быть вежливее.
Я специалист не совсем по рапределённым системам, но сталкивался и немного понятием владею. Удаление файлов приводит и к фрагментации дисков на hdd (фб и вк начинались задолго да эры дешевых ssd), которая на серверах очень дорого обходится, и к обновлению кешей и в ОЗУ, и на балансировочных серверах, и других неведомых местах, которое дорого, и к куче других нюансов.
Я тоже не приведу пруфы, знать все те вещи и гуглить для вас мне прямо сейчаc не хочется. Но я знаю, что знаю достаточно, чтобы понимать что мир файловой системы на персоналке и мир распределённой файловой системы социальной сети планетарного масштаба отличаются примерно как Ньютоновская гравитация и ОТО. И там и там интуиция, наработанная на более простых вещах, ломается на более сложных.
P.S. И ещё про интуицию. Например, реализация европейского права на забвение в соцсети совсем не тождественно удалению файлов, и может быть относительно недорого реализовано. Хотя на персоналке это одна и та же операция.
Tangeman
Извините, вовсе не хотел задеть задавая вопрос насчёт пруфов — просто подобного рода утверждения слишком сильные для принятия на веру без соответствующих подтверждений.
То, что удаление приводит к фрагментации, не очень большая проблема — есть десятки способов это минимизировать. Разумеется, я не утверждаю что данные физически удаляются с носителей сразу после «логического» удаления, но то что они как минимум отмечаются удалёнными и выделенное им пространство может в любой момент быть переиспользовано — это однозначно.
Так что формально — да, вы правы — они какое-то время остаются там (как и удаленный файл в «обычной» FS), но вот вероятность того что они хранятся намеренно, «вечно» (или просто долго) и с возможностью восстановления «одним кликом» (включая метаданные) — очень мала, слишком уж накладно будет наращивать мощности вместо их переиспользования, объемы сами знаете какие (с учётом фото и видео), а польза от такого хранения — близка к нулю.
ffs
Вроде не раз уже писали, что все загруженное в вк уже не удалить. Раньше даже фотки удаленные были доступны по прямым ссылкам, сейчас не в курсе.
Ну и, не удивлюсь, учитывая текущего владельца ВК, что на профиль при удалении по факту просто ставится флаг deleted = 1, а на деле все на месте.
athacker
Про удаление файлов — читал несколько статей по архитектуре высоконагруженных сервисов, типа социальных сетей и т. п. С определённого уровня нагрузки практически все переходят на использование БД в качестве движка хранения, в том числе для файлов. И там удаление — довольно ресурсозатратная операция — там и проблемы с фрагментацией и масса всякого.
Например, вот:
habr.com/ru/post/120918
habr.com/ru/company/oleg-bunin/blog/313364
В целом я с Вами согласен, просто рассматривал использование такого сервиса с точки зрения рисков для ИБ.
Seafile, кстати, довольно стабильная штука. Я эксплуатирую несколько инстансов (домашнее облака и два корпоративных) — вообще никаких проблем. Обновления плановые провожу, не более. Хотя корпоративными пользуются человек 500, наверное, и суммарный объём уже с десяток терабайт.
Sirion
Если они смогут как-то монетизировать те файлы, что я соглашусь пересылать таким образом, то они чёртовы финансовые гении)
dlancer
Расшифровка будет платной? :)
wtpltd
Не, оно же совсем не про то.
Во-первых, шифрование прозрачно и при загрузке и при скачивании. Никаких лишних телодвижений не требуется.
Во-вторых, все лежит на гитхабе (4152 звезды, однако) и можно у себя развернуть сервис для своих нужд.
В третьих, на файлпомойках оседает куча файлов, которое кладут именно для разового обмена. А потом это файло никто не удаляет и оно там скапливается. И через некоторое время разобраться, что нужно, что не нужно, чье оно, просто нереально. И вот именно эту задачу данная штуковина и решает.
Для меня проблема весьма актуальная, поэтому надо потестить и посмотреть.
sena
есть же owncloud и nextcloud
wtpltd
Я использую OwnCloud и для себя и на работе. И да, там можно шарить файлы ссылками.
Проблема в том, что облако про долговременное хранение и совместную работу с файлами. Но часто людям надо разово передать файл другому. И этот файл навсегда осядет в облаке. Его никто никогда не удалит. И постепенно все захламляется до невозможности.
Вот это мозиловское приложение может быть способом решить именно эту проблему.
Tangeman
owncloud/nextcloud не умеют end-to-end между двумя незарегистрированными пользователями (и не уверен что уже могут хотя бы между двумя разыми пользователями), к тому же очень тяжеловесны.
Суть подобных сервисов — простота и доступность в сочетании с безопасностью — не нужно ничего ставить, регистрироваться etc, можно использовать любой браузер (с js) в любой системе в любой момент.
sena
Если действительно важна безопасность, то придётся файл шифровать самому, потому что мало ли какой javascript отдал сервер браузеру на этот раз.
Зато простота, бесплатность и доступность без регистрации, это конечно большой +, даже вообще без шифрования. Но оно ж денег стоит — если дело ограничится рекламой, то прекрасно.
wtpltd
Есть приложение для nextcloud docs.nextcloud.com/server/12/admin_manual/file_workflows/retention.html
Moskus
Это вообще всегда забавно:
— когда конкуренции у какого-то продукта нет, многие (вполне обоснованно) жалуются на то, что этот продукт не имеет каких-то возможностей, а также (тоже совершенно обоснованно) ругают разработчиков/владельцев сервиса монополистами, но пользоваться продолжают,
— стоит появиться конкурирующему продукту, о первом резко забывают, и начинается недоумевающее нытьё «а зачем нужен еще один продукт, ведь и так есть XXX и YYY».
Как-то это второе в контексте первого предельно близоруко и непоследовательно.
bopoh13
Можно даже сервис не разворачивать.
shaggyone
Вы же научили всех родственников, включая пожилых и детей этим пользоваться?
Griboks
нет