Ммм. Насколько я знаю, пока этим не занимаются (могу быть неправ). Да и это будет означать пересборку репозиториев (аналогично миграции с svn на git) и перезагрузку их у всех причастных (ну или локальную пересборку), плюс сломанные подписи коммитов. Плюс куча софта, работающего с git, будет вынуждена внести серьёзные изменения и обновиться, чтобы поддерживать новый хеш.
Нет, судя по контексту, имелось ввиду, что git адресует все попавшие в него объекты (включая коммиты) по sha-1 хэшу.
Поэтому чтобы подделать содержимое или историю так, чтобы куча форкнувших людей этого не заметила — нужно сломать sha-1, подменив код какого-то объекта с сохранением хэша.
Ну, для md5 пару создать заранее давно можно, дело не в случайном треше и не в паролях.
Смотрите: http://www.mscs.dal.ca/~selinger/md5collision/ — этому примеру десять лет, и это пример именно для работоспособной программы, где два бинарника дают один и тот же хеш и делают разные вещи. С исходниками такое тоже возможно сделать, поломав какое-нибудь условие, например.
Вот со sha1 когда-нибудь случится как минимум то же самое, и это когда-нибудь может оказаться уже весьма скоро.
Поэтому надо срочно что-то решать и менять адресацию блобов по sha1 пока не поздно.
Если бы было возможно — то проблема бы не назревала, а уже бы вовсю давала последствия.
До того, как будет возможно, по некоторым прикидкам осталось всего несколько лет (где несколько — это 3 для крупных участников или 5 для какого-нибудь университета). Про md5 тоже когда-то так говорили.
Кстати, чтобы подложить закладку — достаточно внести какую-нибудь незаметную ошибку в какую-нибудь проверку, этого вполне может оказаться достаточно.
А в том, что вы не летаете, вы Ньютона не обвиняете? =)
Это так не работает, не важно, какая теория выглядит более привлекательной внешне, важно, какая лучше описывает реальное положение дел и обладает лучшей предсказательной способностью.
Протокол Диффи-Хеллмана — далеко не единственный способ, поэтому я конкретно пальцем и не тыкал =). Но как пример — да.
Вот вам другой пример: генерируем два приватных ключа, по одному на пользователя, посылаем друг другу публичные, общая картинка — визуализация конкатенации отпечатков этих двух ключей в алфавитном порядке.
Дальше генерируем сессийные приватные ключи, посылаем друг другу публичные, подписанные приватными ключами пользователей.
Общаемся, шифруя трафик сессийными ключами друг друга. В конце разговора (или по таймауту) выкидываем приватные части сессийных ключей, если нужно продолжить — создаём новые.
Даже если приватный ключ пользователя утечёт — расшифровать трафик будет нельзя, так как приватного сессийного ключа в принципе уже нигде не будет.
В такой схеме это только 1:1 разговоры, конечно, но для конференций тоже варианты есть.
Синхронизация предполагает либо p2p между своими устройствами, либо хранение данных на промежуточном сервере. Первое пользователю неудобно: пока один из девайсов выключен, на него/с него ничего не придёт.
Я не вижу в этом особой проблемы, если честно. И не пока один из девайсов выключен, а пока все девайсы пользователя выключены, ему ничего не придёт. Как только один включится — на него придёт очередь доставки от всех собеседников, у которых включен хоть один девайс. Как только включится другой — на него синкнется история с первого девайса.
Историю можно удалить в любой момент, причём как вместе с аккаунтом, так и потерев частное сообщение (но оно удалится только с одной стороны — у вас).
Нет, я не про то. Я про то, что у них приватные только те чаты, которые не сохраняют и не синхронизируют логи.
Попробуйте продвигать в массы мессенджер без синхронизации между устройствами
Синхронизация между устройствами нужна и приватность её не отменяет. Теоретических проблем там нету.
Современному человеку достаточно ощущения приватности, когда «что-то там шифруется и вроде как защищено».
Шильдик «ошень безопасно»?
Включить секретные чаты по-умолчанию равносильно потерять большую часть немногочисленных пользователей, которые сразу же убегут, как только не увидят историю своих прошлых чатов с другого устройства.
То, что они связали в одно удаление истории и шифрование — проблема исключительно телеграма, а не этой вселенной.
This. Но не в интерфейсе.
Сохранять их в очереди на стороне того, кто послал, отправлять по появлению обоих в сети одновременно.
Всё равно на мобильниках все почти всегда в онлайне, так что это не принесёт столько проблем, сколько хранение их в глобальном пуле.
При этом если у пользователя несколько устройств — синкать очередь отправки между ними, то есть если дома стоит постоянно включенный PC — очередь на доставку будет всегда онлайн (как и сообщения, приходящие пользователю), даже если мобильный мигает.
Да и пользователь всегда сможет лично создать себе постоянно включенную ноду, если очень захочет.
Да, в таком решении есть минусы, но мне кажется, что их здесь меньше, чем в остальных.
Покажите мне MitM, пожалуйста, при зашифрованном соединении. С учётом того, что домен таки верен и что браузер поддерживается и не окаменел ещё.
Хотя нет — это возможно при выпуске левого сертификата, конечно, и это проблема системы TLS, она фундаментально сломана в это месте. С заменой её на что-то лучшее пока всё сложно, это да.
Но сейчас речь идёт про банковских клиентов, и это немного не тот уровень пока что. Так что всё равно покажите реальную историю, или метод, который не предполагает злонамеренного центра сертификации.
Отлично! Это вам дало только то, что теперь ваши разговоры может ещё и оператор вашего VPS прочитать, писать от вас, или ключ куда-нибудь вытащить. Да и вообще что угодно делать.
Ну и плюс вы же VNC по зашифрованному каналу гоните, да? Если нет — то тогда все, кто между VPS и вами могут читать, и, возможно, писать.
Смешались вместе люди кони… Мы про разработку чего-то связанного с безопасностью?
Нет, мы про то, насколько пользователям чего-то надо в это что-то вникать. Что значит «связанный с безопасностью»? Это массовый продукт, он должен быть безопасен для всех и явно давать пользователям понять, что надо делать, для того, чтобы не оказаться в плохой ситуации. У меня ядро операционки связано с безопасностью и браузер связан с безопасностью — там шифрование используется.
MitM
Но полоска же зелёная!
Покажите мне MitM, пожалуйста, при зашифрованном соединении. С учётом того, что домен таки верен и что браузер поддерживается и не окаменел ещё.
Tox что-то пилит, например, у них что-то получается, но рекомендовать пока не могу — последний раз, как смотрел, было сырое плюс несколько неверных моментов. Но это давно было, надо посмотреть повнимательнее.
Ну и посмотрите как cjdns работает, хотя оно и не мессенджер.
По тому же, по другому — только в случае заведомой компрометации.
И что значит — предлагаю? Это работает много где, старые сеансовые ключи далеко не всегда восстанавливаются при получении основного ключа постфактум и при доступе к полной записи логов.
Допустим мы сделали end-to-end encryption, но никто не мешает перехватывать весь ваш трафик на уровне провайдера и расшифровать когда станут доступны ключи. Значит ли это что ключи нужны всегда новые и нужно их уничтожать на обоих концах соединения?
Это решаемая проблема — да, по уже установленному безопасному каналу ключи можно обновлять даже в автоматическом режиме, уничтожая старые. При краже ключей всё равно начнутся очень большие неприятности, конечно, но старый трафик не будет расшифрован.
Пусть всегда будет 2FA
К чёрту 2FA и вообще сервер-сайт аутентификацию. Можно построить p2p сеть, где аутентификация в таком виде вообще не нужна, а подключение с другого устройства будет происходить только передачей ключа с имеющегося. При этом, если устройств больше двух, можно даже продумать схему, которая позволит выйти из ситуации кражи одного из них с минимальными возможными потерями, при реакции пользователя на это (хотя, если логи мы храним — их укравшие телефон в разблокированном состоянии получат).
Логи хранить в зашифрованном виде на ваших устройствах и на устройствах собеседников, подписанные вами обоими. Тогда при входе в сеть с телефона, который был выключен — логи подгрузятся с вашего другого устройства или с устройств ваших собеседников.
При этом явно отмечать контакты как не подтверждённые/подтверждённые/скомпрометированные.
Это всё реализуемо.
Ваш телефон могут банально украсть, обойти PIN защиту блокировщика экрана, подделать отпечатки пальца и т.д. Вытащить ключи и расшифровать всю переписку. Даже могут «попросить» вас это сделать. Как защититься от взлома аппарата и владельца? Делать специальный код стирающий все и везде?
См. выше про кражу телефона. Переписку в таком случае злоумышленники получат — можно тупо стукнуть пользователя по голове, пока они читают сообщения — от этого даже теоретически нельзя сейчас защититься. Можно этому пытаться воспрепятствовать через блокировку и шифрование фс — но, опять же, это можно обойти, так что будем защищаться только о того, от чего можно защититься.
Не фричество, а историческая теория (сто лет назад почти предполагали же), но да, не имеющая отошения к действительности.
Я в курсе, но по контексту не понял, в курсе ли вы. Вы меня успокоили немного =).
Верно.
Спорно, тут ещё вопрос в том, что со временем делать — оно неоднородно же. Было бы однородно — было бы эквивалентно, а в реальной картине — не факт.
Это вы об «утомлённом свете» сейчас, да?
Хотя у сохранения энергии и есть оговорки некоторые, но это — не из той оперы, кмк.
Ммм. Насколько я знаю, пока этим не занимаются (могу быть неправ). Да и это будет означать пересборку репозиториев (аналогично миграции с svn на git) и перезагрузку их у всех причастных (ну или локальную пересборку), плюс сломанные подписи коммитов. Плюс куча софта, работающего с git, будет вынуждена внести серьёзные изменения и обновиться, чтобы поддерживать новый хеш.
Нет, судя по контексту, имелось ввиду, что git адресует все попавшие в него объекты (включая коммиты) по sha-1 хэшу.
Поэтому чтобы подделать содержимое или историю так, чтобы куча форкнувших людей этого не заметила — нужно сломать sha-1, подменив код какого-то объекта с сохранением хэша.
Ну, для md5 пару создать заранее давно можно, дело не в случайном треше и не в паролях.
Смотрите: http://www.mscs.dal.ca/~selinger/md5collision/ — этому примеру десять лет, и это пример именно для работоспособной программы, где два бинарника дают один и тот же хеш и делают разные вещи. С исходниками такое тоже возможно сделать, поломав какое-нибудь условие, например.
Вот со sha1 когда-нибудь случится как минимум то же самое, и это когда-нибудь может оказаться уже весьма скоро.
Поэтому надо срочно что-то решать и менять адресацию блобов по sha1 пока не поздно.
Если бы было возможно — то проблема бы не назревала, а уже бы вовсю давала последствия.
До того, как будет возможно, по некоторым прикидкам осталось всего несколько лет (где несколько — это 3 для крупных участников или 5 для какого-нибудь университета). Про md5 тоже когда-то так говорили.
Кстати, чтобы подложить закладку — достаточно внести какую-нибудь незаметную ошибку в какую-нибудь проверку, этого вполне может оказаться достаточно.
Как раз вот относительно этого назревает маааленькая проблема =).
А в том, что вы не летаете, вы Ньютона не обвиняете? =)
Это так не работает, не важно, какая теория выглядит более привлекательной внешне, важно, какая лучше описывает реальное положение дел и обладает лучшей предсказательной способностью.
Знаете, вся эта дискуссия сподвигла меня таки собрать свои мысли по поводу в кучу, вот что получилось:
https://github.com/ChALkeR/whinings/blob/master/Instant-messaging.md.
Аккуратно, я там ною, плюс оно написано совсем недавно и поэтому сырое — я ещё буду расширять, править и вычитывать.
Я предупредил =).
Протокол Диффи-Хеллмана — далеко не единственный способ, поэтому я конкретно пальцем и не тыкал =). Но как пример — да.
Вот вам другой пример: генерируем два приватных ключа, по одному на пользователя, посылаем друг другу публичные, общая картинка — визуализация конкатенации отпечатков этих двух ключей в алфавитном порядке.
Дальше генерируем сессийные приватные ключи, посылаем друг другу публичные, подписанные приватными ключами пользователей.
Общаемся, шифруя трафик сессийными ключами друг друга. В конце разговора (или по таймауту) выкидываем приватные части сессийных ключей, если нужно продолжить — создаём новые.
Даже если приватный ключ пользователя утечёт — расшифровать трафик будет нельзя, так как приватного сессийного ключа в принципе уже нигде не будет.
В такой схеме это только 1:1 разговоры, конечно, но для конференций тоже варианты есть.
Либо «легче» либо «без», наверное.
См. https://habrahabr.ru/company/eset/blog/308640/#comment_9776062
Я не вижу в этом особой проблемы, если честно. И не пока один из девайсов выключен, а пока все девайсы пользователя выключены, ему ничего не придёт. Как только один включится — на него придёт очередь доставки от всех собеседников, у которых включен хоть один девайс. Как только включится другой — на него синкнется история с первого девайса.
Нет, я не про то. Я про то, что у них приватные только те чаты, которые не сохраняют и не синхронизируют логи.
Синхронизация между устройствами нужна и приватность её не отменяет. Теоретических проблем там нету.
Шильдик «ошень безопасно»?
То, что они связали в одно удаление истории и шифрование — проблема исключительно телеграма, а не этой вселенной.
This. Но не в интерфейсе.
Сохранять их в очереди на стороне того, кто послал, отправлять по появлению обоих в сети одновременно.
Всё равно на мобильниках все почти всегда в онлайне, так что это не принесёт столько проблем, сколько хранение их в глобальном пуле.
При этом если у пользователя несколько устройств — синкать очередь отправки между ними, то есть если дома стоит постоянно включенный PC — очередь на доставку будет всегда онлайн (как и сообщения, приходящие пользователю), даже если мобильный мигает.
Да и пользователь всегда сможет лично создать себе постоянно включенную ноду, если очень захочет.
Да, в таком решении есть минусы, но мне кажется, что их здесь меньше, чем в остальных.
Хотя нет — это возможно при выпуске левого сертификата, конечно, и это проблема системы TLS, она фундаментально сломана в это месте. С заменой её на что-то лучшее пока всё сложно, это да.
Но сейчас речь идёт про банковских клиентов, и это немного не тот уровень пока что. Так что всё равно покажите реальную историю, или метод, который не предполагает злонамеренного центра сертификации.
Отлично! Это вам дало только то, что теперь ваши разговоры может ещё и оператор вашего VPS прочитать, писать от вас, или ключ куда-нибудь вытащить. Да и вообще что угодно делать.
Ну и плюс вы же VNC по зашифрованному каналу гоните, да? Если нет — то тогда все, кто между VPS и вами могут читать, и, возможно, писать.
Нет, мы про то, насколько пользователям чего-то надо в это что-то вникать. Что значит «связанный с безопасностью»? Это массовый продукт, он должен быть безопасен для всех и явно давать пользователям понять, что надо делать, для того, чтобы не оказаться в плохой ситуации. У меня ядро операционки связано с безопасностью и браузер связан с безопасностью — там шифрование используется.
Покажите мне MitM, пожалуйста, при зашифрованном соединении. С учётом того, что домен таки верен и что браузер поддерживается и не окаменел ещё.
Tox что-то пилит, например, у них что-то получается, но рекомендовать пока не могу — последний раз, как смотрел, было сырое плюс несколько неверных моментов. Но это давно было, надо посмотреть повнимательнее.
Ну и посмотрите как cjdns работает, хотя оно и не мессенджер.
По тому же, по другому — только в случае заведомой компрометации.
И что значит — предлагаю? Это работает много где, старые сеансовые ключи далеко не всегда восстанавливаются при получении основного ключа постфактум и при доступе к полной записи логов.
О, хорошие, годные вопросы.
Это решаемая проблема — да, по уже установленному безопасному каналу ключи можно обновлять даже в автоматическом режиме, уничтожая старые. При краже ключей всё равно начнутся очень большие неприятности, конечно, но старый трафик не будет расшифрован.
К чёрту 2FA и вообще сервер-сайт аутентификацию. Можно построить p2p сеть, где аутентификация в таком виде вообще не нужна, а подключение с другого устройства будет происходить только передачей ключа с имеющегося. При этом, если устройств больше двух, можно даже продумать схему, которая позволит выйти из ситуации кражи одного из них с минимальными возможными потерями, при реакции пользователя на это (хотя, если логи мы храним — их укравшие телефон в разблокированном состоянии получат).
Логи хранить в зашифрованном виде на ваших устройствах и на устройствах собеседников, подписанные вами обоими. Тогда при входе в сеть с телефона, который был выключен — логи подгрузятся с вашего другого устройства или с устройств ваших собеседников.
При этом явно отмечать контакты как не подтверждённые/подтверждённые/скомпрометированные.
Это всё реализуемо.
См. выше про кражу телефона. Переписку в таком случае злоумышленники получат — можно тупо стукнуть пользователя по голове, пока они читают сообщения — от этого даже теоретически нельзя сейчас защититься. Можно этому пытаться воспрепятствовать через блокировку и шифрование фс — но, опять же, это можно обойти, так что будем защищаться только о того, от чего можно защититься.