Маркетинг и End-to-End шифрование в популярных месседжерах

А разве ватсап петушится на тему «мы офигеть какие секурные, АНБ сасёт»? Не слышал такого. Кажется на эту тему, из попсовых клиентов, петушится только телеграмм.

Во всех СМИ пролетела инфа: «Месседжер WhatsApp теперь использует end-to-end шифрование». Погугли даже. Но в это же время в самом вацапчике более мягкая формулировка о каком-то шифровании... В то же время в СМИ не раз пролетала инфа о том что они не намерены выдавать переписку интересующимся и типа не могут этого сделать.

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

Но вдруг, абонент A открывает зондобраузер (Хром в данном случае) и пишет сообщения абоненту B через веб-морду, а потом еще и читает... О каком end-to-end может идти разговор в данной ситуации?!

End-to-end шифрование работает между двумя устройствами, а не между двумя аккаунтами. Поменялись девайсы - начинай всё сначала. Я уж молчу, что по идее никакой синхронизации между устройствами в таком случае быть не может.

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

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

Протокол Диффи — Хеллмана прекрасно описывает логику end-to-end - одно устройство - один ключ и только два абонента. Все остальное нельзя называть end-to-end. Даже сама формулировка end-to-end как бы подсказывает нам свой принцип работы. А тут какое-то end-to-end-end-to-end-end-to-end-end-to-end-end-to-end-end-to-end-end-to-end-end-to-end-end-to-end-end-to-end....

А разве вебморда вацапа не тянет сообщения с телефона?

Т.е. тянуть сообщения с телефона могут все? О каком end-to-end тогда речь? Зачем тогда пафосные заявления вацаповладельцев, что они не могут читать переписку. Ведь могут же. Могу вообще все! И более того эта переписка как выяснилось - довольно не плохой товар.

DH это всё-таки про обмен ключами (выработку общего ключа), а не про шифрование.

Кстати может мне кто-то объяснить как в практических реализациях DH решается проблема активного (способного модифицировать сообщения) посредника? Алисе и Бобу всё-равно нужен какой-то доверенный канал обмена информацией или доверенный посредник что-бы проверить подлинность сообщений собеседника отправляемых им в рамках протокола DH. Бобу нужно как-то убедится что сообщения ему присылает Алиса, а не Мелори притворяющийся для него Алисой (а для Алисы притворяющийся Бобом).
В этих наших интернетах наивный DH не помешает сервис-провайдеру, или товарищю майору, или соседу-шкальнику заделаться Мэлори.

Без передачи ключей по протоколу DH ни о каком end-to-end в конечном итоге и речи быть не может! Это одна из основ.

Т.е. любые другие мыслимые методы обмена ключами не тру просто по тому что они не DH?
Мне всю жизнь казалось что главное это что-бы сообщение шифровалось Алисой, расшифровывалось Бобом и кроме них двоих ключа не было ни у кого (в случае симметричной криптографии). А уж как именно Алиса и Боб договорятся о ключе — дело десятое, лишь-бы ключ был только у них.

И что там с Мэлори-то? Что-то я с ходу не нашёл никакой инфы кроме того что нужна дополнительная аутентификация. Нормально гуглить в 4 утра как-то впадлу.

Например? Какие протоколы мы еще знаем? Kerberos? Ну, он как-бы предполагает клиент-серверную архитектуру взаимодействия и ставит под сомнение принцип end-to-end. Шифрование, да - он реализует, но не более того.
Я говорю про end-to-end. DF это одна из самых удобных реализаций обмена ключами для этого. Или как по твоему реализовано end-to-end с учетом описанного в треде? Тред про отсутствие end-to-end как-такового и маркетологов с журналистами. Хотя нет, тред про хомячков.

Любой асимметричный алгоритм, хоть RSA.
Сгенерировали ключевые пары, обменялись открытыми ключами - и поехали

В e2e шифрование у такого по как WhatsApp, Viber и прочие я не верю. Например, WhatsApp принадлежит facebook и заработок этой канторы так или иначе от обработки личных данных, какой им смысл поддерживать дорогостоящую инфраструктуру на 1 миллиард человек чтобы хомячки общались с друг другом на шару? Смысла нет. Поэтому e2e шифрование в WhatsApp не более чем маркетинг. Возможно! e2e действительно правильно реализовано в Telegram. Может быть много вариантов зачем Паше тратить по 1 миллиону $ на содержание Telegram, just for fun, нагнать побольше хомячков и потом продать или прослыть меценатом несущим доброе и вечное, хз, но у меня доверия к Telegram больше. P.S. если мне нужно передать что-то действительно! важное, то сделаю это через tox, jabber+ort или e-mail+gnupg

