fk0> Он подвержен MITM без инфраструктуры обмена ключами "out of band". А её нет.
Точно нет? Зуб дашь?
Скрытый текст
Как думаешь, что там такое в URL'е?
fk0>Все эти мессенджеры пускают пыль в глаза, а в реальности там дыра. И гораздо fk0>надёжней размещать зашифрованные GPG объявления на каком-либо аналоге BBS fk0>(веб-форум, usenet, IRC, чятик на вебкаме...) Куда куча народа ходит и всё видно всем. fk0>Кому не предназначено не прочитают. Понять кто читает, а кто просто пришёл fk0>порнушку посмотреть -- невозможно.
РКН и не будет пытаться что-то понимать, заблокирует, и все тут. И порнушку, и вообще все подряд.
PGP — не мессенджер, а всего лишь шифрование. Это вообще не проблема, а фигня на постном масле. fk0> Это всё работало только через голос в Z-fone им. Циммермана но до широкого появления нейросетей. fk0>Сейчас чё угодно подделать можно, а другого канала -- нет. В чятике тем более.
"А если найду?" (С) fk0>Вот например, можно было бы пересылать фингерпринт в MMS-сообщении или в SMS. fk0>У кого-то есть? Нет. Потому и нет.
Ну а если все-таки НАЙДУ?!! Все это есть в signal. Если чего-то не хватает, ну сделай Pull Request.
Здравствуйте, karbofos42, Вы писали:
K>Включишь телефон, а тебя серверы мессенджера дудосить будут, т.к. клиенту сначала нужно получить сообщение, расшифровать его, и только после этого можно будет понять, что это спам и нужно выкинуть, а не пользователю показывать.
Не смертельное препятствие. Можно как-нибудь и его обойти. Хотя бы, например, позволить опционально фильтровать сообщения на сервере по списку контактов. Допустить послабления в шифровании, передавать открыто ID отправителя. И вообще — до DDoS ещё надо дожить, чтобы ты кому-то был бы нужен. По дефолту, можно и оставить возможность дудоса.
UPD. Только сейчас придумал. Можно сразу условиться, что из всего сообщения, первые N байт — зашифрованный заголовок с ID отправителя. От сервера в первую очередь передаётся только он. Всё сообщение не передаётся. Ну и клиент говорит серверу, какие сообщения нужны целиком, а какие можно отбросить.
Я вообще считаю, что миру нужен мессенджер, децентрализованный, без регистрации, полностью зашифрованный. Чтобы юзвери идентифицировали себя с помощью пары открытый/закрытый ключ. А в плане архитектуры, надо чтобы отдельно были бы клиенты, и отдельно т.н. базовые станции — суть сервера. И вот у каждого клиента была бы своя домашняя базовая станция, которая возможно бы крутилась на домашнем сервере юзверя. Или скажем, базовая станция, расположенная в интернете, и принадлежащая какому-то сообществу пользователей. Прям как почтовый сервер и почтовые клиенты.
Клиент общается исключительно со своей базовой станцией, а уже эти станции взаимодействуют между собой, роутя траффик, сохраняя всякие там сообщения, организуя синхронизацию между несколькими клиентами юзверя, организуя сетевые туннели, если нужно. Прям как почтовые сервера. Можно даже сделать так, чтобы до некоторых базовых станций можно было бы добраться через некоторые станции-посредники. Можно туннели через TOR делать. Можно делать endpoint-ы, точки контакта с некоторым базовыми станциями. Причём у станции может быть несколько endpoint-ов. В общем, нафантазировать можно много чего.
K>И в итоге остаётся только доверять, что сервер моего банка или какого-то шлюза не взломали и ввожу цифры на безопасной страничке, которая никому ничего не сольёт.
Именно так. На той стороне может быть и не банк вовсе, а тов. майор. Или шарлатаны.
K>В Signal собеседники же не общаются напрямую p2p, а прогоняют все сообщения через серверы Signal.
Суть "сквозного шифрования" (e2ee) как раз в том, чтобы установить ПРЯМОЙ канал взаимодействия между двумя peers. Для этого и осуществляется обмен публичными ключами. Это можно сделать разными способами. Например, при личной встрече сосканировать QR-код, в котором указан публичный ключ. Или поделиться этим ключом через e-mail, SMS, голубиную почту и прочие средства. Но для большинства обычных пользователей, не замороченных на таких деталях, куда проще воспользоваться каталогом на сервере, который по какому-либо другому признаку (например, телефонному номеру) выдаст тебе публичный ключ. Этот вариант тоже поддерживается signal/whatsapp.
K>Значит всё же придётся им доверять и надеяться, что там не собирают кто с кем переписывается, откуда подключается и т.д.
Я же давал ссылку на sealed sender. Эта техника позволяет избежать отслеживания "кто с кем переписывается" — есть только знание "кто-то отправил сообщение на такой-то адрес". Подключение, естественно, в любом случае будет отслеживаться. Но это уже забота клиента, использовать VPN, Tor или что там еще получится.
K>Еще про получателя наверно известен номер телефона, IP-адрес? А зашифровано сообщение теми сертификатами, которыми ранее через этот же сервер обменялись.
Какой-то идентификатор (номер телефона ли, или e-mail, зависит от мессенджера) получателя должен быть известен. IP-адрес получателя заранее известен быть не может, получатель может придти откуда угодно. Или вовсе никогда не появиться.
Каждое сообщение зашифровано отдельным ключом по схеме double ratcher. Читать whitepaper до просветления! Без понимания, как это работает, исходный код будет темным лесом. В дебри (SCKA, Triple Ratchet) лучше не лезть, это даже мне трудновато понимать и обсуждать, но signal вроде как уже поддерживает.
Читать до просветления. За пару дней можно вникнуть, и понять, что заниматься взломом нет смысла. Проще применить терморектальный криптоанализ, или установить жучок ниже уровнем (я ведь уже писал про скриншоты, да?)
K>Но варианты, когда сам сгенерировал ключи, по альтернативному каналу передал публичный ключ собеседнику, мне видится безопаснее, чем когда один сервис пускает тебя по номеру телефона и весь обмен происходит через него.
Именно это signal и делает. И whatsapp тоже (как минимум делал раньше, сейчас я не смотрю за происходящим). Ну неужели так сложно заглянуть, а? Даже апп можно не ставить. Если нет веры, то можно в исходники заглянуть и даже самостоятельно собрать.
K>Естественно, большинству людей лень будет вручную всё делать, им приятнее взять готовое решение, которое всё само делает, пусть и с компромиссами, снижающими их анонимность, безопасность переписки и т.п. K>Но эти люди в большинстве своём и сами не знают от кого что скрывают и зачем.
Все правильно — вот для них и сделан тот самый каталог, который по номеру телефона даст публичный ключ.
SK>За короткое время было арестовано несколько групп террористов и несколько уничтожено, все они пользовались сигналом на чистых одноразовых аппаратах, регулярно их меняя и т.д. и т.п. SK>Плюс некоторые косвенные признаки.
На этом месте стоит воскликнуть "ИБО ВЕРУЮ!!!111"
И сразу отметить, что в ящике пива 24 банки. И в сутках 24 часа — вот это уж никак не может быть совпадением!
SK>Бритва Оккама из всех версий оставляет слив данных "сигналом" (или вовсе — изначальная разработка мессенджера и контроль серверов людьми в погонах).
Ничего, что я лично знаю "изначальных разработчиков мессенджера"? Разве что Moxie тайный агент, и погоны у него тайные. Но вот как он смог на github все это провернуть, так чтоб вот прямо у всех под носом, и никто ничего не заметил.
Короче. Спорить с аргументами типа "я так вижу" при отсутствии знаний и желания оные получить, как я понимаю, бессмысленно. Все равно ж не убедить. Каким бы предметным ни был спор. Думаю, продолжать имеет смысл только после ознакомления с базовыми основами криптографии, а также протоколом. В конце концов, не так это и сложно, собрать клиента signal'а, и потыкать туда-сюда, по-отправлять сообщения.
SK>Судя по описанию "кухни" ватсапа они этим целенаправленно занимаются.
Что в лоб, что по лбу...
SK>И перед началом переписки необходимо через какой-то другой канал связи вообще проверить, чтоб друг у друга ключики-то одинаковые. Или использовать что-то вроде PGP. SK>А этому активно препятствуют.
О ДАААА! Настолько активно препятствуют, что даже прямо предлагают это делать. И оповещают при изменении ключей. Чтобы полностью воспрепятствовать оффлайновой проверке идентичности ключей.
Жаль, нет иконки "квадрупл фейспалм".
Но на будущее, прежде чем писать глупость, хотя бы попробуй в гугле поискать. Там есть ответы.
J>Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется.
Как это "не потребуется"? А как ты будешь ПОЛУЧАТЬ сообщения? Чтобы получить "сообщения получателю А", как минимум нужно аутентифицироваться как "А".
Если же речь только про ОТПРАВКУ сообщений, то, да, там можно без аутентификации — именно так и устроен sealed sender.
J>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
И так тоже можно, соответствующая настройка имеется.
SK>В чем смысл шифровать каждое отдельное сообщение другим ключом?
Чтобы при взломе одного ключа шифрования все другие сообщения остались зашифрованными.
SK>Зачем у вас много ключей, для большей путаницы?
Потому что это РАЗНЫЕ ключи. Один ключ удостоверяет пользователя. Другой — сообщение.
SK>Стоп, но ведь несколько выше ты утверждал что каждое сообщение идентифицируется другим, новым ключем. генерируемым на лету пачками.
Правильно. Одно сообщение — один ключ.
SK>Выходит, этот QR ничего не идентифицирует, иначе он должен постоянно меняться.
Ключ ПОЛЬЗОВАТЕЛЯ — это НЕ ключ сообщения. Это ключ пользователя. Между ними есть связь — всегда можно проверить, был ли ключ сообщения сгенерирован вот этим пользователем. Более подробно см. https://signal.org/docs/specifications/doubleratchet/double ratchet
SK>ну да, ну да.
ИБО ВЕРУЮ!!! (С)
SD>>Сколько? И откуда такие точные знания, что вот там прямо-таки "закладка", а не банальное "не предусмотрели"? SK>Потому что изначально её не было, и она была внесена целенаправленно.
Да что за закладка-то хоть? Объясни, не томи. Что-то из очень свежего? Я только про xz знаю, что там кто-то пытался протащить уязвимость, и ему это (почти) удалось.
Кто, почему, и как (целенаправленно) внес? Хотя бы CVE номер приведи. А то я помню баг про IV, но там ни о каком "сознании" и речи не шло.
SK>В данном случае знание можно получить только изучив исходники сервера, самостоятельно подняв его полнофункциональную копию локально.
В самый последний раз спрашиваю. Если тебя end-to-end (клиент-клиент) шифрование, какая разница, что там делает сервер? Ну возьми и подними, даже можешь свой сервер написать. Это ничего не даст — ведь весь смысл е2ее как раз в том, чтобы верить серверу не требовалось. Все на клиенте.
J>Клиент общается исключительно со своей базовой станцией, а уже эти станции взаимодействуют между собой, роутя траффик, сохраняя всякие там сообщения, организуя синхронизацию между несколькими клиентами юзверя, организуя сетевые туннели, если нужно. Прям как почтовые сервера.
Вот на этом этапе все и ломается. Потому что chain of trust как-то нужно организовать. Где-то должен быть какой-то anchor, которому все доверяют. На настоящий момент таковыми является "список корневых сертификатов". Но как же ему верить, если нет возможности проверить, что там с ними творится.
Здравствуйте, SkyDance, Вы писали:
J>>Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется.
SD>Как это "не потребуется"? А как ты будешь ПОЛУЧАТЬ сообщения? Чтобы получить "сообщения получателю А", как минимум нужно аутентифицироваться как "А". SD>Если же речь только про ОТПРАВКУ сообщений, то, да, там можно без аутентификации — именно так и устроен sealed sender.
Ну ё-маё. Если мы говорим о мессенджерах типа Telegram, с неким центром, у которого работают сервера. Он может не требовать номера телефонов, а как по-старинке всё работало — username/password.
И вот каждый юзверь имеет некий никнейм с мессенджере, к которому шлют сообщения. С никнеймом связана пара username/password, и клиент мессенджера аутентифицируется на серверах по этой паре.
У тебя легко может быть несколько аккаунтов, несколько никнеймов, прям как раньше было.
Это чтобы принять сообщения. Чтобы отправлять — даже и никакого username/password не требуется.
Всё это было с электронной почтой годы назад. Всё работало.
J>>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
Здравствуйте, SkyDance, Вы писали:
SD>Вот на этом этапе все и ломается. Потому что chain of trust как-то нужно организовать. Где-то должен быть какой-то anchor, которому все доверяют. На настоящий момент таковыми является "список корневых сертификатов". Но как же ему верить, если нет возможности проверить, что там с ними творится.
Ты очень туманно выражаешься. Совершенно понятно, что каждый клиент у себя имеет список контактов, к которым прилагаются их открытые ключи и реквизиты базовых станций, к которым эти контакты приписаны.
Очень легко проверяется, что твой контрагент действительно приписан к некоторой базовой станции БС. Ты отправляешь на БС сообщение для контрагента, в котором просишь подтвердить что он действительно приписан к БС. Контрагент должен ответить утвердительно, снабдив ответ цифровой подписью, публичный ключ которой тебе известен. Все базовые станции также идентифицируются своими парами открытых/закрытых ключей.
Клиент у себя отмечает, какой публичный ключ у базовой станции, к которой приписан контрагент.
Вот тебе и chain of trust. Опять же, все эти базовые станции могут просто передавать зашифрованные сообщения, не разбираясь в их содержимом. Им полагается знать только адреса получателя и их БС. Действует end-to-end шифрование.
Я исхожу из того, что каждый юзер доверяет своей базовой станции. В конце-концов, он может поднять её у себя дома. Может держать БС для друзей, человек на 100. Может работать БС одна на фирму. Идея в том, что клиент может включаться/выключаться, связь пропадать. А БС работает непрерывно.
Как юзвери изначально установят отношения — здесь не рассматривается. Они могут обменяться своими публичными ключами, а потом ещё сверить их хэши по стороннему каналу, чтобы избежать подмены через MITM-атаку.
А друг друга юзеры могут находить по DHT, которую поддерживают базовые станции.
В DHT в качестве key публикуется никнейм юзера или хэш никнейма, а в качестве value хранится открытый
криптоключ, которым идентифицируется юзер и ещё реквизиты его домашней базовой станции.
Ещё можно поддерживать дополнительную DHT, по которой можно искать сами базовые станции.
Хочу сказать, что выделенные базовые станции могут куда эффективнее обходить всяческие интернет-блокировки, чем клиенты. Особенно на смартфонах. Например, БС можно запустить на домашнем сервере, где ещё поднять VPN, подключить сервер к нескольким провайдерам сразу, сделать возможным доступ к БС с нескольких IP адресов. Имеются большие вычислительные мощности.
J>Вот тебе и chain of trust. Опять же, все эти базовые станции могут
Ты сейчас описал e-mail, не упомянув разве что поведение relay. У e-mail есть куча проблем, включая необходимость строить chain of trust через сторонние механизмы — в частности, DNS. Не знаю, доводилось ли тебе устанавливать, настраивать и админить почтовые серверы (мне — более чем, от сравнительно простого mailcow до полного зубодробильного MS Exchange). Вот когда там дойдешь до DKIM, станет понятно, откуда берется trust.
J>просто передавать зашифрованные сообщения, не разбираясь в их содержимом. Им полагается знать только адреса получателя и их БС. Действует end-to-end шифрование.
Если есть e2ee, то зачем все эти сложности? Какую проблему решаем? Судя по всему, проблему "сервер знает IP-адрес клиента". В таком варианте "БС" является ни чем иным как VPN сервером. Ты можешь добиться ровно такого же эффекта и с signal/whatsapp, — ходи на них через VPN, и будет у тебя всегда один и тот же IP.
J>Как юзвери изначально установят отношения — здесь не рассматривается.
Так и в чем смысл всего описанного зоопарка, если основная проблема не решена? Проблема распространения ключей и является, пардон май френч, ключевой. Именно там больше всего претензий — если ключи раздает какой-то "сервер" или "каталог", веры таким ключам нет. А если есть "сторонний канал", то есть и e2ee, и что уж там посередине — серверы, роутеры или что угодно еще — значения не имеет.
