https://www.opennet.me/openforum/vsluhforumID3/110161.html В популярной системе обмена сообщениями WhatsApp выявлена (https://tobi.rocks/2017/01/whatsapp-vulnerability-bug-or-backdoor/) уязвимость, которая позволяет (https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages) владельцу сервиса (Facebook) и другим заинтересованным спецслужбам перехватывать и прочитывать зашифрованные сообщения. Проблема вызвана тем тем, что сервис WhatsApp может принудительно сменить сгенерировать новые ключи для пользователей, которые в данным момент находятся вне сети (offline), без ведома отправителя и получателя сообщений.<br><br><br><br>Уязвимость рассматривается некоторыми исследователями безопасности как преднамеренный бэкдор - Facebook был уведомлен о проблеме ещё в апреле прошлого года, но уязвимость до сих пор остаётся не исправлена.<br>Сокрытие проблемы и игнорирование выпуска исправления может стать серьёзным ударом по имиджу WhatsApp, учитывая то, что ранее Facebook заверял пользователей, что применяемое в WhatsApp end-to-end-шифрован https://www.opennet.me/openforum/vsluhforumID3/110161.html#87 Sat, 21 Jan 2017 08:28:44 GMT &gt; В популярной системе обмена сообщениями WhatsApp выявлена<br>&gt;-or-backdoor/) <br>&gt; уязвимость, которая позволяет<br>&gt; владельцу сервиса (Facebook) и другим заинтересованным спецслужбам перехватывать и прочитывать <br>&gt; зашифрованные сообщения.<br>&gt; сменить сгенерировать новые ключи для пользователей, <br>&gt; без ведома отправителя и получателя сообщений.<br>&gt; Уязвимость рассматривается некоторыми исследователями безопасности как преднамеренный <br>&gt; бэкдор<br><br>.<br>&gt; Сокрытие проблемы и игнорирование выпуска исправления может стать серьёзным ударом по имиджу <br>&gt; WhatsApp, учитывая то, что ранее Facebook заверял пользователей, что применяемое в <br>&gt; WhatsApp end-to-end-шифрование исключает любые возможности перехвата сообщений, в том <br>&gt; числе персоналом WhatsApp. Тем не менее аудит реализации протокола показал, что <br>&gt; на деле компания Facebook имеет возможность чтения чужих сообщений, осуществив замену <br>&gt; ключа.<br><br>.<br>&gt; Примечательно, что оригинальная реализация протокола Signal вместо автоматической <br>&gt; переотправки с новым клю https://www.opennet.me/openforum/vsluhforumID3/110161.html#86 Thu, 19 Jan 2017 07:30:26 GMT Честна-честна, клянуся щито нету тама бикдорав, чесна!!11 Рубаху рву!1<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#85 Tue, 17 Jan 2017 13:11:34 GMT Если они не понимают, то им это не нужно.<br>Об этом и речь, что было бы неправильно заблокировать сообщение с котиками девачке, которое это end-to-end нафиг не сдалось - убегут в Viber.<br>Для параноиков есть тот же signal.<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#84 Mon, 16 Jan 2017 20:45:07 GMT Он имеет право диктовать практически что угодно в рамках своей инфраструктуры, если это не противоречит его локальному законодательству. А ребята из LibreSignal рискуют получить повестки в суд.<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#83 Mon, 16 Jan 2017 20:08:53 GMT Уведомлять отправителя о смене ключа получателя и запрашивать отправителя о необходимости повторной отправки сообщений, и только после явного подтверждения перешифровывать новым ключом и отправлять.<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#81 Mon, 16 Jan 2017 15:17:28 GMT &gt; 1) В P2P IM оффлайн сообщениями должны заниматься сами клиенты. Других _безопаных_ <br>&gt; вариантов не видно.<br>&gt; 2) Разрабатывают.<br>&gt; 3) А в чём должна заключаться адаптированность Tox для мобильных устройств?<br>&gt;2) Да. Ждём. Как и полноценных конференций.<br><br>который год ждём.......... жаббер2, блин<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#80 Mon, 16 Jan 2017 14:38:51 GMT &gt;Ты новость-то читал? )<br><br>Ты протокол не читал.<br><br>В этом протоколе у контакта может быть множество ключей-устройств. Первый раз при добавлении контакта клиентом производится аутентификация (не знаю как в ватсапе, по-нормальному это делается сверяя отпечатки ключей через сторонний доверенный канал) и устанавливается доверие ключу контакта. Открытые части ключей хранятся на сервере под идентификатором контакта. Соответственно, злоумышленник (фсб в сговоре с сервером) может добавить на сервер свой ключ привязав его к идентификатору контакта. Далее наш клиент получает с сервера новый ключ контакта и в зависимости от клиента:<br>* Нормальный клиент: не доверяет новому ключу, шифрует сообщения только ключами, которым доверяет "хозяин"<br>* Ватсап: автоматически устанавливает доверие новому ключу, не требуя проведения хозяином аутентификации нового ключа и ничего не говоря, отправляет сообщение зашифрованное всеми ключами (в т.ч. новым, который генерировало фсб).<br><br>В протоколе уязвимости нет, проблема в клиенте и хома https://www.opennet.me/openforum/vsluhforumID3/110161.html#79 Mon, 16 Jan 2017 06:43:49 GMT &gt; На клиенте, разумеется. Проблема в том, что в этом клиенте по умолчанию <br>&gt; вы доверяете новым ключам ранее доверенного контакта.<br><br>А кто генеряет "новые ключи ранее доверенного контакта", если этот "контакт" даже не в курсе, что ему перегенеряли ключи?<br><br>Ты новость-то читал? )<br> https://www.opennet.me/openforum/vsluhforumID3/110161.html#78 Mon, 16 Jan 2017 06:34:31 GMT если уйти от версии бэкдора, то как по другому организовать доставку offline сообщения при условии, что собеседник может быть offline потому-что он утопил телефон, а с новым у него будет новый ключ?<br>