обменялись открытыми ключами

Вот это как-раз самое интересное. С шифрованием-то всё уже более-менее хорошо, а вот как обменяться ключами?

Вот я тебе говорю что вот то мой публичный ключ. А от куда ты знаешь что тот ключ который вижу на своём экране я и ключ который видишь ты это один и тот-же ключ, что адский Макском не подменил его? А ведь если ты будешь шифровать сообщения адресованные мне ключём Макскома то он сможет их расшифровать.
Нам нужен как-то внешний (по отношению к RSA) способ подтвердить подлинность наших публичных ключей. Так-что RSA не решает адачу обмена ключами. Известные мне внешние способы обмена ключами либо зело неудобны, либо требуют каких-то «волшебных» ресурсов (например канал передачи данных который вот просто защищён от любых атак), либо решето, либо всё это вместе взятое.
Топикстартер топит за DH, но он всё-ещё не объяснил мне как там обходится проблема Мэлори, а ведь она превращает DH в то самое решето.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQINBE6gI4YBEADeF5Cs4i/6De6zZNoUu4P/U+HZ0NsuxVZDcuJf3wM4bJKxAnoN
4FleFVHv7B7YTHrUr5mc7WBdNen3LZR0U6uC5jpTsIoRucnyxRdVUcJlKxgJsJA5
JPz05o5JFPeT2J/p9qbVZCVU6L921cq/oqtBtVNDkNvauLRIjJzo5spflOpzY4nV
6TvvBdukLXwmdwb9k8/xITXWuGmHWxKpZfL6LfvvfwV/pRHZWzqWNuYohnthKwsv
91JMX5Pw6GCR03FCWRV8hOH+qq4dGCY3PdbYxVlqn69E9eWXTjLrHX9U+X+bJuYw
wf7Zmlm4/0WEk0EdI3XUgajKpqqE10UG3OwieMmr1PgU8cnFtughC+5bwFn2Lmq0
tjOmG8FxrZOCis3cAfalP6kMr7itA4/C+vDZZy6ZQoDXlxHiBfErSQKksz2Pw2dq
oihxoUjJMsZKHnukZMaNMZP0RmnyckuK234ThHo5IkJRirXj2feEq51lugsnHN80
BIX1QvPrDKDKJcA5NVPcMJO2/T6nZ7WMK/SH3fO3YKTwndEjds2NmX4ht/EOIZlf
SW/sCc+lEjq4U6SrwriHU8UrgJBm9UTX+VkwuR6oCODk8Mx6lDIkkkQSFikq/fY0
N3NZrBAfBZA0Xki2RbHHv/uHgW0um8h2bme1SNhTQO1cm2wv0lTc5R54hwARAQAB
tB1NckNsb24gPE1yQ2xvbi5ydXNAZ21haWwuY29tPokCOAQTAQIAIgUCTqAjhgIb
AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQnwi6U9yEGj9yLBAAisv19I14
800LuobhZlXTb5gXEJ6kanzKSnUNKrGur3rF7y2UepaKf9fXbT9zaLeaPaqYmX+n
OoXfg3r3kX8mtVx1fwmq2cW0ZkpfraWAyf7rMxrMW5JIWGpILvnbYQ53IesKBTCR
O18R8NUYIxwQrksy5gHeRMwHqCM+ZL1Rnu3/fDFJnwlYxg1cx8xc7W440YiByzME
Rtc8gI0pTZ7quZxTm5V16TeWk9XHXdoWxjR7qhAk38gDD9ZJR5gy4k6dAAz+bbhY
9bFXDjANnRWxDMWNsQA7L272LBdE+gojkuzsD61SE5vUlsdUMsUiL4WRdPfi+/BR
6WhOnRq4ngSMsNh/gf4uZd2ZgQm5Su3rBTzFosr8jL/ehaXVTobmyfeCbiJj45Gw
kTyTwSvqzp1uFcpcBk2gHi2qw5gjFomzYReF1BPCbQhZFk1y1VHSI1COlDyuLIlK
L6VAucubpD1wtL4WUdiIFH/0VRhLOCRU/83vp0vrKAnMwCi61D0Z2QtbEuIyjK/0
CN7ZA9zJzHq874ICi7qKO6F1y6yib+usN6HIBEbeXguSqkTrF/8cPPbSutcr1oWf
d77JUPozs9FwXuef54JPZco/VBfNiuZlstUqCj9hNdGVV7adT99vwt2jBKZX65B+
/tazNnghl/0bKDH4qLreKj6wdiiRqrLQ6Ly5Ag0ETqAjhgEQALwpnw7A9OO02Rk5
Xc6QlfJ/Psi+geti9I2H4OOEjDn7b8fJHeItk/GBOeLh/A7Fl3oRUGWHEpvaYhWb
XCGs2Y1WiLVVin9BzIdqrZ4Fg6hag7gYqihHxxiSuYpHcD6jxtE66BPCFJjm7+rS
/ZdgUrTzicBs5wCwV2JrXEn6VlAzMg/a09fzbCHgYexLvGhY/QX3LIkasM8nkmmV
ktnCnvnLRQ3V8fRB1jDVQHDuasDw5xGuwPORKK7C5IHI5Xj4qCW7cu45NW27JlMX
3/PHADGjpV+95mdHFdHZEuh/eCQWnaFYAPtYAqRBYAaxzEKTr4EWBuM20mh541IS
JkgX1UEzXpDWDQgl98r94Z+4yBEyrMUIaWLA0JXL3Q+0IVpDwL7yHKtoj/V8yHTC
4ftiqXUiEJyv+6qHqC9NlVs2FT+KcbYteYwRz3LiMj3PipJP4f7RrXj8QhcRe24T
EQC10iFIQC3LBPceT8JgBFDCY88vdLAID76S4N31wbcLKKmeqCiXP4ytoPiQGuHB
fXYnEFrPujUwxmL/7EE1zWCWlnExYvJN6wuuRmUyc5+ggicU8+SRM6eimy1tYUFC
adga75QlxQAo7mdP33Xop3ifG6NyBwJxPPO6AKqy7O7adjceaWraZis4i3VGeFb/
jcDhJeCt0dD+aeF+GbgOg8sW1QyVABEBAAGJAh8EGAECAAkFAk6gI4YCGwwACgkQ
nwi6U9yEGj87CxAAxYLWtYhu5c0TKcTdDH5iD4aE/v2wsPZeh7BgfRiR+IMpCI6s
pC5/32HiNI6nkvXtyWrqpdBBapk8T3zTx3HAOJOwqcS6wKA66rfBrBNjpO/NotxN
YMR49LqzpPAwfVQrF6DbAZLhLcARQKq/npM3xJL/has5iG695JsKpddufHOXJbHJ
6z3jbLEIxfikNGjuI2wsFjNyOW5vsFkZwQmbmK1hbu3ADQ2yYYZXrozP9+7ZfUNg
w8PS/fvgDR+WKCoxjodgvdb1jdtE19YD0CtWvYpwmqxPzwgOHXUrTKAgx8FRdfAo
ZKPFG5tLyXDoGqzzdKJ99MM5NGiZ7o/rkvghxtEVDD+lxhD55k/NpvTCgr6ftFIF
7ki6D2BI2lm1Lm7WbMYXIqxr5HkCr8ZuDlmZrA3Y5Q/yCkT3d89KUbAAjWVXnHGe
Mpo9dYUFPyVHnbx4O626JTf/3WMzFMOpugHfGhwkesh0u8fSalo7EJ/+Y5Fsw9Qm
6mXiPadvVWyLP5nvy70h5Ljsj4zFK21RrQ7GJ7XAqiPdE0TCcKOjwrG54Qg8ZqI/
o1azFSMwFhthKRb0Ua2INqIXHvWTU/DyFcl9LuO2bny0m3mgpdC7o5WKuHLAyNV5
WSWvyWWVpVSPpBKS4xP+q4PGj7PFqo7GcslRop/IfVL9LZ/NtcQJaUsWplU=
=g6kF
-----END PGP PUBLIC KEY BLOCK-----

