Этот мессенджер безопасен? (Часть 1)
BespalePhone0. Предисловие
Так, ну что, мои золотые, пришло время по-взрослому побалакать за мессенджеры
Любого здравомыслящего человека в наши дни беспокоят 3 простых вопроса: 1️⃣❓ возможен ли безопасный канал удаленной связи в принципе, хотя бы теоретически?
[и если да]
2️⃣❓ существует ли сегодня в природе практическая реализация такого канала?
[и если да]
3️⃣❓ как я могу этим пользоваться?
*Да, сразу оговорюсь: мы не обсуждаем gsm (звонки, смс, ммс) в принципе, ни в каком виде - это не может быть безопасно от слова абсолютно
gsm - все равно что орать друг другу из одного конца вагона в другой в час пик - вот примерно такой уровень конфиденциальности, поэтому сразу оставим эту тему
✔️Безопасный канал связи может быть реализован только через интернет - зафиксируем
**И да, оговорюсь еще, что ни один даже самый-самый безопасный и защищенный мессенджер сам по себе не может обеспечить безопасную коммуникацию, только - безопасный канал, и то.. еще дай бог справится
Безопасность коммуникаций - тема куда более обширная, там и анонимность, и сеть, и сам узел, и банальная гигиена, итд итп
protect ur communications, но вы уже, должно быть, в курсе😘
Содержание (ч.1)
0. Предисловие
1. Концептуально
1.1. p2p
1.2. server-based
1.3. рейтинг, методология, участники
2. Что и как считать?
2.1. владелец/разработчик
2.2. e2e-шифрование
2.2.1. симметрично-асимметрично
2.2.2. три проблемы шифрования
2.2.3. алгоритмы/протоколы
1. Концептуально
1️⃣❓ возможен ли безопасный канал удаленной связи?
В ответ на этот вопрос, как правило, начинают сыпаться малопонятные термины: e2e, p2p, decentralized/federated, ключи/сертификаты, aes, дифи-хелман какой-то..
Пойдем от простого к сложному, и для начала введем в наше уравнение:
a и b - это два абонента, которые хотят безопасно пообщаться друг с другом
И термин:
пакеты - это любое содержание интернет общения (и не только общения), текст - это пакеты, звонки - это пакеты, файлы - это пакеты, пакеты данных
Ну и для разминки рассмотрим сколь простую, столь же и утопичную концепцию - p2p.
Это красивая идея, о ней написано много замечательных слов и еще больше - лозунгов, она даже имеет несколько практических отражений в реальности..
Но суровая правда жизни разбивает всю эту красоту об (1) убогость исполнения и (2) фатальную несовместимость тех.условий с окружающей действительностью🤷♂️
Чем-то напоминает коммунизм, не правда ли?
1.1. p2p
Концепция p2p гласит:
безопасным может быть лишь тот канал, который установлен непосредственно между a и b, т.е. peer-to-peer - p2p
То есть, переводя на технический язык: посередине не должно быть промежуточного (маршрутизирующего) сервера, который бы принимал пакеты от a и направлял бы их b (и наоборот b ->a).
Пиры (a и b) должны неким образом сами находить друг друга в интернете и сами маршрутизировать друг другу пакеты.
И если говорить кратко - это тупо не работает, сообщения не доходят/доходят невовремя; звонки - 9ый круг ада: сбои, вылеты; клиенты - говно, недопилено, недоделано, лагает, крашится и прочие прелести безопасного общения.
Юзабилити, хотя бы базовое, хотя бы какое-нибудь - оно же должно присутствовать, нет? Иначе зачем этим вообще пользоваться?
Юзабилити не может дать много баллов, даже если оно очень хорошее, мы все-таки оцениваем безопасность.
Но если его нет - это жирный минус, это фактическая неработоспособность, техническое поражение.
Не было еще ни одного по-настоящему рабочего p2p мессенджера для телефона, и вряд ли он когда-либо появится.
Здесь речь даже не о безопасности канала, а о его принципиальной несостоятельности:
❌Нужен либо какой-то другой интернет, где каждому девайсу присвоится свой ip-адрес, однажды и навсегда (охуенно безопасно, правда?)
❌Либо чтобы каждый пользователь соответствующего p2p протокола носил с собой по небольшому маршрутизирующему серверу, по крайней мере часть из которых должна иметь опять же статический ip
Проблема p2p даже не столько в тотальной дисфункции, сколько в абсолютной бессмысленности.
Даже если по дороге от a к b не будет сервера мессенджера (=железки), то хуева туча других железок все равно ж никуда не деваются: от базовой станции/wifi-роутера, через сервера опсоса/провайдера, к распределительным коммутаторам и маршрутизаторам, по кабелям, по дата-центрам, из страны в страну - это и правда можно назвать p2p?
Разве что через briar, стоя на одной площади по wf/bt.. ну тогда зачем вам вообще интернет и, собственно, телефон? Вы же рядом, подойдите, пообщайтесь.
Прежде чем перейти к чему-то более реалистичному, оговорюсь, что существует даже p2p без сети. Сейчас заострять уже не будем, вот тут подробнее, если кому интересно.
Также, предчувствуя недовольство идейных, в частности указание на реально существующее воплощение p2p - briar, сходу направляю таковых изучать матчасть: начать можно отсюда, либо же сразу перейти к контрольному в голову: briar - не то что НЕ p2p, там даже сообщения не шифруются, идейные вы мои.
На этом оставим сию простую, красивую, чудесную, но абсолютно мертворожденную идею и проследуем далее - в реальность.
1.2. server-based
А в реальности такой интернет, в котором стабильный канал связи может обеспечить только промежуточный сервер.
Почему?
Потому что p2p никогда не решит следующих задач:
📍аптайм - (термин условный и не совсем верный строго говоря, но будем пользоваться им) т.е. доставка вовремя, т.е. a отправил и в течение 5-10 секунд b получил - если нет сервера, то как они найдут друг друга в моменте?
📍звонки - если нет аптайма, то как оповестить b о том, что a звонит ЗДЕСЬ И СЕЙЧАС?
📍хранение - если нет сервера, то где хранить пакеты, которые сейчас не могут быть доставлены, т.к. b не в сети?
следовательно,
📍файлы (фото/видео/документы/музыка) - вероятность успешной доставки стремится к нулю, собственно, как и отправки😁
Сервер посередине нужен, это удобно, это быстро, это практично, это реально
1.3. рейтинг, методология, участники
В любом случае, вовсе не факт отсутствия (или наоборот - наличия) сервера посередине обуславливает безопасность канала связи.
Это как с огнестрельным оружием:
это безопасно? или опасно?
Какая сразу появляется вариативность, правда?🙂
смотря у кого в руках/или в сейфе лежит, смотря на кого направлено, заряжено/нет, состояние, калибр, тип боеприпаса, дистанция, сноровка, доступность цели, итд итп
Также и с безопасностью канала связи - это куда более сложносочиненная сентенция, нежели банальная железка-посередине.
Чтобы ответить на вопрос "безопасно или нет?" придется учесть и сопоставить друг с другом целый ряд факторов, важнейшими из которых являются e2e-шифрование и открытость кода.
Мы тут в редакции такое усилие произвели, учли-сопоставили: собрали объективные и открытые данные, которые предоставили (или не предоставили) о себе #messengers, проанализировали их, структурировали, разнесли по параметрам, оценили каждый параметр в числовом выражении (баллы), в конечном итоге, посчитав итоговый балл для каждого участника, получили некий рейтинг.
Он весьма условный, конечно, весьма субъективный по части баллов, например. Но в то же время не лишен своей стройной логики, а главное - матчасти.
Редакция в рамках настоящего исследования в первую очередь ставит перед собой задачу аккумулировать и структурировать объективные данные, разобрать механику процессов и установить причинно-следственные связи.
Дорогой читатель вправе самостоятельно переоценить/перебалансировать рейтинг и/или его отдельные параметры/участников.
Нам остается лишь скромно надеяться, что дорогой читатель предварительно обременит себя изучением хотя бы части представленных данных.
Итак, дамы и господа, встречайте участников нашего забега (A-Z):
1. briar
2. confide
3. corpchat
4. deltachat
5. dstalk
6. jabber(xmpp)+otr
7. riot(matrix)
8. safeswiss
9. safeum
10. session
11. signal
12. telegram
13. threema
14. tox
15. twinme
16. uaround
17. vipole
18. whatsapp
19. wickr
20. wire
21. zangi
Участники подобраны по заявкам подписчиков, а также - на усмотрение редакции.
Кто-то наверняка не увидел здесь своего фаворита, но изучив наш рейтинг, поняв механику процессов и основные принципы, сможет легко сам(-а) оценить любого претендента, и скорее всего, по опыту редакции, оценка будет удручающая в лучшем случае.. увы, к сожалению🤷♂️
Хотя мы всегда готовы признать свою ошибку/недосмотр, если будут представлены объективные данные - будем даже рады.
Но хватит прелюдий, перейдем к мякотке
2. Что и как считать?
Для начала пробежимся по параметрам оценки, т.е. что именно и как именно влияет на безопасность того или иного мессенджера.
Обсчитываются и сочетаются друг с другом эти параметры.. весьма нелинейно, скажем так, логика будет видна в процессе.
Пока же просто поймем из чего состоит безопасный канал в принципе:
- владелец/разработчик - т.е. кто владеет/управляет сервером, и/или пишет (кодит) приложения/серверную часть (далее - с.ч.)
- е2е-шифрование - пожалуй самый сложный, обширный и запутанный параметр, вещь в себе, но в то же время - самый важный. Вкратце: е2е должно обеспечить неприступность пакетов по дороге от a до b и обратно, т.е. из-конца-в-конец, end-to-end, e2e, сколько бы железок между ними не находилось
- opensource - т.е. исходный код открыт для всех и каждого. Причем нас интересует код и приложения (клиента), и с.ч., это сдвоенный параметр.
Мы не оцениваем сам код, достаточно хотя бы просто: открыт он или нет, поверьте, это уже достижение - базовый функционал - т.е. (1)текст, (2)файлы, (3)звонки, можно ли этим безопасно пользоваться, если оно вообще присутствует
- андроид-разрешения - количество разрешений, запрашиваемых андроид-приложением. Неочевидный, можно даже сказать косвенный параметр, но зато весьма наглядный
- всякие фишечки (по безопасности) - т.е. запрет скринов, исчезания, таймеры, хуяймеры и прочее баловство. Дорого не стоит, но ладно уж, отметим
- юзабилити - это вообще работает? сообщения приходят? звонки прорываются?
Вот такие базовые параметры, по мнению редакции, следует рассматривать, если нас интересует безопасный мессенджер
2.1. владелец/разработчик
Ранее мы выяснили, что сервер нужен в любом случае. Но какой сервер? Чей? Что он должен делать? Как он это должен делать?
Но прежде чем перейти к совсем техническим аспектам, остановимся еще на одном простом и понятном, приземленном моменте:
чей сервер?
И хотя дальше, в наших стройных рассуждениях это должно стать технически-неважно, все же, по-человечески нельзя обойти этот момент стороной, че уж там.
Поэтому, владелец/разработчик - один из параметров в нашем рейтинге, рассмотрим какие тут могут быть варианты:
🟢 decentralized/federated - это самое лучшее, что может предложить нам мир на сегодня, это когда мы можем собрать себе свой промежуточный сервер, и сами все контролировать.
Что для этого нужно?
❗️Ну, во-первых с.ч. должна быть в открытом доступе - opensource.
Но одного только opensource'a с.ч., по скромному мнению редакции, недостаточно для того, чтобы получить положительный балл по параметру владелец/разработчик.
Opensource - это еще не true decentralized/federated
Например
И у ваера, и у сигнала с.ч. лежит в открытом доступе - бери, собирай себе свой ваер/сигнал.
Но красивая картинка упирается в суровую реальность: это совсем не так просто, как звучит.
Чтобы собрать "свой ваер" только на железо в мес нужно $200-250 (3 мощных сервака, по 6 виртуалок🙈в каждом).
Полагаю, с сигналом примерно такая же ситуация, к тому же "свой сигнал" не поддерживает звонки ни в каком виде.
Поэтому это НЕ тру-децентрализация, а так - красивая картинка, морковку привязали, в реальности нет этого - никто не сидит в своем сигнале/ваере.
Что же такое тру-децентрализация, спросите вы?
📌Жаба (jabber+otr)
она смело получает свой заслуженный балл по этой дисциплине. Ее легко и быстро можно собрать на самой захудалой vps'ке и получить все возможные преимущества по безопасности, предусмотренные протоколом
Тупо сравните в деньгах:
Мы берем всего 15к за поднятие и настройку жабы, + всякие плюшки по анонимности и защите, а сам сервак - ну $40-60/год (против $200/мес у вари и это - только железо, сколько будут стоить человеко-часы - поднять и обслуживать - даже считать не возьмусь)
🔜Также, есть еще один претендент на получение положительного🟢балла по параметру владелец/разработчик именно за тру-децентрализацию
И это - riot
Выглядит очень перспективно и многообещающе, вообще в целом, не только из-за децентарала, но и поговаривают, что собрать несложно..
Ну мы пока это сами не проверяли, поэтому балл пока не дадим, но возможно дадим позже, наш рейтинг ведь - не путин, можно и обновлять по мере развития событий😁
Думаю, в целом по децентрализации понятно:
если мы легко и недорого можем собрать себе "свой что-то" - это положительный балл по параметру владелец/разработчик
И такой балл пока только у жабы (riot догоняет)
Но по параметру владелец/разработчик есть и другой вариант получить положительный балл:
🟢[только не смейтесь] p2p
да, это нежизнеспособно в целом (по крайней мере пока), но это все еще очень и очень безопасно конкретно по этому аспекту, грубо говоря:
отправлять пакеты p2p уж никак не опаснее, чем через свой сервер
поэтому все p2p получает точно такой же положительный балл по этому параметру, как и жаба
Дальше по параметру владелец/разработчик у нас будет еще:
⚪️нейтральная оценка
сюда попали те, чья с.ч. - только их, никаких opensource'ов, что там происходит - знают только они, но при этом
ничего плохого вот так на поверхности о них не лежит
т.е. грубо говоря - хз, может нормальные люди, а может уебки замусоренные - нейтральная оценка, в общем.
Также сюда попал и ваер, потому что вроде бы и можно "свой ваер", но я что-то живого доказательства пока не видел, но и плохого по делу за них не слыхал (видео треугольника - это пародия на анализ, не рекомендовал бы на него ссылаться)
Вы спросите, а как же телеграм/сигнал? Они же во многом похожи вроде бы.
А для тг/сг и им подобных у нас тоже есть соответствующая категория:
🔴проблемы
сюда, помимо указанных тг/сг попали также вотсап с его фейсбуком, по результатам всенародного голосования - briar, ну и так скопом - сразу все ру-снг
Считайте меня предвзятым, параноиком, наймитом супостатов, кем покайфу, но ру-снг - это стремная хуйня (уж не говоря о том, что еще и максимально убогая по большей части).
Да, это предвзятая оценка, я даже немного опровергну сам себя впоследствии - кое-что хорошее наша земля все-таки родила в этой сфере, но в этом рейтинге, по параметру владелец/разработчик: ру-снг - это проблемы, и ничто не в состоянии изменить эту позицию, по крайней мере в отношении действующих участников забега
ИТОГО
владелец/разработчик
🟢tru-decentral/p2p
⚪️хз
🔴все плохо
Считаю, что этот сложный и неоднозначный параметр оценен весьма справедливо по сути: (1🟢) доверять можно только себе, (2⚪) но и обвинять огульно никого не стоит, (3🔴) ну а если уж кто зашкварился - пусть кушает
2.2. e2e-шифрование
Как уже сказано выше, шифрование - самый важный аспект при оценке безопасности каналов связи. Но и самый сложный, так что приготовьтесь, мы взлетаем.
Итак, наши пакеты снуют по интернету туда-сюда, и даже если не будет сервера-посередине (p2p), то там все равно еще очень много чего будет, через что эти пакеты пройдут и, не исключено, останутся навсегда (привет сорм-коробкам)
Нам в любом случае не избежать засвета пакетов по дороге от a к b
❓Соответственно, что надо сделать с пакетами?
✅Правильно, зашифровать
Из малопонятных терминов сюда относятся: e2e, aes, rsa, cha-cha, sha, hmac и, конечно же тот самый загадочный дифи-хелман (dh); также сюда относятся цифры, кратные восьми: 128, 256, 512, 1024, 2048, 4096, их обычно прилепляют справа к аббревиатурам, указанным выше.
Что это все значит в простом человеческом понимании?
Если пакеты, которые отправит a, будут зашифрованы таким образом, что расшифровать их сможет только b, то это позволит им обоим пренебречь сервером мессенджера (а равно любой другой железкой-посередине), т.к. весь путь пакеты пройдут в зашифрованном (т.е. нечитаемом) виде
Еще проще:
вместо наших сообщений/файлов/голоса - 08y977WD83563d3gd9736d8736dgd, вот что-то такое, примерно
и так на всех узлах (серверах) по дороге от a к b
Такое шифрование называется сквозным, или оконченным, или е2е.
Строго говоря, любое шифрование, если разговор идет о мессенджерах, должно быть только и исключительно е2е, иначе какая там безопасность. Но и здесь не все однозначно, впрочем вы уже должны были бы привыкнуть😁
е2е - вообще очень размытый термин.. точнее термин-то нормальный, а вот применяют его куда не попадя, потому что это не какая-то конкретная технология, а набор технологий + практик. Ну а где практика, там человек, а значит и дьявол опять в деталях копошится где-то рядышком.
Ну и перед тем как перейти уже к этим деталям, усвоим еще парочку базовых постулатов:
№1
шифрование ВСЕГДА происходит (совершается) по АЛГОРИТМУ и/или ПРОТОКОЛУ
№2
шифрование ВСЕГДА подразумевает под собой КЛЮЧ(-И)
Разжуем:
АЛГОРИТМ/ПРОТОКОЛ - это условная формула, например
s+k=p
где:
s - наше содержание (текст/файл/звонок)
k - КЛЮЧ шифрования
p - финальный пакет, представляющий из себя наш текст/файл/звонок, зашифрованный ключом
Так вот
даже из этой нехитрой математики наглядно явствует: безопасно - это когда в мир мы отпускаем только p - финальный пакет, потому как если этот коварный мир получит еще и k - КЛЮЧ, то легко расковыряет наше sодержание обратно:
p-k=s
Объяснение схематичное, в реальности формулы посложнее будут, конечно, но суть, надеюсь, уловили.
2.2.1. симметрично-асимметрично
Но какими бы сложными ни были формулы, т.е. алгоритмы/протоколы шифрования, их общее количество и вариативность - весьма скромны. А базовых принципов - так и всего два: симметричное и асимметричное.
🔄Симметричное шифрование
Если для шифрования и дешифрования пакетов используется один и тот же ключ🔑 - это называется симметричным шифрованием. Т.е. у a и b есть один и тот же, одинаковый🔑ключ, с помощью которого они шифруют свои пакеты и дешифруют пакеты друг друга
↪️↩️Асимметричное шифрование
Если для шифрования и дешифрования пакетов используется два разных ключа🗝🔑- это называется асимметричным шифрованием.
Т.е. у b есть пара связанных друг с другом ключей: открытый🗝 и закрытый🔑
Открытый🗝 он передает a в любом виде: хоть в городской газете печатает, а вот закрытый🔑 - оставляет себе и никому не показывает
Теперь a берет открытый ключ b, шифрует с помощью него исходящий пакет, после чего b дешифрует этот пакет с помощью своего закрытого ключа
Еще можно сказать так:
⤴️чтобы отправить кому-то зашифрованный пакет - нам надо узнать открытый ключ персонально этого кого-то
но
⤵️чтобы расшифровать любой входящий пакет, от кого бы он ни был - нам нужен только наш персональный закрытый ключ
И на первый взгляд очевидная проблема симметричного🔄шифрования - сам ключ🔑.
Собственно, ключ - это же тоже пакет, текстовый файл, а его же надо как-то передать и a, и b (распределить), чтобы они уже шифровали/дешифровали с помощью него дальнейшие пакеты.
А как это сделать-то? В голом виде же не пошлешь, вспоминаем формулу p-k=s, подарим ключ - подарим все.
Дилемма получается..
Как бы асимметричное↪️↩️шифрование - ответ на эту дилемму (весьма условно и весьма условный), где свой открытый (публичный) ключ можно распространять по каким угодно дырявым каналам, т.к. с помощью него можно только ЗАшифровать пакет, а вот для РАСшифровки потребуется уже закрытый (приватный) ключ, который передавать никуда не требуется.
Казалось бы, идеальная схема
2.2.2. три проблемы шифрования
1️⃣❗️Но проблема распределения ключей лишь на первый взгляд касается только и исключительно симметричного шифрования, и лишь на первый взгляд решается с помощью асимметричного.
И это лишь та проблема, которая лежит на поверхности.
2️⃣❗️Существует еще угроза MITM (man-in-the-middle, человек-посередине). Т.е. на одной из тех самых железок, через которые проходят пакеты между a и b, может сидеть плохой человек-посередине, который будет всячески перехватывать и подменять пакеты обеим сторонам, в частности подменять ключи, выступать в роли b для a и в роли a для b, расшифровывая таким образом весь трафик посередине, на себе - фейковом собеседнике для обеих сторон.
3️⃣❗️И существует еще одна проблемка с шифрованием - правдоподобное отрицание, также это называют - отрицаемое шифрование.
Смысл в том, что когда и если будут спалены те или иные ключи, то у a и b должна остаться правдоподобная (т.е. обратное - недоказуемо) возможность сказать "а это не мое/не мне/не от меня" и в отношении самих ключей, и в отношении содержания.
В данном случае, конечно, еще большой вопрос к самому содержанию: если там окажется наш паспорт, к примеру, то будет довольно сложно правдоподобно отрицать. Но и все же, несмотря на кажущуюся человеческую природу этой угрозы, на самом деле, сегодня - она вполне техническая.
Вышеуказанные 3 проблемы в действительности представляют из себя один большой взаимосвязанный клубок, например:
2️⃣❗️ человек-посередине перехватил ключи, вследствие их 1️⃣❗️ неправильного распределения, после чего предъявил a и b переписку, которую 3️⃣❗️ невозможно отрицать, т.к. установлена цепочка принадлежности: человек-ключ-пакет
Зафиксировали
2.2.3. алгоритмы/протоколы
Теперь давайте развернем это все на практике, и немного - на исторической перспективе.
Но перед этим до конца проясним терминологию:
алгоритм шифрования и протокол шифрования - это одно и то же или разные вещи?
Алгоритм - это про умножить, возвести в степень, поменять местами, отнять, прибавить, вычислить функцию - т.е. именно зашифровать, превратить читаемое в нечитаемое, сугубо математический механизм.
Протокол же - это про как, куда, кому, сколько, когда, как часто - т.е. окружение алгоритма.
Конечно, оговоримся, что и эта терминология, и это разделение - опять же весьма условны, кто-то называет свои протоколы алгоритмами, и наоборот, но мы будем для удобства пользоваться такими определениями:
алгоритм - математическая суть
протокол - применение/окружение/реализация алгоритма