Is Telegram Safe? v2
From the very moment Telegram appeared, only lazy did not criticize it. The residents of Reddit, Hacker News, etc. did it with equal enthusiasm.
In a rush to reason the fiercest critics, a contest was announced with the main prize of $ 200,000 for the first person who could break the protocol and read the contents of a secret chat between two imaginary users.
The competition, as the organizers apparently expected, attracted attention, but caused a flurry of even more criticism due to the limited potential of researchers in choosing tools for analysis: only the encrypted contents of the correspondence were available, without being able to influence its contents or enter into or interaction with its authors (thus excluding opportunities for MITM, replay attacks, etc).
In response, some even offered a counter challenge on similar conditions, with a deliberately vulnerable protocol, pointing to the unrealistic nature of the proposed scenario.
A year later, taking into account the criticism, Telegram announced a new contest with a prize fund of $ 300,000 for breaking the protocol and an additional $ 100,000 for a successful attack, the result of which would be the bot receiving the encrypted message from the attacker.
')
At 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.).
The wide scope of opportunities for researchers, however, hides an inexorable fact: banal implementation errors are more often a threat to protocols 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 found significant resonance due to their criticality and coverage.
Bearing in mind that programmers make mistakes more often than mathematics *, I decided to start research not from a protocol, but from clients implementing this protocol. It was decided to start with the console client .
What a surprise it was when it was discovered that all the data of the “secret” chat (including the _private_ key) are stored on the disk in the unencrypted form:
And 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 Telegram does not guarantee forward secrecy ( PFS ), this means that an attacker who has been in passive listening mode ( eavesdropping ) for a long time, gaining control of your device, in addition to the contents of all secret chats (opened on this device), will also be able to continue on your behalf of any of them, not being forcibly completed by that moment.
How reliable is the protocol from this perspective?
Not too much. Because 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, be it 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, is the fact that the attacker will be able not only to decrypt all ** messages post factum , but also to 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 mechanism in the protocol (re-keying protocol) does not solve the problem, and in some circumstances only aggravates: because ratchet (re-keying protocol) designed to guarantee a perfect forward secrecy does not guarantee PFS in strict sense (the window for a ratchet is 100 messages or 1 week), an attacker can intercept the session and force a new ratchet to be forced, “cutting off” the compromised user from the session.
* Which, of course, is not true.
** Until the 20th version (20 layer) of the protocol, absolutely everything, starting with the 20th version of the protocol, everything, starting with the last ratchet.
In a rush to reason the fiercest critics, a contest was announced with the main prize of $ 200,000 for the first person who could break the protocol and read the contents of a secret chat between two imaginary users.
The competition, as the organizers apparently expected, attracted attention, but caused a flurry of even more criticism due to the limited potential of researchers in choosing tools for analysis: only the encrypted contents of the correspondence were available, without being able to influence its contents or enter into or interaction with its authors (thus excluding opportunities for MITM, replay attacks, etc).
In response, some even offered a counter challenge on similar conditions, with a deliberately vulnerable protocol, pointing to the unrealistic nature of the proposed scenario.
A year later, taking into account the criticism, Telegram announced a new contest with a prize fund of $ 300,000 for breaking the protocol and an additional $ 100,000 for a successful attack, the result of which would be the bot receiving the encrypted message from the attacker.
')
At 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.).
The wide scope of opportunities for researchers, however, hides an inexorable fact: banal implementation errors are more often a threat to protocols 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 found significant resonance due to their criticality and coverage.
Bearing in mind that programmers make mistakes more often than mathematics *, I decided to start research not from a protocol, but from clients implementing this protocol. It was decided to start with the console client .
What a surprise it was when it was discovered that all the data of the “secret” chat (including the _private_ key) are stored on the disk in the unencrypted form:
And 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 Telegram does not guarantee forward secrecy ( PFS ), this means that an attacker who has been in passive listening mode ( eavesdropping ) for a long time, gaining control of your device, in addition to the contents of all secret chats (opened on this device), will also be able to continue on your behalf of any of them, not being forcibly completed by that moment.
How reliable is the protocol from this perspective?
Not too much. Because 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, be it 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:
If you’re an interrupted, you’ll be able to take care of the interrogated messages and then appropriately select the interrogated messages. It can not be a problem . however, the following steps could be taken to overcome this weakness.
Silent, however, is the fact that the attacker will be able not only to decrypt all ** messages post factum , but also to 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 mechanism in the protocol (re-keying protocol) does not solve the problem, and in some circumstances only aggravates: because ratchet (re-keying protocol) designed to guarantee a perfect forward secrecy does not guarantee PFS in strict sense (the window for a ratchet is 100 messages or 1 week), an attacker can intercept the session and force a new ratchet to be forced, “cutting off” the compromised user from the session.
* Which, of course, is not true.
** Until the 20th version (20 layer) of the protocol, absolutely everything, starting with the 20th version of the protocol, everything, starting with the last ratchet.
Source: https://habr.com/ru/post/244735/
All Articles