Я не говорю что DH надо закопать в пользу вон того очишуенного решения, я говорю что DH тоже решето, жизнь — боль, мир — иллюзия, вселенная — голограмма, покупайте золото.
Точнее я прошу объяснить мне как в софте адекватно использующем DH обходится проблема превращающая его в решето.

А про то как, по моему мнению, реализовано e2e шифрование в ватсапе уже выше сказал один оратор — скорее всего никак или очень неправильно, скорее всего кукарекание маркетологов это просто кукарекание. А что ты хотел от подобного сервиса?

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

Пересылать открытый ключ через несколько разных источников.

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

Снижает вероятность успешной подмены, но принципиально вопрос не решает. К тому-же усложняет процесс.
И ещё проблема: допустим я сейчас скину TheAnonymous-у свой адрес JID что-бы передать публичный ключ и там, но как TheAnonymous убедится что злой Макском не подменил и мой JID? Ведь ему даже дополнительно ломать ничего не придётся что-бы скомпрометировать и второй путь передачи.

Также ты не можешь быть уверенным что TheAnonymous и не является самим Макскомом. Видимо, поэтому некоторые люди и обмениваются публичными ключами при личной встрече.

В чистом виде алгоритм Диффи-Хеллмана уязвим для модификации данных в канале связи, в том числе для атаки «Человек посередине», поэтому схемы с его использованием применяют дополнительные методы односторонней или двусторонней аутентификации.

