Pull to refresh

Comments 66

Много думал о подобном.

Будут не лишними зеркала в tor и i2p.

Можно ещё сервис заметок нагородить рядом. Хранить на сервере шифрованный bson со всеми данными пользователя, отдавать их любому, но расшифровывать только на клиенте паролём.

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

Интересные идеи! Обязательно попробую в свободное время.

Это все хорошо до тех пор доверяют сайту. Причины это делать?

Установить TLS-соединение между двумя хостами и гнать между ними все что угодно - сложнее, но определенно более секьюрно

Не поспоришь. Но тут дело как раз в простоте. Зайти на сайт и сформировать ссылку быстро и доступно любому. А вот с TLS между двумя хостами... Получится поговорить только с истинным единомышленниками))

А есть вариант self-hosted развёртывания? В идеале - чтобы можно было в докере 1 контейнер поднять.

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

Фронтенд и так можно посмотреть, а бэк несложно пишется, если разбираетесь. Поэтому можете взять фронтенд и сделать на свой вкус)

Всё же было бы больше доверия к такой системе, если бы весь код был открыт. Уверен, здесь даже нашлось бы некоторое количество людей, готовых его вдумчиво проанализировать и предложить доработки в виде пулл-реквестов.

Насколько я понимаю, честные варианты монетизации такого сервиса в текущем виде отсутствуют. С другой стороны, если рассмотреть self-hosted решение, можно и продавать расширенную поддержку, если сервис окажется достаточно популярным.

Так что призываю Вас не переживать, если в Вашем коде найдут что-то некрасивое или неоптимальное, и открыть его миру =)

Честно говоря, я никогда не понимал, почему опенсорс так сильно повышает доверие. Ведь всегда можно написать разные версии для гитхаба и для продакшена. Но да ладно. В целом, я пока рассматриваю вариант открытия кода, и такие люди как Вы, наверняка меня убедят это сделать) так что в свободное время рефакторю код, но пока ничего не обещаю)

Потому что с гитхаба можно развернуть у себя, не беспокоясь что там в продакшене у автора.

Да! А в чем выгода создателю? Трафика он не получит, монетизировать никак не сможет. Опенсорс это конечно хорошо, не спорю, но вот на чем живут авторы я никак не пойму.

Не знаю. Думаю средние/крупные проекты живут на платной поддержке/донатах, мелкие просто за идею.

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

Почему бы на самом сервере не оставить сообщение благодарным пользователям в виде реквизитов для "спасибо"?

Я планирую когда-то сделать что-то вроде донатов на сайте. Но по поводу "спасибо" пока не думал, кстати. А не сделал ещё из-за того, что времени не было. Да и на благодарных пользователей пока не рассчитывал. Но если Вы благодарны, я благодарен Вам))

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

Осталось убедиться, что сервер всегда будет отдавать именно этот код.

Проблема тут только одна:

  1. Набирается большая аудитория сайта

  2. Изредка вашим сервером в браузеры отдаются чуть подправленные скрипты, отсылающие на ваш сервер не только зашифрованную инфу, но и незашифрованную

  3. Юзеры этого не замечают, а вы начинаете заходить в их аккаунты :(

Скрипту не нужно отправлять что-то расшифрованное, чтобы оно спалилось снифферами. Достаточно отправить якорь при открывании ссылки и сохранить в БД ключей к запискам. :)

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

обственно, так может делать любой мессенджер.

Не может. Мессенджеры (нормальные) не обновляют/загружают свой исходный код с внешнего сервера при каждом открытии приложения и подобную аттаку к ним не применить.

Ваш сервис не безопасен т.к. требуется доверять вам и вашему серверу. При компроментации сервера ключи шифрования и содержимое становятся доступными не только получателю и отправителю.

У большинства популярных мессенджеров есть веб-версия...

UFO just landed and posted this here

PGP оно как vim или емакс - идея хороша но UX по 10 бальной шкале примерно на минус гугол

+100500. pgp/gpg - это база, без него нельзя говорить о защите от 3 лиц

Пишем супер-секретную записку с очень-важным-паролем.

Отправляем её другу другим каналом связи, например, whatsapp, telegram, да хотя бы и почтой или смс. Добрая среда общения у друга услужливо делает предпросмотр ссылки, и...

