Is Telegram safe? v2
Since the very appearance of Telegram, only the lazy has not criticized him. Residents of Reddit, Hacker News, etc. were equally enthusiastic about this.
In an effort to temper the most fierce critics, a contest was announced with the main prize of $ 200,000 for the first of those who manage to crack the protocol and read the contents of the secret chat between two fictitious users.
The competition, as the organizers expected, attracted attention, but it caused a flurry of criticism due to the limited potential researchers to choose tools for analysis: only encrypted content of the correspondence was available, without the ability to influence its contents or enter into any or interaction with its authors (thus excluding opportunities for MITM, replay attacks, etc).
In response, some even offered a counter challenge on similar terms, with a deliberately vulnerable protocol, indicating the unrealistic nature of the proposed scenario.
A year later, taking into account the criticism, Telegram announced a new contest with a prize pool of $ 300,000 for hacking the protocol and an additional $ 100,000 for a successful attack, which will result in the bot receiving an encrypted message from the attacker.
This time, any researcher can act not only in the passive role of an observer, but also has the ability to conduct active attacks (MITM, CPA, tampering, etc.).
However, the inexorable fact hides a wide range of possibilities for researchers: banal errors more often become a threat to protocolsimplementations rather than a vulnerable scheme. Everyone makes mistakes, and programmers here, unfortunately, are no exception:
Apple's 'goto fail' ( CVE-2014-1266 )
OpenSSL's 'Heartbleed' ( CVE-2014-0160 ).
Bash's 'ShellShock' ( CVE-2014-6271 )
This is just a small list of those that have gained significant resonance due to their criticality and scope.
Bearing in mind that programmers make mistakes more often than mathematicians *, I decided to start the study not from the protocol, but from clients implementing this protocol. It was decided to start from the console client .
What a surprise it was when it turned out that all the data of the "secret" chat(including _private_key) are stored on the disk in unencrypted form:
And are read by two functions `read_secret_chat_file`
and` read_secret_chat`:
Which is easily confirmed by the debugger:
What does this mean for the end user?
Since the Telegram protocol does not guarantee forward secrecy ( the PFS ), which means that an attacker, a long time in a passive mode of listening ( eavesdropping ), gaining control over your device, in addition to the contents of the secret chats (open on the device), also have the opportunity to continue on your behalfany of them, which by that time was not forcibly completed.
How reliable does the protocol look from this perspective?
Not too much. Since in this case the reliability of all your correspondence begins to be determined not by the stability of the protocol, but by the reliability of the weakest component of your system, whether it be a browser ... or a shell.
Stay tuned.
PS The problem turned out to be endemic not only for the console client but also for the Android client (https://github.com/DrKLO/Telegram)
PPS Telegram developers are aware of the problem and consider it an acceptable compromise:
Silent however, the fact that the attacker will be able to not only decrypt all ** post factum messages , but also intercept and continue the session in such a way that the interlocutor of the compromised user will not notice the substitution.
PPPS The newly introduced ratcheting (re-keying protocol) mechanism in the protocol does not solve the problem, and in some circumstances only exacerbates it: due to the ratchet (re-keying protocol), designed to guarantee perfect forward secrecy , it does not guarantee PFS in strict sense (the window for ratchet is 100 messages or 1 week), the attacker can intercept the session and forcefully initiate a new ratchet, “cutting off” the compromised user from the session.
* Which, of course, is not true.
** Up to the 20th version (20 layer) of the protocol, absolutely everything starting from the 20th version of the protocol, everything starting from the last ratchet.
In an effort to temper the most fierce critics, a contest was announced with the main prize of $ 200,000 for the first of those who manage to crack the protocol and read the contents of the secret chat between two fictitious users.
The competition, as the organizers expected, attracted attention, but it caused a flurry of criticism due to the limited potential researchers to choose tools for analysis: only encrypted content of the correspondence was available, without the ability to influence its contents or enter into any or interaction with its authors (thus excluding opportunities for MITM, replay attacks, etc).
In response, some even offered a counter challenge on similar terms, with a deliberately vulnerable protocol, indicating the unrealistic nature of the proposed scenario.
A year later, taking into account the criticism, Telegram announced a new contest with a prize pool of $ 300,000 for hacking the protocol and an additional $ 100,000 for a successful attack, which will result in the bot receiving an encrypted message from the attacker.
This time, any researcher can act not only in the passive role of an observer, but also has the ability to conduct active attacks (MITM, CPA, tampering, etc.).
However, the inexorable fact hides a wide range of possibilities for researchers: banal errors more often become a threat to protocolsimplementations rather than a vulnerable scheme. Everyone makes mistakes, and programmers here, unfortunately, are no exception:
Apple's 'goto fail' ( CVE-2014-1266 )
OpenSSL's 'Heartbleed' ( CVE-2014-0160 ).
Bash's 'ShellShock' ( CVE-2014-6271 )
This is just a small list of those that have gained significant resonance due to their criticality and scope.
Bearing in mind that programmers make mistakes more often than mathematicians *, I decided to start the study not from the protocol, but from clients implementing this protocol. It was decided to start from the console client .
What a surprise it was when it turned out that all the data of the "secret" chat(including _private_key) are stored on the disk in unencrypted form:
And are read by two functions `read_secret_chat_file`
and` read_secret_chat`:
Which is easily confirmed by the debugger:
What does this mean for the end user?
Since the Telegram protocol does not guarantee forward secrecy ( the PFS ), which means that an attacker, a long time in a passive mode of listening ( eavesdropping ), gaining control over your device, in addition to the contents of the secret chats (open on the device), also have the opportunity to continue on your behalfany of them, which by that time was not forcibly completed.
How reliable does the protocol look from this perspective?
Not too much. Since in this case the reliability of all your correspondence begins to be determined not by the stability of the protocol, but by the reliability of the weakest component of your system, whether it be a browser ... or a shell.
Stay tuned.
PS The problem turned out to be endemic not only for the console client but also for the Android client (https://github.com/DrKLO/Telegram)
PPS Telegram developers are aware of the problem and consider it an acceptable compromise:
The protocol's principal drawback is that an intruder passively intercepting messages and then somehow appropriating the authorization key (for example, by stealing a device) will be able to decrypt all the intercepted messages post factum. This probably is not too much of a problem (by stealing a device, one could also gain access to all the information cached on the device without decrypting anything); however, the following steps could be taken to overcome this weakness
Silent however, the fact that the attacker will be able to not only decrypt all ** post factum messages , but also intercept and continue the session in such a way that the interlocutor of the compromised user will not notice the substitution.
PPPS The newly introduced ratcheting (re-keying protocol) mechanism in the protocol does not solve the problem, and in some circumstances only exacerbates it: due to the ratchet (re-keying protocol), designed to guarantee perfect forward secrecy , it does not guarantee PFS in strict sense (the window for ratchet is 100 messages or 1 week), the attacker can intercept the session and forcefully initiate a new ratchet, “cutting off” the compromised user from the session.
* Which, of course, is not true.
** Up to the 20th version (20 layer) of the protocol, absolutely everything starting from the 20th version of the protocol, everything starting from the last ratchet.