Это понятно. Т.е. это тоже не панацея, но тем не менее это безумно популярных хоть и слегонца дырявый алгоритм.

Сам придумал какой-то бред, сам ему удивился.

скоро проблема с этим ватсaпом исчезнет, когда все перейдут на убунтуфон, а там ватсапа нету.

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

Promusik ★  параноик

Почему я не удивлён.

По теме - всё можно взломать. Было бы желание, ну или паяльник.

Я всего-лишь говорю про псевдо end-to-end. Это чтобы хомячки не удивлялись если что-то пойдет не так после их переписочек...
А вообще паранойя это просто потому что 1984 скоро. Но ты не парься.

Синхронизацию запилить совершенно не проблема. Соединяешь два девайса пользователя все по тому же протоколу и синхронизирует.

два девайса

Не три, не восемь, не 150! Два! Два одновременно в один сеанс работающих девайса.

Можно и больше. Не вижу проблемы.

и синхронизирует

Закрытый ключ?

e2e нормально только в tox реализовано.

DH подразумевает участие двух участников обмена. Ключи (если их никуда не передавать) хранятся на двух устройствах. Если ты куда-то передал ключи, то считай такая переписка будет скомпрометирована

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

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

как TheAnonymous убедится что злой Макском не подменил и мой JID?

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

https://en.wikipedia.org/wiki/Station-to-Station_protocol

Они должны быть оба онлайн в таком случае.

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

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

Хотя можно придумать схему защиты и для этого. Например:
1) Браузер генерит пару RSA ключей
2) Добавляет информацию об открытом ключе в QR-код
3) Смартфон шифрует твой секретный ключ на открытом ключе браузера и отправляет в вотсап
4) Браузер обращается к серверам вотсапа и скачивает твой зашифрованный ключ
5) Браузер расшифровывает твой секретный ключ на своем закрытом ключе
6) Профит

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

Например, в телеграмме проблема доверия серверу при установке клиента решается «прошитым» в приложение открытым ключем сервера, что позволяет организовать передачу сгенерированного клиентом ключа по закрытому каналу на сервер.

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

На самом деле, кмк, проблема несколько надумана. Если нужно доверие к контакту, то только обмен ключами при личной встрече. Но и при этом, никто не исключает ситуации, что при e2e-диалоге, на той стороне будет совсем не тот человек, чей ключ используется.

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

В telegram предлагают сравнить визуализацию хэша ключа с визуализацией картинкой на телефоне того с кем начинается секретный чат.

В Signal по идее сделано тоже самое, но для звонков визуализация сделана фразой, а для текста QR кодом. Плюс шифрование расчитано на то, что при первом разговоре MITM не было, а если ключ собеседника изменился то оно об этом пишет.

WhatApp использует протокол Signal и реализация там соответственно такая же, но дока лежит тут.

https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

в ватсапе броузер показывает уже расшифрованные сообщения с мобилки - поэтому ему обязательно нужно чтобы на телефоне мессенджер был запущен

Не обязательно. После соединения девайсы могут между собой синхронизировать историю.

Это передача ключа третьему клиенту. Это с большой долей вероятности вызывает компрометацию и противоречит принципу e2e

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

Запущенный месседжер в телефоне это всего-лишь псевдозащита вацапчика, дающая чувство защищенности хомячкам, но она никак не объясняет компрометацию ключей и нарушение принципов end-to-end шифрования.

пруфы будут? Где именно скопмроментированы ключи?

Не вижу компромитации. Я лично соединяю мои устройства между собой, используя другие ключи шифрования. И канал в данном случае - защищенный. Если у тебя устройство не зашифровано и не защищено паролем, то это ссзб, а не компромитации.

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