Здравствуйте, Pzz, Вы писали: Pzz>Передай картиночкой через телегу. Если твой провайдет умеет такое перехватывать, ну, он о-о-очень крут.
Не "мой провайдер", а ФСБшное оборудование, которое у него принудительно стоит. И ничего крутого в этом нету — в телеге шифруется вовсе даже не всё. Pzz>Но мне кажется, терморектальный криптоанализ практичнее, чем такой уровень техногогий.
Терморектальный криптоанализ требует близкого взаимодействия с криптоанализируемым. А технологии, интересные Мистерам Смитам, позволяют массово взбадривать электорат, не выходя из кабинета.
Вот когда чисто-цифровые методы позволят сузить круг подозреваемых, тогда-то и и настанет очередь терморекталки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Маск подо**рал все спецслужбы мира, включая свои
Здравствуйте, Sinclair, Вы писали:
I>>Расскажи про то как подменить уже опубликованный публичный ключ? )) S>"Уже опубликованный" == "переданный по небезопасному каналу". Если MITM сидит там с самого начала, то ему не составит труда подменить ключ в процессе "публикации".
Публичные ключи и цепочки сертификатов на доверенные центры распространяются в т.ч. с обновлениями операционок, где в т.ч. можно проверить публикуемые CRC пакетов обновлений, где эти публикации многократно где могут дублироваться.
В общем, MITM в теории прост, а на деле должен воссоздать чуть ли не альтернативный интернет атакуемым субъектам.
Re[6]: Маск подо**рал все спецслужбы мира, включая свои
Здравствуйте, vdimas, Вы писали:
v> Публичные ключи и цепочки сертификатов на доверенные центры распространяются в т.ч. с обновлениями операционок, где в т.ч. можно проверить публикуемые CRC пакетов обновлений, где эти публикации многократно где могут дублироваться.
v> В общем, MITM в теории прост, а на деле должен воссоздать чуть ли не альтернативный интернет атакуемым субъектам.
Чушь. Приходит тащ майор в доверенный центр сертификации, и очень доверительно предлагает посотрудничать. Отказаться центр не может, ибо есть обязывающий патриотический акт. Фсе.
Здравствуйте, rudzuk, Вы писали:
v>> В общем, MITM в теории прост, а на деле должен воссоздать чуть ли не альтернативный интернет атакуемым субъектам. R>Чушь. Приходит тащ майор в доверенный центр сертификации, и очень доверительно предлагает посотрудничать. Отказаться центр не может, ибо есть обязывающий патриотический акт. Фсе.
А как это коснётся независимых центров-эмитентов ключей, раскиданных по всему миру?
Re[7]: Маск подо**рал все спецслужбы мира, включая свои
Здравствуйте, rudzuk, Вы писали:
v>> В общем, MITM в теории прост, а на деле должен воссоздать чуть ли не альтернативный интернет атакуемым субъектам. R>Ну и чтобы два раза не вставать: https://www.opennet.ru/opennews/art.shtml?num=59965
Проблема, как видно из статьи, (а) в бесхозном Let’s Encrypt, что любой мог в автоматическом режиме получить сертификат на тот же хост, и (б) — в неполноценном использовании клиентами и сервером джаббера возможностей протокола TLS.
Например, в TLS сегодня стандартом де-факто стало использование расширения SNI, которое дополнительно защищает от подмены сертификата (хотя, изначально было введено из других соображений, см описание) — подменный сертификат должен быть выдан на тот же хост и, опционально (а эту опцию стоит задействовать, ес-но) проходить ту же цепочку валидации.
Как раз в своей конторе эти вопросы и всё вокруг этого на мне в плюсовых и дотнетных версиях, и как раз явное указание доверенных цепочек широко используется в финансовых транзакциях, бо никаким левым CA никто доверять не собирается, ес-но.
Итого, если использовать оба подхода, то MITM сможет работать только если один и тот же Certificate Authority будет выдавать разным аккаунтам сертификаты на один и тот же хост, что сразу превращает всю инфраструктуру открытых ключей в тыкву, т.е. рассуждения об этой инфраструктуре, как она описана в теории, перестают иметь к ней какое-либо отношение.
И да, есть очень простой способ защититься даже в случае использования бесхозных Let’s Encrypt и прочих — это создать дочерний приватный свой центр сертификации (многие конторы с большим кол-вом клиентов-подключений так делают), т.е. добавить +1 к цепочке валидации доверенных ключей, и чтобы приложухи клиента и сервера пользовали именно эту цепочку.
Если бы Jabber так поступил, он бы вынудил майора прийти уже прямо к ним и запросить уже у них такой же сертификат, т.е. выданный их же приватным CA.
И тут снова MITM теряет смысл — тогда уж можно майору дать прямой доступ к системе изнутри, т.е. можно тогда встроить MITM в сам джаббер-сервер, без возни с проксями-перехватчиками.
Здравствуйте, vdimas, Вы писали:
v> R>Чушь. Приходит тащ майор в доверенный центр сертификации, и очень доверительно предлагает посотрудничать. Отказаться центр не может, ибо есть обязывающий патриотический акт. Фсе.
v> А как это коснётся независимых центров-эмитентов ключей, раскиданных по всему миру?
Про не зависимость это сейчас смешно было. Ну нельзя же быть такими наивными, в наше то время... Борьба с терроризмом оправдает все что угодно.
V>Например, в TLS сегодня стандартом де-факто стало использование расширения SNI, которое дополнительно защищает от подмены сертификата (хотя, изначально было введено из других соображений, см описание) — подменный сертификат должен быть выдан на тот же хост и, опционально (а эту опцию стоит задействовать, ес-но) проходить ту же цепочку валидации. V>Как раз в своей конторе эти вопросы и всё вокруг этого на мне в плюсовых и дотнетных версиях, и как раз явное указание доверенных цепочек широко используется в финансовых транзакциях, бо никаким левым CA никто доверять не собирается, ес-но.
Через DNS-запись CAA, упоминаемую в статье? Ну так тут уже MITM атаке может быть подвержен DNS запрос.
V>Итого, если использовать оба подхода, то MITM сможет работать только если один и тот же Certificate Authority будет выдавать разным аккаунтам сертификаты на один и тот же хост, что сразу превращает всю инфраструктуру открытых ключей в тыкву, т.е. рассуждения об этой инфраструктуре, как она описана в теории, перестают иметь к ней какое-либо отношение.
От этого в некоторой степени защищает отслеживание логов Certificate Transparency. Об этом кстати в статье и написано.
V>И да, есть очень простой способ защититься даже в случае использования бесхозных Let’s Encrypt и прочих — это создать дочерний приватный свой центр сертификации (многие конторы с большим кол-вом клиентов-подключений так делают), т.е. добавить +1 к цепочке валидации доверенных ключей, и чтобы приложухи клиента и сервера пользовали именно эту цепочку. V>Если бы Jabber так поступил, он бы вынудил майора прийти уже прямо к ним и запросить уже у них такой же сертификат, т.е. выданный их же приватным CA.
Если клиентской и серверной частью управляет одна и та же организация, то сторонние CA конечно не нужны.
В общем случае это не так. С jabber.ru может работать любой third-party клиент (или сервере для S2S коммуникаций).
Re[9]: Маск подо**рал все спецслужбы мира, включая свои
Здравствуйте, m2user, Вы писали:
M>Если клиентской и серверной частью управляет одна и та же организация, то сторонние CA конечно не нужны. M>В общем случае это не так. С jabber.ru может работать любой third-party клиент (или сервере для S2S коммуникаций).
Дык, в этом и суть — идентификации всегда подвергается противоположная сторона.
Т.е. это в интересах клиента — удостовериться, что он подключается именно на jabber-сервис, а не к MITM.
Тогда, в случае приватного дочернего CA, клиенту для надёжной валидации истинности сервера необходимо использовать именно указанную цепочку валидации для сервера.
А если клиент валидирует сервер недостаточно тщательно, то такой клиент ССЗБ.
В TLS вообще есть возможность разрешить соединение, даже если валидация не прошла, если валидируется только сервер, как в случае браузинга или подключения к сервисам, навроде джаббера.
Т.е., выстрелить себе в ногу ни разу не запрещено. ))
Ну и, в финансовой области, зачастую клиентам тоже раздают сертификаты, которые серверной частью валидируются относительно приватных цепочек сертификатов (как минимум дочерних их СА).
В этом случае сервер дополнительно защищается от левых клиентов, т.е. сервер защищает от левых клиентов остальных участников торгов.
