|
|
@@ -8,109 +8,35 @@ Bullshit-free MTPROTO proxy for Telegram
|
|
8
|
8
|
|
|
9
|
9
|
# Rationale
|
|
10
|
10
|
|
|
11
|
|
-Telegram supports proxies and proxies act as a shield for censorship
|
|
12
|
|
-and blocking actions of different goverments. At the moment of writing,
|
|
13
|
|
-Telegram supports 2 types of proxies:
|
|
14
|
|
-
|
|
15
|
|
-1. SOCKS5
|
|
16
|
|
-2. MTPROTO
|
|
17
|
|
-
|
|
18
|
|
-SOCKS5 proxy is general SOCKS proxy as defined in
|
|
19
|
|
-[RFC1928](https://www.ietf.org/rfc/rfc1928.txt). The problem is that
|
|
20
|
|
-by default SOCKS5 proxy has an access to the whole internet so a lot
|
|
21
|
|
-of people tend to hide them "just for a case". It is possible to setup
|
|
22
|
|
-SOCKS5 proxy so it is able to access just some IPs/CIDRs but, you know,
|
|
23
|
|
-yeah.
|
|
24
|
|
-
|
|
25
|
|
-MTPROTO proxy is a native Telegram proxy. It has several advantages:
|
|
26
|
|
-
|
|
27
|
|
-1. Traffic is obfuscated by AES-CTR;
|
|
28
|
|
-2. It allows connections only to Telegram services;
|
|
29
|
|
-3. It gives proxy maintainer an ability to promote its channel.
|
|
30
|
|
-
|
|
31
|
|
-But in reality, MTPROTO have 2 advantages (from my biased view):
|
|
32
|
|
-
|
|
33
|
|
-1. Obfuscation
|
|
34
|
|
-2. Simplify connection chain.
|
|
35
|
|
-
|
|
36
|
|
-Here is how it looks like to work with SOCKS5 proxy:
|
|
37
|
|
-
|
|
38
|
|
-```
|
|
39
|
|
-Client -> SOCKS -> MTPROTO -> Telegram
|
|
40
|
|
-```
|
|
41
|
|
-
|
|
42
|
|
-SOCKS5 connects to IPs of Telegram proxies. AFAIK this is because
|
|
43
|
|
-Telegram wants us to avoid censorship and regulations.
|
|
44
|
|
-
|
|
45
|
|
-What MTPROTO proxies do:
|
|
46
|
|
-
|
|
47
|
|
-```
|
|
48
|
|
-Client -> MTPROTO -> Telegram
|
|
49
|
|
-```
|
|
50
|
|
-
|
|
51
|
|
-And promoted channels. I do not tend to use them because mtg was created
|
|
52
|
|
-for slightly other way of using it but yeah. People want moneys.
|
|
53
|
|
-
|
|
54
|
|
-There are a number of unofficial proxies and one
|
|
55
|
|
-[OFFICIAL](https://github.com/TelegramMessenger/MTProxy), so why bother?
|
|
56
|
|
-
|
|
57
|
|
-<start-biased-rant>
|
|
58
|
|
-
|
|
59
|
|
-I'm a big fan of [ShadowSocks](http://www.shadowsocks.org/en/index.html)
|
|
60
|
|
-project and I like how people use it. The majority of SS proxies are
|
|
61
|
|
-disposable ones which are blocked/unblocked frequently. There are some
|
|
62
|
|
-public lists of them in Internet so if one proxy has stopped to work,
|
|
63
|
|
-you throw it out and use another one.
|
|
64
|
|
-
|
|
65
|
|
-Some SS proxies are long-living. This is because they are not public and
|
|
66
|
|
-intended to be used only by limited number of people. And single secret
|
|
67
|
|
-is fine there.
|
|
68
|
|
-
|
|
69
|
|
-What I do not get about official and some unofficial implementation is
|
|
70
|
|
-why they decided to support multiple secrets? I mean, WTF with all of
|
|
71
|
|
-you?
|
|
72
|
|
-
|
|
73
|
|
-1. MTPROTO obfuscation (called obfuscated2) does not allow to verify
|
|
74
|
|
- client easily. You need to decrypt the frame for every secret. So, you
|
|
75
|
|
- need a number of workers which will constantly try to crack initial
|
|
76
|
|
- handshake frames with a list of secrets. That does not scale and will
|
|
77
|
|
- never be.
|
|
78
|
|
-
|
|
79
|
|
-2. Why do you need a multiple secrets? Which task are you trying to
|
|
80
|
|
- solve with them? Valid secret means only 1 thing: access to Telegram. A
|
|
81
|
|
- binary thing. Absurd and rudimentarty access control.
|
|
82
|
|
-
|
|
83
|
|
-Okay, you want to revoke an access, thats fine. Will you ssh to the
|
|
84
|
|
-machine and restart the container? Do you want to have API for that? Web
|
|
85
|
|
-UI? Maybe store secrets in database and collect statisitcs per each?
|
|
86
|
|
-
|
|
87
|
|
-With all respect, this is idiotic thing. Guysngals, this is a proxy.
|
|
88
|
|
-Gateway to Telegram. This is not a webservice, or SASS or name that
|
|
89
|
|
-shit. This is disposable stuff. Blocked? Fine, go to the next one. Just
|
|
90
|
|
-look at ShadowSocks. There is multiple user implementation available,
|
|
91
|
|
-with control you want. Does anyone gives a flying fuck about it?
|
|
92
|
|
-
|
|
93
|
|
-> Those Who Do Not Learn History Are Doomed To Repeat It
|
|
94
|
|
-- George Santayana
|
|
95
|
|
-
|
|
96
|
|
-What I want to have?
|
|
97
|
|
-
|
|
98
|
|
-1. Minimal tool for me and my friends (which are not all my FB friends but
|
|
99
|
|
- a limited number of close friends).
|
|
100
|
|
-2. Minimum viable configuration.
|
|
101
|
|
-3. Single artifact runnable on every platform (not always Docker, some
|
|
102
|
|
- environments may have no Docker)
|
|
103
|
|
-4. Smallest Docker image
|
|
104
|
|
-5. Lightweight
|
|
105
|
|
-6. Have as less management as possible.
|
|
106
|
|
-
|
|
107
|
|
-</end-biased-rant>
|
|
108
|
|
-
|
|
109
|
|
-So, please do not ask for:
|
|
110
|
|
-
|
|
111
|
|
-1. Multiple users/secrets
|
|
112
|
|
-2. Web UI
|
|
113
|
|
-3. Detailed statistics/histograms etc.
|
|
|
11
|
+There are several available proxies for Telegram MTPROTO available. Here
|
|
|
12
|
+are the most notable:
|
|
|
13
|
+
|
|
|
14
|
+* [Official](https://github.com/TelegramMessenger/MTProxy)
|
|
|
15
|
+* [Python](https://github.com/alexbers/mtprotoproxy)
|
|
|
16
|
+* [Erlang](https://github.com/seriyps/mtproto_proxy)
|
|
|
17
|
+* [JS](https://github.com/FreedomPrevails/JSMTProxy)
|
|
|
18
|
+
|
|
|
19
|
+Almost all of them follow the way how official proxy was build. This
|
|
|
20
|
+includes support of multiple secrets, support of promoted channels etc.
|
|
|
21
|
+
|
|
|
22
|
+mtg is an implementation in golang which is intended to be:
|
|
|
23
|
+
|
|
|
24
|
+* **Lightweight**
|
|
|
25
|
+ It has to consume as less resources as possible but not by losing
|
|
|
26
|
+ maintainability.
|
|
|
27
|
+* **Easily deployable**
|
|
|
28
|
+ I strongly believe that Telegram proxies should follow the way of
|
|
|
29
|
+ ShadowSocks: promoted channels is a strange way of doing business
|
|
|
30
|
+ I suppose. I think the only viable way is to have a proxy with
|
|
|
31
|
+ minimum configuration which should work everywhere.
|
|
|
32
|
+* **Single secret**
|
|
|
33
|
+ I think that multiple secrets solves no problems and just complexify
|
|
|
34
|
+ software. I also believe that in case of throwout proxies, this feature
|
|
|
35
|
+ is useless luxury.
|
|
|
36
|
+* **Minimum docker image size**
|
|
|
37
|
+ Official image is less than 2 megabytes. Literally.
|
|
|
38
|
+* **No management WebUI**
|
|
|
39
|
+ This is an implementation of simple lightweight proxy. I won't do that.
|
|
114
|
40
|
|
|
115
|
41
|
|
|
116
|
42
|
# How to build
|