E: Well, I took a look at the desktop client with wireshark. It appears to just do MTProto on port 443, not TLS. When I use iptables to drop traffic on port 443, it falls back to MTProto over HTTP(!).
They list some alternate transports on their website, but it looks like you need to host them yourself. https://core.telegram.org/mtproto/transports
I reminisce that when Durov was questioned about the abscence of secure connection to the servers, he told it's a too much of overhead and may impact QoS badly.
Some time they rolled out an `always use https` option and buried it deep in the user preferences. Meaning most of non-tech savvy audience kept using the service unaware they are not secure.
The obvious pattern here is they tend to use plain http as a default transport unerminig established security practices.
[0] https://translate.google.com/translate?sl=auto&tl=en&u=https...
Could you expand on their usage of TLS and HTTP? Surely they don't send anything in plain-text over HTTP?
I thought they used TLS wrapping in some markets for censorship resistance, but apparently that is not the case unless you set up your own proxy.
You of all should know better than to conflate the general concept of encryption with the very nice special case that is end-to-end encryption!
> and 1:1 E2E is disabled by default.
It is not disabled in any way. It just isn't default.
There are really enough real reasons to criticize Telegram, absolutely no reason to 1. redefine words to have narrower definitions 2. Write outright misinformation.
I respect you a whole lot but your somewhat sloppy handling of facts detract a whole lot from the overall image.