ZRTP в Jitsi а может и не только в нём
Вопрос по ZRTP в частности реализации в Jitsi – в настройках есть 2 пункта "Доверенный MitM" и обработка SAS подписи, за что они отвечают?
impl.media.security.zrtp.TRUSTED=Доверенный MitM
impl.media.security.zrtp.SASSIGNATURE=обработка SAS подписи
MitM как я подозреваю "man in the middle" но для чего это в jitsi не представляю.
Чтобы при перекидывании файлов расшифровывать их и проверять антивирусом?
Каких файлов? Это же не пиринговая сеть.
Ну вдруг там есть функционал отсылки файлов от одного абонента другому подобно тому, как это сделано в Skype.
наткнулся тут на вот это:
кто нибудь пользовался сабжем как voip-клиентом?
какие впечатления?
Опять юзерофилия в ущерб безопасности. При сверке PGP-ключей надо сверять весь отпечаток, а не только keyid — ведь не зря же об этом твердят. А тут — так вообще...
если опустить данный факт, а посмотреть на voip шифрование и на саму работу сабжа. удобство, функциональность и т.д.
Зачем смотреть на VoIP-шифрование, если есть подозрение, что его можно отMITMить?
насколько я понимаю, MiTM избежать никому не удастся, если противник задастся целью (врезаться в канал разве трудно?). НО что он (противник) получит в результате? для контроля шифрованного канала нужно маркитанить с сертификатами, а в случае с шифрованием сообщений pgp (gpg), так вообще смысл MiTMить (ну кроме инфы о получателе и ключах)?
вот что выдает Википедия:
получается очень ненадежно ((
Абсолютно неверно. Затем сверка отпечатков ключей и делается, чтобы не было MITM. В частности, сверка отпечатков — штатная процедура для ssh, PGP и OTR.
Если на первом этапе сделать имперсонацию, т.е. подсунуть одному из собеседников ключ атакующего, то стороны не смогут ничего заподозрить, если только не будут сверять ключи друг друга. Атакующий же, произведя атаку, может невозбранно прослушивать канал и даже вставлять в него свои собственные сообщения — сплошной PROFIT.
Вы всё-таки почитайте о том, как делается MITM, там не очень сложно.
а размещение ключа на keyserver может защитить от подмены?
можно и наверно разместить ключ под пароль на обменник в непубличном режиме. как такой вариант? на rghost хэш автоматом вывешивается и можно верифицировать самому владельцу. пароль отправить по СМС ))
Нет.
Никак, бесполезно.
Матчасть:
/Библиотека/Основы/ВведениеВКрипто/Глава1/ЦифровыеСертификаты[link1]
/Библиотека/Основы/СетьДоверия[link2]
там нет как безопасно передать открытый ключ.
На самом деле есть. Варианта принципиально всего два: лично или через доверенного посредника(удостоверяющий центр или сеть доверия).
Или передать ключ по недоверенному каналу и сверить отпечаток по тем или иным образом аутентифицированному (распространённый вариант — по телефону, если известен голос собеседника).
а вот ответ из Матчасти:
что подтвердил SATtva
хэш MD5 (например) можно подделать? разве это не уникальный идентификатор?
да вот и зачем в gpg отправка ключа в keyserver?
Да, поэтому ключи PGP в формате v3 (которые генерировались в PGP 2.6 и использовали для выработки отпечатка MD5) являются небезопасными. В v4 в качестве отпечатка используется SHA-1, который в данном контексте пока можно считать приемлемо надёжным.
Для удобства. Читайте ссылки[link3] до просветления.
Если убрать из вопроса MD5, то отпечаток ключа, собственно, уже есть хэш ключа. Его и сверяют по аутентифицированному каналу.
был приведен для примера. да хоть sha-1.
изначально ставился вопрос так, "а что если вывесить открытый ключ на файлообменнике, где хешируется файл, под паролем конечно и не в публичном виде". так понял, что и в этом случае небезопасно. видимо можно также произвести подмену... правда ссылку на файл и пароль можно переслать например СМС.. но профи виднее. остается только из рук в руки или сверять ID (хэш) по телефону.
правда читал на сайте про хитрую схему передачи ключей, но не вспомнить где ((
Хэшируется кем, чем? Файлообменником? Тогда сам файлообменник и способен произвести подмену, такая схема небезопасна. Если файлообменник, или сервер ключей, или личный вебсайт используется только для обмена материалом ключа, а его аутентификация производится по независимому надёжному каналу, то эта схема является безопасной в той мере, в которой надёжен используемый для аутентификации канал (считать таковым SMS я бы точно не стал).
да. я понял, речь идет о потенциальной возможности подмены. 100% гарантии даже личная передача не дает, а вдруг пластическая операция (шутка). в любом случае, канал определять самому, исходя из собственных обстоятельств.
Да, как-то так. В предположении, что противник может менять/резать ваши реплики на лету даже тот факт, что вы договорились переслать ключ по n независимым каналам не спасёт. Вы же пишете собеседнику, но не знаете достоверно, какие из ваших сообщений до него вообще доходят, и из тех, которые доходят, какие доходят неискажённо. Считается, что подделывать телефонный разговор в реальном времени намного сложнее, хотя кто его знает, до чего уже прогресс дошёл.
Ранее не обращал внимания на этот софт, довольно интересно. Родилась пара вопросов:
1. В Jitsi предлагается шифрование любого SIP аккаунта или это учетка именно Jitsi?
2. Насколько можно шифрование Jitsi считать надежным?