:goto start

Не раз обжигался :(

При предпросмотре откроется страница подтверждения открытия записки. На этом этапе содержимое записки клиенту не отправлено и не удалено. Записка останется в БД до тех пор, пока на этой странице кто-то не подтвердит, что действительно хочет посмотреть записку

Это одноразовая записка. После того, как Ваш друг прочитает послание оно навсегда удалится с сервера.

Ага, а гарантирует это сам сервер. И он действительно удалит записку, а не тупо инвалидирует ссылку. Ведь джентельменам следует верить на слово, так?

Получается так) Но зачем по-Вашему нужна инвалидированная записка? Хранить её в надежде что кто-то взломает аккаунт пользователя сайта и мы вместе с ним посмотрим, что там? Придётся на всякий случай хранить миллиарды записок)

Если владелец сервера недобросовесный, он просто может взять ключ из access.log и прочитать записку.

Ключ хранится в якоре. Якорь не отправляется браузером, а сервером не принимается. То есть если в ссылке было .../id_записки#ключ, то в логах будет только .../id_записки. Это и сделано для того, чтобы так было сделать нельзя.

Как только ваш сервис станет достаточно значимым и им начнут пользоваться массово, к вам непременно придут и объяснят, что вы все делаете не совсем правильно, надо же делиться инфой.

Делиться нечем, придётся прикрыть лавочку. В конце концов когда-то придут ко всем. А к кому не придут, того заблокируют. Может когда-то так и случится. Возможно, к тому моменту станут доступны новые пути достижения поставленных целей. Ну и будем надеяться, что если указанная ситуация и произойдёт, то это будет не скоро.

Вы не поняли. Вас никто не будет ниочем просить. Вам просто скажут это делать. И прикрыть лавочку уже не получиться, если не появится стойкого желания присесть.

Вы же понимаете, что таким сервисом в первую очередь будут пользоваться криминальные и террористические организации?

Разве есть статья, по которой я не могу прекратить деятельность сервиса в пользу расследования преступлений? Возможно я чего-то не знал. Если поделитесь — буду признателен.

Давайте гепотетически представим, что вами был создан такой сервис. Он выстрелил. Стал популярен. И на этой стадии через сервис пошли месенджи по незаконному обороту наркотиков, оружия, торговлей людьми, детской порнографией. Это уже не говоря про терроризм (хотя его доля в сервисе будет мизерна, на фоне всего перечисленного).

Вас приглашают на общение в правоохранительную структуру. Вы действительно думаете, что после проведенного там диалога, у вас будет возможность закрыть сервис? Сервис, который по сути является единорогом доказательной базы? Ой, я вас прошу. Выбора будет в лучшем случае два - передача прав на сервис указанному лицу (организации) или выполнения поставленных требований.

Ультимотивность требований будет зависеть от вашего социального статуса. Если вы Дуров, то создадут видимость законности действий, демонстрируя обществу вашу очень темную сущность, чтоб когда воплотить угрозы, общество было на стороне государства. Если попроще, то замаячет ряд интересных статей криминального кодекса, с весьма продолжительными сроками, а на этих стадиях можно и в СИЗО посидеть, подумать над своим поведением.

UFO just landed and posted this here

А почему именно к владельцу надо привязать, не понял. На что рассчет?

UFO just landed and posted this here

Идею понял, но, пожалуй, довольно жёсткая система. Если у меня комп разрядится, а меня дома не будет... надо подумать тогда действительно, как избежать ложной тревоги

UFO just landed and posted this here
Если технику владельца изъяли, то запрос не приходит и запускается протокол
Ну да, экскаватор кабель порвал / дом электрики обесточили, и всё — данные всех пользователей сервиса накрылись вместе с сервисом.

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

Хорошие приватные мессенджеры так и работают. Только почему-то большинство людей предпочитают удобство безопасности. Private-net.work сделан для того, чтобы было достаточно того, чтобы им пользовался только отправитель. Вдобавок, клиент скачивать не надо. А чтобы пользоваться таким вот мессенджером, надо ещё пойти и убедить всех, что им это надо...

Тут вам скорее объясняет, в чем вы не правы, нежели помогут с раскруткой сервиса

Это правда))) Но не все существующие проблемы очевидны, и знать о них — тоже хорошо

