Live data from Hacker News

Telegram - secure, free messaging

telegram.org

81–90 of 231 posts

Re: Telegram - secure, free messaging

#81
post #29

Earlier quoted context omitted.

The fact that we have to trust TLS to deliver software doesn't automatically mean that we should trust it for secure messaging. Also, I think App Store software delivery doesn't depend on only TLS, but also on Apple's signature. And you can visually verify that the source code downloaded from GitHub doesn't contain backdoors.

My knowledge on cryptography is next to nothing. Would you mind explaining to me what makes the case for secure messaging different than any other transfer through a secured HTTP connection? I also read a bit on OTR Messaging and the "Socialist Millionaires' Protocol" but just got even more confused.

It's not that messaging can't use TLS, of course, it can. I'm objecting to the absolute (if we don't trust TLS for messaging, we shouldn't trust it one-time download), e.g. see https://en.wikipedia.org/wiki/Threat_model

Re: Telegram - secure, free messaging

#82
post #30
post #28

Earlier quoted context omitted.

HTTPS is fine, it's just all the x509 surrounding it that people are upset about

No, it's not fine. Currently the only secure version of TLS is 1.2 with AES-GCM; and it's still not deployed widely.

Can you provide some more details for this claim? I'm interested.

Re: Telegram - secure, free messaging

#83
If this is closed source (and the source seems to be only implementing API calls to a closed system) then it's fair to assume that this application is probably insecure or has backdoors.

Also if the private key is stored in the cloud then it's likely to be subject to requisitions.

Re: Telegram - secure, free messaging

#84

Looking at [1], it has several red flags. The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages. Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE. Also, as already mentioned, there's again NO reason not to use…

The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections.

TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks.

MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.

Disclaimer: Unfortunately, I'm not Nikolay. But I do work for Telegram.

Re: Telegram - secure, free messaging

#85
post #38

Their HTTPS server isn't configured with the right certificate :( Firefox gives me "The certificate is only valid for the following names: *.stel.com , stel.com" for https://telegram.org/

Looks fine https://www.ssllabs.com/ssltest/analyze.html?d=telegram.org&...

Re: Telegram - secure, free messaging

#86
post #30

Earlier quoted context omitted.

No, it's not fine. Currently the only secure version of TLS is 1.2 with AES-GCM; and it's still not deployed widely.

Can you provide some more details for this claim? I'm interested.

Sure,

https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...

https://community.qualys.com/blogs/securitylabs/2013/03/19/r...

Re: Telegram - secure, free messaging

#87
post #75

Earlier quoted context omitted.

He's done nothing in crypto, and he's rolled his own protocol. That's historically been recipe for disaster regardless of how many honors you hold. Colin Percival is similarly decorated, along with being a cryptographer (he's the FreeBSD security officer): http://www.daemonology.net/papers/ ... yet even his crypto app Tarsnap was broken for over a year before he noticed, due to a typo during an innocent-looking refac…

And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't. Looks like the programme is open source: http://telegram.org/source

> "For the moment we are focusing on open sourcing the things that allow developers to quickly build something using our API. We started with Android and Linux, since these platforms are the most open, recently we published the iOS app code as well. We will be releasing more code eventually." -- http://telegram.org/faq#q-why-not-open-source-everything

Re: Telegram - secure, free messaging

#88

Is HTTPS not secure channel for communication between client-server? What is the reason behind using an entirely different protocol for client-server communication[0] over HTTP? [0] - http://core.telegram.org/mtproto

The main reason is speed. MTProto is designed to work fast on weak mobile connections. Another reason is security, with HTTPs you need to trust more parties.

Re: Telegram - secure, free messaging

#89
post #79
post #65

People here are complaining a lot about this app, and rightfully so. However, this is definitely the best encrypted communications app there is for ios and therefore also the only app that is cross platform and able to reach a wide audience. I know they didn't do it completely right, but it definitely seems to be the best option that is currently available.

An "encrypted communications app" that is not using secure encryption is worse than an unencrypted one - the users get a fake feeling of security, and might reveal sensitive information to whoever is listening. Regarding real security, have a look at ChatSecure, which is available for iOS and Android, uses standard encryption protocols (XMPP with TLS, OTR), is open source, and was developed by the Guardian Project (w…

Yes, I have been using chatsecure and I know it is much more secure but it is almost unusable on ios because it can not run in background.

As for the false sense of security, you're probably right.

Re: Telegram - secure, free messaging

#90
post #56

Looking at [1], it has several red flags. The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages. Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE. Also, as already mentioned, there's again NO reason not to use…

make sure to check out their structure definition language: http://core.telegram.org/mtproto/TL-dependent look like a great parody to me? can't tell if they are serious with these 'dependent types'

Is anything wrong with it?
Post reply on HN