В популярной системе обмена сообщениями WhatsApp выявлена (https://tobi.rocks/2017/01/whatsapp-vulnerability-bug-or-bac.../) уязвимость, которая позволяет (https://www.theguardian.com/technology/2017/jan/13/whatsapp-...) владельцу сервиса (Facebook) и другим заинтересованным спецслужбам перехватывать и прочитывать зашифрованные сообщения. Проблема вызвана тем тем, что сервис WhatsApp может принудительно сменить сгенерировать новые ключи для пользователей, которые в данным момент находятся вне сети (offline), без ведома отправителя и получателя сообщений.Уязвимость рассматривается некоторыми исследователями безопасности как преднамеренный бэкдор - Facebook был уведомлен о проблеме ещё в апреле прошлого года, но уязвимость до сих пор остаётся не исправлена.
Сокрытие проблемы и игнорирование выпуска исправления может стать серьёзным ударом по имиджу WhatsApp, учитывая то, что ранее Facebook заверял пользователей, что применяемое в WhatsApp end-to-end-шифрование исключает любые возможности перехвата сообщений, в том числе персоналом WhatsApp. Тем не менее аудит реализации протокола показал, что на деле компания Facebook имеет возможность чтения чужих сообщений, осуществив замену ключа.
Проблема не касается применяемого для организации связи протокола Signal и связана конкретной особенностью механизма передачи сообщений пользователям в offline. Для end-to-end шифрования сообщений применяются уникальные ключи, которые подтверждены обоими участниками обмена сообщениями. От имени получателя, который в данный момент находится вне сети, может быть анонсирован новый публичный ключ, после чего механизм доставки на стороне отправителя автоматически перекодирует этим новым ключом все сообщения, ожидающие отправки.
Таким образом отправленные сообщения будут зашифрованы не оригинальным ключом собеседника, а подставным ключом, который сгенерирует сервис. При этом собеседник не узнает о том, что адресованные ему сообщения ушли не туда, а отправитель получит уведомление о смене ключа только если явно выставит в настройках соответствующую опцию и то, уведомление будет выведено после отправки с новым ключом. Примечательно, что оригинальная реализация протокола Signal вместо автоматической переотправки с новым ключом, блокирует доставку подобных сообщений и отправляет уведомление отправителю.URL: https://www.theguardian.com/technology/2017/jan/13/whatsapp-...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45851
цирк
блондинке-кухарке в опсасносте!!!
Да, вот как раз недавно блондинки-кухарки на нём погорели - http://www.kommersant.ru/doc/3189252
не, блондинки-кухарки разносят новость о том, что кто-то там, якобы, погорел
Если ключи генеряются на сервере, а не на клиенте, то о какой безопасности вобще можно говорить?! Это же голимый лохотрон! :)Раньше лошков на рынке с напёрстками разводили, а сейчас им тупо втюхивают скомпрометированные ключи и уверяют, что клиент в безопасности ))
...и сколько клоунов в нём (кто этим пользуется).
если уйти от версии бэкдора, то как по другому организовать доставку offline сообщения при условии, что собеседник может быть offline потому-что он утопил телефон, а с новым у него будет новый ключ?
Уведомлять отправителя о смене ключа получателя и запрашивать отправителя о необходимости повторной отправки сообщений, и только после явного подтверждения перешифровывать новым ключом и отправлять.
>Проблема не касается применяемого для организации связи протокола SignalМожет хватит уже пиарить это УГ, к которому даже создание альтернативных клиентов лицензией запрещено? Какая тут безопасность может быть?
GPLv3 запрещает альтернативные клиенты? Аноним, ты хорошо себя чувствуешь?
Увы, Moxie яро против альтернативных клиентов, использующих их серверы (это важно, т.к. серверная часть у Signal не open-source), и прямо об этом сказал форку Signal LibreSignal:https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Я это знаю, и теоретически осуждаю :-) Но, это совершенно не равнозначно утверждению "лицензия запрещает форки". Форкай, но поднимай свою инфраструктуру.
Кстати, серверная часть висит на GitHub:
https://github.com/WhisperSystems/Signal-Server
Он там вполне четко говорит, разворачивайте свой сервер и пользуйте свой клиент, мы вам не мешаем все исходники есть. Ну и жалуется что не так просто держать содержать это все. Видимо боится проблем связанных с кривыми неофициальными клиентами.
Серверная часть у Сигнала вполне себе opensource, это вы с Телеграмом перепутали.
Послать его в пешее эротическое. Он не имеет права диктовать, какой код нам использовать на своём оборудовании и какой код использовать, чтобы коннектится к его инфраструктуре.Пусть там хоть захлебнется в желчи неодобрения, но ребята с LibreSignal делают всё правильно.
Он имеет право диктовать практически что угодно в рамках своей инфраструктуры, если это не противоречит его локальному законодательству. А ребята из LibreSignal рискуют получить повестки в суд.
Альтернативные реализации открытого протокола запретить никто не может.
Axolotl Ratchet используется в OMEMO - XEP XMPP работающий на стороне клиента, а на стороне сервера задействующий уже существующие расширения.
https://conversations.im/omemo/
Любой клиент и любой сервер, поддерживающий требуемые расширения.
Бесполезно спорить. Наш Аноним не смог даже зайти на GitHub, чтобы посмотреть какая там в реальности лицензия. А вы ему: Axolotl, OMEMO, XEP.
Какая разница в контексте поддержания связи людьми, сможете ли вы технически поднять свой сервис с преферансом и гимназистками или нет, если ваши контакты останутся жить в экосистеме WhatsApp?
Честно, вы читаете перед тем, как комментировать? В этой ветке разговор о Signal, а не WhatsApp.
> Может хватит уже пиарить это УГ к которому даже создание альтернативных клиентов лицензией запрещено
> применяемого для организации связи протокола SignalНу как бы можно получается. WhatsApp протокол же использует.
Вот они последствия того, что клиент и сервер имеют одного разработчика. Аналогичная претензия относится к web-клиентам вроде тех же Telegram, Wire, Skype на Electron. Производитель ПО может без вашего ведома изменить алгоритм работы программы и все ваши зашифрованные разговоры будут известны большому брату. Только XMPP, PGP, S/MIME.
У телеграма клиент опенсорсный на гитхабе лежит.В XMPP протоколе есть все, но клиента к этому так никто и не осилил: 2017 год на дворе, а они только текст отправить могут.
Pidgin? Conversation? Xabber?
XMPP это такая-же мутная ботва как и SIP. Каждый понаписал и понапродвинул своих драфтов и РФЦ несовместимых между собой, мотивированный полутора юзерами и гениальными маркетолухами которые захотели очередную уберфичу. В итоге имеем дремучий РФЦ и вязанку костылей категорически несовместимую с другой вязанкой костылей, и оговорку, что гарантируется только базовый набор фич, а кто не все тот сам себе Буратино.Одепты нереализованых фичей исторгают из себя плач Ярославны.
Опенсурс код клиента Телеграма выложили только один раз год назад, больше его никто и Павел Дуров не торопится выкладывать коммиты
> Опенсурс код клиента Телеграма выложили только один раз год назад, больше его
> никто и Павел Дуров не торопится выкладывать коммитыТак оно вродеж вполне обратно совместимо. Кто не одепт блидинг эдж тот сидит "на один раз год назад" и не парицца....
https://github.com/telegramdesktop/tdesktopСдается мне, что анонимус просто врет. Я вот вижу, что последний коммит 23 часа назад. Я понимаю, что у тебя рабочая задача обсирать телеграм и врать про него, но делай это тоньше.
irc забыл. он так должен быть номер 1, по идее
С зоопарком русских кодировок как в 1990-е? Не, не нужно.
> С зоопарком русских кодировок как в 1990-е? Не, не нужно.Use utf-8, Luke.
А что скажете насчет Ostel с клиентом Jitsi.
Правда, чат там идет нормально, а говорить по нему не получается, звук идет с задержкой и жуткими искажениями.
> и другим заинтересованным спецслужбамТонко.
Просто свое комьюнити с опенсорцом для спецслужб.
Эти истории будут повторяться, до тех пор, пока люди не осознают всю серьезность положения и не сделают нормальный децентрализованный месенджер.
Кто ищет, тот найдет.
Сейчас эпоха мобильных клиентов, им необходимо тратить как можно меньше батареи и трафика. С одноранговой архитектурой клиент участвует в трафике сети, что неприемлемо для мобильных устройств. Оптимально использовать федеративные протоколы, такие как XMPP.
Кроме того, в мессенджерах с одноранговой архитектурой не существует хорошего решения для офлайн сообщений.
Стоит только предположить, что в сети есть довольно приличная доля вполне себе стационарных машин на хороших каналах - и всё становится проще. Простейшая алгоритмика синхронизации нескольких клиентов под одним логином и хранения (зашифрованных) сообщений - например, для явно указаных избранных и по их запросу - и проблем с оффлайновыми соообщениями тоже нет.Опять же, это не означает, что промежуточных серверов быть не должно - но это должна быть не федерация вроде XMPP, а просто системы кэширования, даже если с регистрацией - то она не должна быть частью идентификатора полльзователя. Ну там - после регистрации клиент рассылает по контакт-листу "сообщения для меня готов принимать вот такой-то сервер".
>>Простейшая алгоритмика синхронизации нескольких клиентов под одним логином и хранения (зашифрованных) сообщенийага то есть мне нуно купить мобильник у которого батарейка сутки не держит (то есть фактически уходит в офлайн каждые 8 часов), купить обычный ПК который выключается раз в день, и сервер который выключается к примеру раз в год - так что ли ?
>>проблем с оффлайновыми соообщениями тоже нет.
есть и будет всегда, зададимся вопросом а нужна ли эта офлайновая доставка ? вы часто, когда не можете дозвониться до абонента, отправляете голосовое сообщение ?
http://matrix.org/
Ну так для каких то конф. переписок использовать tox, чем он плох?
https://news.ycombinator.com/item?id=13392128
https://github.com/TokTok/c-toxcore/issues/426
Ужасная атака, да. Если у тебя увели секретный ключ - это так или иначе тапки, я бы сказал. А дальше на копейку надо усилий или на две, чтобы тебя доломать - не принципиально.
В Tox нет
* офлайн сообщений
* мультидевайса
* Адаптированности для мобильных устройств
В IRC вроде же тоже нет офлайн сообщений...
В сетях с "сервисами" (ChanServ, etc) часто есть MemoServ. Ну и разумеется админы оного потенциально могут сообщения читать. Что стоит учитывать при его использовании.
для секретных заклинаний есть почта+крипто, а принцип что знают двое знает и свинья всегда актуален. не понимаю людей с шизофренией по теме преследования, тем более в групповом общении. это на клинику смахивает. а мобильные мессенджеры и создавались для слежки - это же очевидно
> для секретных заклинаний есть почта+крипто, а принцип что знают двое знает и
> свинья всегда актуален.Так это, если человек онлайн - можно otr допустим использовать. В принципе он до некоторой степени и оффлайн может сработать. Но с memoserv это будет несколько сложно реализовать.
> не понимаю людей с шизофренией по теме преследования,
Ну так опубликуй свои логины, пароли, паспортные данные и какие там еще мелочи жизни.
> тем более в групповом общении.
В ирц, внезапно, есть приваты. А еще по ирц иногда шарятся боты непонятной принадлежности.
> это на клинику смахивает. а мобильные мессенджеры и создавались для слежки
> - это же очевидноИ эти люди про клинику. Прикольно.
1) В P2P IM оффлайн сообщениями должны заниматься сами клиенты. Других _безопаных_ вариантов не видно.
2) Разрабатывают.
3) А в чём должна заключаться адаптированность Tox для мобильных устройств?
1) Это так и это проблема. Для меня, по крайней мере. Решение QTox не подходит. Остаётся только выделить эту функцию на сервера, как это сделано с их системой имён.
2) Да. Ждём. Как и полноценных конференций.
3) В низком потреблении трафика и расходе батареи. Опять же это возможно только если в сети будут присутствовать супер-ноды - сервера.Итого у нас может быть одноранговая сеть для базовой работы сети (DHT разрешающая id в ip) и сервера для всего остального. Насколько это лучше уже работающего, отлаженного и стандартизированного федеративного XMPP который умеет всё что умеют современные проприетарные централизованные мессенджеры?
> 3) В низком потреблении трафика и расходе батареи. Опять же это возможно
> только если в сети будут присутствовать супер-ноды - сервера.Тут на самом деле вопрос в том кому они принадлежат, насколько сложно это получается и проч.
> Итого у нас может быть одноранговая сеть для базовой работы сети (DHT
> разрешающая id в ip) и сервера для всего остального.А зачем сервера? Чуть заппгрейженые p2p узлы и могут стать "типа серверами". Да и id в ip - слишком примитивно, и никого ни от чего не защищает. Начиная от банальных нюков а-ля ирц "скажи мне свой айпишник!" до тотального шпионажа.
> Насколько это лучше уже работающего, отлаженного и стандартизированного
> федеративного XMPP который умеет всё что умеют современные проприетарные
> централизованные мессенджеры?Придуркативный этот ваш XMPP, в нем даже банальная передача файлов сроду не работает, квитков о доставке в половине случаев нет, а уж voip какой - там теоретически так можно но у меня это вообще ни разу не получилось. Эталонное designed by committee: кривое, сложное и работает как полный шит.
> 1) В P2P IM оффлайн сообщениями должны заниматься сами клиенты. Других _безопаных_
> вариантов не видно.
> 2) Разрабатывают.
> 3) А в чём должна заключаться адаптированность Tox для мобильных устройств?
>2) Да. Ждём. Как и полноценных конференций.который год ждём.......... жаббер2, блин
и, буквально, в тот же день на ленте " 06:28, 13 января 2017
Чеченские силовики нашли боевиков перед спецоперацией через WhatsApp"
Никогда не воспринимал попсовые закрытые интернет мессенджеры иначе чем более дешевые аналоги стационарной или gsm телефонии для белых и пушистых поздравлений бабушки с новым годом, например. Зачем вы это делаете?
Внутри всех этих мессенджеров нормальный криптографический протокол https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
Проблема в пользователях, не уделяющий внимания аутентификации контактов и кривых клиентах.
"Никогда такого не было..." (ц)
А что скажете насчет Ostel с клиентом Jitsi?
Правда, чат там идет нормально, а говорить по нему не получается, звук идет с задержкой и жуткими искажениями.
Т.е. сообщение прийдёт собеседнику даже в случае перехвата и оффлайна? Это же наоборот годнота =)
Кто бы сомневался. Все проприетарные мессангеры - ненужно
Если ключи генеряются на сервере, а не на клиенте, то о какой безопасности вобще можно говорить?! Это же голимый лохотрон!
Исходники опенсорса тоже генерятся на стороне кем-то не тобой...
Ты щас это к чему сморозил?
Разницу между приватными ключами и публичными исходниками не чуешь?
То что безопасности нету - ты не понял
> То что безопасности нету - ты не понялЕсли ты не чуешь разницу между приватными ключами и публичными исходниками, то как ты можешь вобще рассуждать о безопасности? У тебя картошка в голове, гнилая и не мытая )
На клиенте, разумеется. Проблема в том, что в этом клиенте по умолчанию вы доверяете новым ключам ранее доверенного контакта.
> На клиенте, разумеется. Проблема в том, что в этом клиенте по умолчанию
> вы доверяете новым ключам ранее доверенного контакта.А кто генеряет "новые ключи ранее доверенного контакта", если этот "контакт" даже не в курсе, что ему перегенеряли ключи?
Ты новость-то читал? )
>Ты новость-то читал? )Ты протокол не читал.
В этом протоколе у контакта может быть множество ключей-устройств. Первый раз при добавлении контакта клиентом производится аутентификация (не знаю как в ватсапе, по-нормальному это делается сверяя отпечатки ключей через сторонний доверенный канал) и устанавливается доверие ключу контакта. Открытые части ключей хранятся на сервере под идентификатором контакта. Соответственно, злоумышленник (фсб в сговоре с сервером) может добавить на сервер свой ключ привязав его к идентификатору контакта. Далее наш клиент получает с сервера новый ключ контакта и в зависимости от клиента:
* Нормальный клиент: не доверяет новому ключу, шифрует сообщения только ключами, которым доверяет "хозяин"
* Ватсап: автоматически устанавливает доверие новому ключу, не требуя проведения хозяином аутентификации нового ключа и ничего не говоря, отправляет сообщение зашифрованное всеми ключами (в т.ч. новым, который генерировало фсб).В протоколе уязвимости нет, проблема в клиенте и хомаках, которым плевать на аутентификацию.
Если вдруг кто-то ищет im-систему, которая имеет:
- свободные клиенты для современных мобил и современных (важно!) десктопов,
- свободную серверную часть,
- федерацию децентрализованных серверов,
- возможность включения e2e-шифрования (пока экспериментального),
- синхронизацию сообщений между всеми клиентами одного пользователя,
- работоспособные современные фичи вроде аудио- и видеозвонков, предпросмотра ссылок, картинок, удаления своих ошибочных сообщений, отправки сообщений офлайн-контактам (т.е. не такая древняя как irc и не такая несостыкованная как jabber),
- возможность гейтования с некоторыми ирк-сетями, слаком
и много чего ещё, то заглядывайте к нам на огонёк
https://riot.im/app/#/room/#ru.matrix:matrix.org -- расскажем и покажем что к чему.
пыль в глаза эта ваша end-to-end криптография
им важней доставка сообщения нежели безопасная доставка.
Они это так и прокомментировали:
https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/Если они внезапно перестанут доставлять сообщения, когда вы поменяли телефон или переустановили клиент - большинство людей просто не поймут почему они не могут отправить сообщение.
Параноикам достаточно сверять ключи и следить за статусом доставки сообщений.
>> большинство людей просто не поймут почему они не могут отправить сообщение.думаете большинство людей понимают когда внезапно в окне чата написано - "Поздравляем вы перешли теперь на end-to-end шифрования, ваша переписка "после этого" надёжно защищена".
Если они не понимают, то им это не нужно.
Об этом и речь, что было бы неправильно заблокировать сообщение с котиками девачке, которое это end-to-end нафиг не сдалось - убегут в Viber.
Для параноиков есть тот же signal.
Честна-честна, клянуся щито нету тама бикдорав, чесна!!11 Рубаху рву!1
Ну что, как говорится, кто бы сомневался.
"Уж сколько раз твердили миру" (басня И.А. Крылова "Ворона и лисица")
Как только Вы вывешиваете свои "трусы" в инете, не зависимо с шифрованием или без, эти "труселя" видят ВСЕ !!! И как говорил осёл Иа "Удивляться не приходится" :)
> В популярной системе обмена сообщениями WhatsApp выявлена
>-or-backdoor/)
> уязвимость, которая позволяет
> владельцу сервиса (Facebook) и другим заинтересованным спецслужбам перехватывать и прочитывать
> зашифрованные сообщения.
> сменить сгенерировать новые ключи для пользователей,
> без ведома отправителя и получателя сообщений.
> Уязвимость рассматривается некоторыми исследователями безопасности как преднамеренный
> бэкдор.
> Сокрытие проблемы и игнорирование выпуска исправления может стать серьёзным ударом по имиджу
> WhatsApp, учитывая то, что ранее Facebook заверял пользователей, что применяемое в
> WhatsApp end-to-end-шифрование исключает любые возможности перехвата сообщений, в том
> числе персоналом WhatsApp. Тем не менее аудит реализации протокола показал, что
> на деле компания Facebook имеет возможность чтения чужих сообщений, осуществив замену
> ключа..
> Примечательно, что оригинальная реализация протокола Signal вместо автоматической
> переотправки с новым ключом, блокирует доставку подобных сообщений и отправляет уведомление
> отправителю.2016-12-28 Michael "Phoronix" Larabel "FreeBSD Foundation Receives Another $500,000 USD Gift" --http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-U...
500K от благодарного гендира WhatsApp-а + 500К от не пожелавшего назваться "бенифициара".
"" Jan says, “While WhatsApp today is used by over a billion people, it is FreeBSD that provides the reliability and performance and helps our engineers keep WhatsApp service running efficiently and trouble-free.” "" --https://www.freebsdfoundation.org/blog/foundation-announces-.../