Недавно на Geektimes подняли шум со статьей «Плохой Telegram» или Как я не взял денег за черный пиар Telegram на Хабрахабре. В итоге выяснили, что знакомый Бурумыча читает переписку дочери и что приветствие «Добрый день» лучше чем «Доброго времени суток».Дабы вбросить в вентилятор полезной информации, мы со специалистами компании Edison сделали подборку публикаций про Telegam и безопасные мессенджеры, чтобы пытливый читатель мог самостоятельно сделать вывод (а не получить «проплаченную» экспертизу) чему стоит доверять и чем пользоваться для своих целей. Про уровень доверия/желтизны СМИ предлагаю решить читателю самостоятельно.
Поток адекватной и неадекватной информации про безопасность коммуникации (и мессенджеров в том числе) растет и будет расти, и очень хочется, чтобы на Хабре можно было найти грамотную, независимую и понятную аналитику.
Какими критериями пользоваться для оценки безопасности мессенджеров, можно подсмотреть у борцов за цифровую неприкосновенность — Electronic Frontier Foundation (EFF). Кстати, вопрос, являются ли эти критерии исчерпывающими или нужны дополнительные (например, про маскировку метаданных)?
Чтобы повысить градус объективности и независимости, прошу высказаться в комментах тех, кто разбирается в вопросе по поводу безопасности мессенджеров.
На основе каких данных можно делать выводы?
«Информационная работа стратегической разведки» Вашингтон Плэтт
Electronic Frontier Foundation
www.eff.org/secure-messaging-scorecard
Организация Electronic Frontier Foundation (EFF) опубликовала серьезный аналитический материал (последнее обновление 2015-11-03), оценив степень безопасности и приватности мобильных и онлайн-мессенджеров. EFF присуждала участникам баллы, оценивая приложения по семи параметрам.
- Шифруются ли данные при передаче?
- Защищены ли данные от чтения сервис-провайдерами?
- Может ли пользователь удостовериться в подлинности личности своего собеседника?
- Защищена ли история переписки от расшифровки при перехвате текущего ключа (в этом вопросе подразумевается, что ключ шифрования должен постоянно меняться, а использованные ключи безопасно удаляться вместе с теми случайными данными, на основе которых они были построены)?
- Открыт ли программный код решения?
- Описаны ли детально используемые методы шифрования?
- Проводился ли за последние 12 месяцев независимый аудит безопасности?
Подробнее про критерии на английском
METHODOLOGY
Here are the criteria we looked at in assessing the security of various communication tools.
1. Is your communication encrypted in transit?
This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.
2. Is your communication encrypted with a key the provider doesn't have access to?
This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users' public keys are exchanged using a centralized server.
3. Can you independently verify your correspondent's identity?
This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:
An interface for users to view the fingerprint (hash) of their correspondent's public keys as well as their own, which users can verify manually or out-of-band.
A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire's protocol.
Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.
4. Are past communications secure if your keys are stolen?
This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties' long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.
Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.
5. Is the code open to independent review?
This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.
6. Is the crypto design well-documented?
This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:
Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process
How keys are generated, stored, and exchanged between users
The life-cycle of keys and the process for users to change or revoke their key
A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it's good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
7. Has there been an independent security audit?
This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool's main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.
[источник]
Here are the criteria we looked at in assessing the security of various communication tools.
1. Is your communication encrypted in transit?
This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.
2. Is your communication encrypted with a key the provider doesn't have access to?
This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users' public keys are exchanged using a centralized server.
3. Can you independently verify your correspondent's identity?
This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:
An interface for users to view the fingerprint (hash) of their correspondent's public keys as well as their own, which users can verify manually or out-of-band.
A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire's protocol.
Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.
4. Are past communications secure if your keys are stolen?
This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties' long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.
Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.
5. Is the code open to independent review?
This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.
6. Is the crypto design well-documented?
This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:
Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process
How keys are generated, stored, and exchanged between users
The life-cycle of keys and the process for users to change or revoke their key
A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it's good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
7. Has there been an independent security audit?
This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool's main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.
[источник]
Топ-лист самых защищенных мессенджеров по мнению EFF:
- Chatsecure — это бесплатное iOS- и Android-приложение для обмена сообщениями на базе открытого кода с поддержкой шифрования. Разработчиком является Guardian Project. Мессенджер соответствует всем необходимым параметрам, предложенным EFF, гарантируя самую высокую степень безопасности и приватности (однако только при условии использования вместе с Tor-плагином Orbot на базе Tor).
- CryptoCat — открытый мессенджер с поддержкой шифрования, работающий с браузерами Chrome, Firefox, Safari и Opera, а также в качестве отдельного сервиса в Apple OS X и на iPhone. Этим летом разработчики CryptoCat занимались поиском спонсоров для разработки Android-версии и создания шифрованного видеочата — возможно, скоро «криптокот» появится и на этой платформе.
- Signal, RedPhone и Textsecure — продукты компании Whisper Systems, предназначенные, соответственно, для обмена сообщениями на iOS-устройствах, совершения конфиденциальных звонков с Android-устройств и переписки между Android-пользователями. Каждое из приложений имеет открытый исходный код и предлагает полное шифрование передачи и хранения данных.
- Silent Phone и Silent Text — сервисы безопасных звонков и обмена сообщениями от Silent Circle. Они, конечно, платные, зато совместимы с платформами iOS и Android, а также работают на традиционных ПК. Компания Silent Circle также разработала собственную модель защищенного от проникновения смартфона на базе модифицированной сборки Android под названием Blackphone. Также предлагается поддержка корпоративных клиентов.
- Telegram — бесплатный кроссплатформенный мессенджер, позволяющий обмениваться сообщениями и медиафайлами. В системе используется проприетарная серверная часть, работающая на мощностях нескольких хостинг-компаний США и Германии, и несколько клиентов с открытым исходным кодом (под GNU GPL). Для мессенджера был создан протокол MTProto, предполагающий использование нескольких протоколов шифрования. При авторизации и аутентификации используются алгоритмы RSA-2048, DH-2048 для шифрования, при передаче сообщений протокола в сеть они шифруются AES с ключом, известным клиенту и серверу. Также применяются криптографические хеш-суммы SHA-1 и MD5.
- Pidgin — мультипротокольный опенсорсовый IM-клиент с поддержкой Jabber, AIM, ICQ, GTalk, MSN, Yahoo!, Sametime и др. Есть возможность аудио и видео связи.
Осторожно длинная картинка
Сводная таблица
Журнал ][акер
- Мессенджер Telegram сливает метаданные всем желающим (1 декабря, 2015 Мария Нефедова)
- Telegram заблокировал 78 каналов ИГИЛ, а эксперты ставят под вопрос безопасность мессенджера ( 20 ноября 2015, Мария Нефедова )
- Китай заблокировалTelegram (13 июля 2015, Анатолий Ализар)
- Павел Дуров рассказал о расходах Telegram и планах на будущее ( 9 июня 2015, Мария Нефедова)
- Telegram предлагает хакерам $400 тыс. ( 5 ноября 2014, Анатолий Ализар)
Хабр
- Матрица возможностей современных мессенджеров с упором на безопасность (23 ноября 2015, Scratch)
- О тонкостях приватности в Telegram Bots API: «это не баг, это фича» (3 июля 2015, deNULL)
- Атака Telegram за 2^64 операций, и почему суперзлодею она не нужна (12 марта 2015, Davidov)
- Потенциальная уязвимость в Telegram Android (19 февраля 2015, visput)
- Безопасен ли Telegram? v2 (2 декабря 2014, f0rbidik)
- Откровенность API Telegram (11 февраля 2014, Bakuutin)
- Тревожные симптомы Telegram (15 октября 2014, alex0ff)
- Новый баг в Telegram'e (26 декабря 2013, me3k)
- Безопасен ли Telegram? Или как я искал закладку в MTProto (22 декабря 2013, x7mz)
- Остались ли ещё закладки в Telegram? (23 декабря 2013, aabc)
- Ответный вызов разработчикам Telegram (20 декабря 2013, ArtyomKazak)
- Ловушка конкурсов по взлому (20 декабря 2013, galaxy)
- $200 000 любому, кто взломает IM-мессенджер Telegram (18 декабря 2013, alizar)
Касперский
Push me and then decrypt me till your can get law satisfaction
- Золотой ключик, или Приключения Буратино в стране криптографии (25 Ноябрь 2015, Serge Malenkovich)
- Рассекреченные материалы, или Безопасны ли мессенджеры? (20 Ноябрь 2015, Alex Perekalin)
- Кэмерон против шифрования (15 Январь 2015 Igor Oskolkov)
- Девять самых безопасных систем обмена сообщениями (14 Ноябрь 2014, Brian Donohue)
- Безопасный интернет-мессенджер. Существует ли он? (16 Апрель 2014, Alex Savitsky)
Security Lab
- Telegram раскрывает метаданные третьим лицам (30 Ноября, 2015)
- Telegram не настолько защищен, как кажется террористам (19 Ноября, 2015)
- Руководство Telegram отрицает наличие уязвимости в приложении для защищенного общения (24 Февраля, 2015)
- Террористы разработали план обхода блокировки в Telegram (19 Ноября, 2015)
TJ
- Пользователи «Хабрахабра» пожаловались на предложение написать заказные статьи с антипиаром Telegram
- Мессенджеры для параноиков (25 февраля 2014 Елистратов)
- Павел Дуров прокомментировал для CNN историю с подготовкой теракта через Telegram (04 октября 2015)
- СМИ сообщили о массовом переходе украинских политиков на Telegram из-за сообщений об уязвимостях в Viber (17 августа 2015)
- «Представляю, как новое поколение россиян начинает верить в превосходство госрегулирования над свободой» (03 июля 2015)
- В Telegram опровергли отчёт специалиста по безопасности о взломе мессенджера (24 февраля 2015)
- Telegram заплатит 300 тысяч долларов за расшифровку переписки двух ботов
Roem.ru
- Сотовые сети заметили бум «неотрегулированных» интернет-мессенджеров у корпоративных клиентов (2 сентября 2015 )
- Китайские власти провели PR-акцию Telegram и его функциям шифрования (13 июля 2015)
- Павел Дуров: реальной свободы слова нет ни в одной стране (3 апреля 2015)
- Дуров скрестил Slack и секретные чаты (19 марта 2015 )
- Дуров проигнорирует приказы властей о выдаче информации из Telegram (9 марта 2014)
- UCP проявило «заботу» о Telegram (18 ноября 2013)
РБК
Чиновники решили ограничить общение россиян в мессенджерах (9 декабря 2015)
Авторы (законопроекта об ограничении) предлагают внести в законы «Об информации...» и «О связи» такое понятие, как «информационно-коммуникационные сервисы». Под их деятельностью подразумевается передача «текстовых, голосовых и графических сообщений, технологически неразрывно связанных с услугами связи, оказываемыми третьими лицами на сетях передачи данных операторов связи». Представители интернет-компаний и операторов, ознакомившись с документом, пришли к выводу, что речь прежде всего идет о мессенджерах, хотя теоретически под действие закона могут попасть и соцсети.
P.S.
Согласно исследованию, проведенному «Лабораторией Касперского» совместно с B2B International, 62% опрошенных не считают онлайн-мессенджеры безопасными, 61% не доверяют IP-телефонии, 60% настороженно относятся к видеочатам. И тем не менее 37% принявших участие в опросе чаще всего используют для общения именно онлайн-мессенджеры, 25% — мессенджеры из социальных сетей и 15% — VoIP-сервисы.
Основные выводы исследования
Одна из критических уязвимостей современных мессенджеров (в том числе и Telegram) — это незащищенные метаданные (злоумышленники могут получить список контактов для определения круга общения, время доступа в сеть и тд), а очень часто факт коммуникации намного важнее содержания коммуникации. Какими инструментами это решить (исключить из системы централизованные серваки или что-то еще) предлагаю обсудить в комментах.
UPD
ru_crypt:
«Последние результаты по анализу протокола MTProto: eprint.iacr.org/2015/1177.pdf. В этой работе показано, что данный протокол не является стойким в модели IND-CCA, т.е. возможно любой шифртекст преобразовать в некоторый другой шифртекст, который может быть расшифрован в исходный открытый текст. Несмотря на то, что атака теоретическая, авторы рекомендуют все-таки не использовать самопальные решения, а реализовывать хорошо проверенные конструкции, ну и предлагают изменить протокол, чтобы атака не проходила.»
ValdikSS:
«Мне не нравится Telegram, но, в целом, он определенно лучше прочих популярных мессенджеров хотя бы тем, что там есть возможность сделать шифрованный чат с более-менее нормальной сверкой отпечатка ключа, но у обычных чатов-то защищен только транспорт, как и у, собственно, большинства прочих популярных мессенджеров, а СМИ, по большей части, описывают Telegram как супер защищенное решение, которым пользуются даже террористы, так что вам, типа, точно подойдет. Я считаю такое преувеличение со стороны СМИ достаточно большой проблемой, без шуток, т.к. такие новости привлекают в Telegram много технически неграмотных новых пользователей. Если в тот же Tor безопасность заложена архитектурно, то безопасность переписки неграмотных пользователей Telegram держится только на принципиальности разработчиков о нераскрытии данных и физической сохранности серверов, а в случае компрометации страдают не только сами пользователи, но и вы тоже, если вы переписывались с пользователем, данные которого, например, выдали правительственным организациям.»
zhovner:
«Эта тема сильно больше нас всех, потому как такая важная для человечества технология как IM и аудио-видео звонки не может быть управляема одной компанией. Есть всякие рабочие группы поддержания критических для индустрии библиотек и программ, типа openssl, apache. Мне кажется этим должен заниматься какой-то IETF.
Просто в какой-то момент они проебали это и открытые стандарты не успели за коммерческими поделками. То что сейчас IM монополизирован компаниями это ужасно. В идеале все мессенджеры должны поддерживать унифицированный минимальный стандарт, достаточный для того чтобы связаться с кем угодно, как email, а все свои фирменные штуки реализовывать внутри сети для своих пользователей.
Представьте что имейлы можно было бы слать только между outlook, но на gmail уже нельзя. Или звонить можно было только с Nokia на Nokia, а на самсунг нельзя. Именно так и выглядят так сейчас мессенджеры.»
J_o_k_e_R:
«Самый явный и очевидный фейл телеграма: централизованность серверов. Берутся за жопу те, кто ими управляют — и все. Нет телеграма. Пусть даже никто и не прочитает мою переписку в прошлом.
Вытекает этот фейл из чуть менее очевидного фейла — закрытости исходного кода серверов.»
