На фоне борьбы мессанджеров, особенно когда WhatsApp так сильно скомпрометировал себя, очередной раз встал вопрос о безопасности общения и приватных данных. И конечно что же всех интересуют доказательство того, что нашу переписку невозможно прочесть.

Естественно все известные мессанджеры пытаются показать(или доказать) своим скептическим пользователям, что вся переписка надежно защищена. Обычно это мудреные описание современных механизмов шифрования, перегрузка технических терминов, а так же открытия исходных кодов(но не всегда).

Не преминул сделать это и телеграм. Павел Дуров уже опубликовывал свой критический пост и заявил что исходники клиентского приложения открыты. Да это действительно так, любой пользователь может найти исходники для сборки под Андроид или например для IOS. Да действительно можно найти места реализации секретных чатов с использованием всех современных стандартов криптографии.

Так же Павел совершенно верно прокомментировал вопрос о закрытых исходников для серверного приложения. :

Exactly, I’m also puzzled by folks who even mention server-side code in this context. Publishing the server code doesn’t guarantee privacy, because - unlike with the client-side code - there’s no way to verify that the same code is run on the servers.

Перевод:

Меня также озадачивают люди, которые упоминают серверный код в этом контексте(контексте о безопасности). Публикация серверного кода не гарантирует конфиденциальности, потому что, в отличие от клиентского кода, нет возможности проверить, выполняется ли тот же код на серверах.

Тут Павел абсолютно прав, когда какая то компания выкладывает свой серверный код и говорит что она полностью опенсорсная - это всего лишь маркетинг или пиар ход, поскольку никакой возможности у пользователей нет проверить, что именно этот код работает на серверах(не будут же разработчики давать доступ на сервера каждому встречному поперечному). Когда как проверка клиентского кода не составляет трудностей для специалиста.

Далее же Павел пишет

And you don’t even need the server-side code to check the integrity of Secret Chats - they are solid regardless of how the servers function (that’s the whole point). In other words, publishing server-side code won’t help verify Secret or Cloud Chats, and would constitute a marketing gimmick that has nothing to do with security.

Перевод:

И вам даже не нужен код на стороне сервера для проверки безопасности секретных чатов - они надежны независимо от того, как работают серверы (в этом весь смысл). Другими словами, публикация серверного кода не поможет проверить секретные или облачные чаты и будет представлять собой маркетинговый трюк, не имеющий ничего общего с безопасностью.

И вот тут уже с этим нельзя соглашаться. Поскольку протокол Диффи-Хелманна, тот самый которым пользуется телеграмм для обмена секретным ключом подвержена атаке Человек Посередине(Man In The Middle). Изначальна известно что протокол Диффи-Хелмана можно использоваться для обмена общим секретом по незащищенному каналу связи между двумя участниками, при этом все сообщения могут читаться третьей стороной, но ни в коем случае не изменяться.

Простыми словами это значит что безопасный зашифрованный канал можно установить только в том случает если Мэлори(см изображение) может читать сообщения между Бобом и Алисой, но не изменять.

Это значит при открытии секретного чата в приложении Телеграмм между двумя участниками происходит обмен ключами(так называемый handshake). При этом ключи идут по каналу телеграмма, т.е. через сервера телеграмма. И в этом случае та самая Мелори - является сервером телеграмма, который может ключи подменить, при этом оба участника не будут знать об этом.

Многие конечно могут ответить - в телеграмме же есть функция сравнения ключей. Оба собеседника могут проверить совпадают ли ключи. Да это действительно так, но к сожалению это не освобождает от факта что и сервер может обладать этим общим ключем. Ведь на этапе создания общего ключа по протоколу Диффи-Хеллмана участвовал сервер, который способен изменять сообщения. Таким образом можно выработать общий ключ, который известен не только участникам беседы но и серверу. А раз серверу доступен общий ключ - то он может читать сообщения.

Проблема доказательство владения публичным ключом - это старая и известная проблема, которая имеет решение - выдача сертификатов сертификационными центрами для доказательства владением публичным ключом. Это решение удачно применяется для реализации SSL(тот самый https который мы видим в строке браузера при посещении сайта использующего безопасное соединение). Да это решение годится когда есть один сервер и много клиентов. Сертификат выдается серверу и канал браузер - сервер защищен от атаки по середине.

В случае же с мессанджером это не возможно. Так как надо каждому пользователю выдать по сертификату, а это колоссальные нагрузки, при этом пользователь должен пройти формальную процедуру, предоставив стратификационному центру свои данные и доказав что он - это именно он.

Итог: как бы телеграмм себя не позиционировал безопасным мессенджером с невозможностью раскрыть данные - это не так. В текущей реализации клиентского приложения обмен ключами происходит через сервера телеграмма, поэтому у сервиса есть возможность провести атаку и начать читать переписку секретных чатов.

Решение: добавить возможность пользователям передавать ключи по любым другим каналам, но не через сервера мессенджера. Самый безопасный способ - это физический обмен ключами, например через считывание qr-кода. Да этот способ очень неудобен, поскольку требует, чтобы участники были непосредственно рядом, но он является самым безопасным. Другой способ - выгрузить ключи в файловую систему и передать их по другим каналам связи - соц сети, другой мессенджер, электронная/обычная почта, факс или продиктовать по телефону(что будет трудно выполнимо поскольку ключи имеют гигантские размеры). Этот способ менее безопасен, но тем не менее вероятность атаки очень мала.

И да, надо не забывать, что обязательно должны быть исходники всей реализации(если говорить о любой другой компании)

Получается чтобы любая компания могла доказать своим пользователям что она использует защищенный канал связи она должна предоставить:

• Исходники клиентского приложения

• Реализацию обмена ключами сторонники каналами.

При этом открывать серверный код ей не к чему абсолютно.