ID довольно короткий, юные хекеры будут периодически зачищать чужие одноразовые записки простым перебором

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

может кто нибудь запилил уже pgp поверх телеги с публичными сертификатами в записной книге?

В принципе, эта схема может работать на другой архитектуре.


  • Небольшая, opensource программа шифрует сообщение. На выходе — шифротекст в base64 и секрет. Программа проходит аудит безопасности и шифрования. Программа, естественно, offline.
  • Шифротекст загружается на надёжный, независимый, находящийся в другой стране, хостинг, который гарантирует удаление записи по истечению срока или по факту доступа.
  • Собеседнику присылается ссылка на шифротекст, секрет и инструкция по расшифровке с помощью offline-утилиты из пункта 1

Есть ли у этой схемы изъяны безопасности? Конечно есть. Но явно меньше, чем у предложения автора.


Сложно ли это реализовать? Отнюдь нет. Для шифрования можно использовать известные opensource утилиты, хоть даже Zip + base64encode. Для хранения сервисов полно — вроде Pastebin


Будет ли этим кто-то пользоваться? Вряд ли. Между удобством и безопасностью мы обычно выбираем удобство.

Между удобством и безопасностью мы обычно выбираем удобство.


Выбираем то что более важно. Большинству анонимусов ничего не угрожает — зачем им особенная безопасность?
Прочие могут воспользоваться аппаратным генератором одноразовых ключей.
независимый, находящийся в другой стране, хостинг, который гарантирует
Если у вас есть такой хостинг, что мешает прямо туда поставить web-чат с SSL + ещё 100500 e2e-шифрований, если не доверяете SSL. И никакого гемора с ключами, программами, ссылками.

Вообще можно позвонить человеку по другому каналу, через звонилку с end-to-end шифрованием, и продиктовать пароль голосом.


Аудиозаписи звонков люди обычно не ведут, а e2e шифрование гарантирует, что это не сделает man in the middle

Короткий пароль перебирается, а хотя бы со 128 бит энтропии запаришься диктовать.

10 слов парольной фразы дают 129.5 бит если верить генератору паролей keepassxc

Да, но звонить по телефону и диктовать не сильно легче, чем установить какой-нибудь Bitmessage и перейти на него. А тут опять вопрос в удобстве. Если вы хотите передать что-то, но не слишком светить, а собеседник поленится заморачиваться ради вашей безопасности, то слушать пароль по телефону он не станет и так и не узнает вашего послания. А такой вариант хотя бы частично устроит обоих

а e2e шифрование гарантирует, что это не сделает man in the middle

При условии, что собеседники предварительно верифицировали ключи по независимому каналу. Я недавно проводил мини-опрос среди знакомых "параноиков", сверяли ли они хоть раз ключи собеседника. Большинство даже не знало, как и зачем это делать :(

В комментариях уже есть упоминание PrivateBin. Селфхостинг, опенсурс, оконечное шифрование.

Я по заголовку ("нарушение целостности") надеялся, что здесь наконец кто-то напишет про цензуру и подделку переписки, когда из писем вырезают куски... А здесь - всего лишь способ добиться приватности при условии доверия любому одному внешнему серверу из двух вместо доверия просто одному внешнему серверу.

Поясню. Допустим, я не доверяю вам. И пересылаю ссылку через email, админам которого тоже не доверяю. Скрипты я, допустим, могу теоретически посмотреть, но. Откуда мне в таком случае знать, что вы действительно удаляете зашифрованные записки с сервера после прочтения? Откуда мне знать, что у властей не будет прямого доступа к вашему серверу хотя бы постфактум?

Если же вы их не удаляете, а у властей есть доступ, то. Товарищ майор, через N дней/месяцев/лет после отправки, как только у него появляется такое желание, заходит в спецрежиме в мой почтовый ящик и видит ссылку с пароелм в "отправленных", даже если я нажал в почтовом ящике кнопку """""удалить""""". После чего заходит к вам на сервер и смотрит там зашифрованное сообщение, расшифровывает его с помощью ссылки.

Так что правильно выше пишут - лучше PGP/GnuPG ещё ничего не придумали.

Невыдержал хабраэффекта?

Хабраэффект та ещё штука)

Sign up to leave a comment.

Articles