mtprotoproxy
mtprotoproxy copied to clipboard
alexbers
Experimental link doesn't work at all
With the latest addition of TLS option standard link works as expected but the experimental link doesn't work at all - it just tries to connect indefinitely. Tried on windows 1.8.1 client and android 5.10.0. tried multiple networks different ISPs including VPN connections.
00:00:00.872238 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [S], seq 3754160274, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 00:00:00.000042 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [S.], seq 3185558187, ack 3754160275, win 28400, options [mss 1420,nop,nop,sackOK,nop,wscale 7], length 0 00:00:00.076757 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [.], ack 1, win 260, length 0 00:00:00.000403 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [P.], seq 1:518, ack 1, win 260, length 517 00:00:00.000012 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [.], ack 518, win 231, length 0 00:00:00.000736 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [P.], seq 1:127, ack 518, win 231, length 126 00:00:00.077025 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [P.], seq 518:694, ack 127, win 260, length 176 00:00:00.043364 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [.], ack 694, win 239, length 0 00:00:00.011461 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [F.], seq 127, ack 694, win 239, length 0 00:00:00.076651 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [.], ack 128, win 260, length 0 00:00:00.000045 IP 46.48.xx.xx.47727 > 10.156.0.10.33589: Flags [F.], seq 694, ack 128, win 260, length 0 00:00:00.000015 IP 10.156.0.10.33589 > 46.48.xx.xx.47727: Flags [.], ack 695, win 239, length 0 ^C 228 packets captured 228 packets received by filter 0 packets dropped by kernel root@1eb7:/opt/mtprotoproxy#
for me, it just connects and the blue shield shows it's connected but in fact, it doesn't load any new message or photos. if I try the same with a VPN connection it works. I think they have detected the new TLS and DPI is blocking it as well.
@ParaNULL What secret do you use? The one which is written to stdout?
@MasterGroosha yes the one that's being printed on output ,according to this topic here: https://github.com/alexbers/mtprotoproxy/issues/115 avoid using base64url in your secrets for ios clients (even those guys reported it here:https://github.com/TelegramMessenger/Telegram-iOS/issues/118
@ParaNULL Well, I get this in output:
tg2: tg://proxy?server={my IP}&port=3256&secret=7gEjRWeJq83vASNFZ4mrze9nb29nbGUuY29t (experimental)
When using this link in TDesktop 1.8.1 and TAndroid 5.10, client stucks on "Connecting to proxy"
Are you sure it's not related to your server configuration... Is tcp 3256 accessable?! Everything is okay when you see this printed on output
@ParaNULL Yes, I'm sure, since I'm using that server for official MTProxy (on another port of course)
the maximum tls record size was decreased according the specification: https://github.com/alexbers/mtprotoproxy/commit/48330f1e8a1722a62f1680edf010409c034fcb8b. Could you please retry with the latest version
@alexbers No, neither TDesktop nor Telegram for Android work with the latest git commit.
do this proxy link works for you? tg://proxy?server=bitblockinfo.com&port=443&secret=7gARIjNEVWZ3iJmqu8zd7v9iaXRibG9ja2luZm8uY29t
Dont work too. From syslog
Aug 13 08:07:03 v111231 python3[299]: future: <Task finished coro=<handle_client.<locals>.connect_reader_to_writer() done, defined at /root/mtprotoproxy/mtprotoproxy.py:1232> exception=TypeError("initializer for ctype 'unsigned char *' must be a cdata pointer, not bytearray",)>
Aug 13 08:07:03 v111231 python3[299]: Traceback (most recent call last):
Aug 13 08:07:03 v111231 python3[299]: File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
Aug 13 08:07:03 v111231 python3[299]: result = coro.send(None)
Aug 13 08:07:03 v111231 python3[299]: File "/root/mtprotoproxy/mtprotoproxy.py", line 1236, in connect_reader_to_writer
Aug 13 08:07:03 v111231 python3[299]: data = await rd.read(rd_buf_size)
Aug 13 08:07:03 v111231 python3[299]: File "/root/mtprotoproxy/mtprotoproxy.py", line 439, in read
Aug 13 08:07:03 v111231 python3[299]: return self.decryptor.decrypt(data)
Aug 13 08:07:03 v111231 python3[299]: File "/root/mtprotoproxy/mtprotoproxy.py", line 207, in decrypt
Aug 13 08:07:03 v111231 python3[299]: return self.decryptor.update(data)
Aug 13 08:07:03 v111231 python3[299]: File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 137, in update
Aug 13 08:07:03 v111231 python3[299]: return self._ctx.update(data)
Aug 13 08:07:03 v111231 python3[299]: File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 108, in update
Aug 13 08:07:03 v111231 python3[299]: len(data))
Aug 13 08:07:03 v111231 python3[299]: TypeError: initializer for ctype 'unsigned char *' must be a cdata pointer, not bytearray
@themiron thanks, upgraded pip from https://bootstrap.pypa.io/get-pip.py to 19.x from stock 9.x and its working now. Cryptography package was 2.7 and not upgradable
Hmm... I installed python3-distutils, upgraded cryptography from 2.1.4 to 2.7 and it seems to be working, thank you!
P.S. how to properly generate a secret for FakeTLS proxy?
Хм ... Я установил python3-distutils, обновил криптографию с 2.1.4 до 2.7 и, похоже, работает, спасибо!
PS как правильно сгенерировать секрет для прокси FakeTLS?
in any hex generator
@medfan00 however, as far as I know (correct me if I'm wrong), FakeTLS secrets should contain domain name, shouldn't they? For example, 7gEjRWeJq83vASNFZ4mrze9nb29nbGUuY29t from the default example can be base64 decoded as #Eg#Eggoogle.com
Could you try with the latest master. I think https://github.com/alexbers/mtprotoproxy/commit/53184470e94964a4a171b41957715b255c6f9d5f should fix the bug.
Yep, I'm on Ubuntu 16.04, updated cryptography and PIP and through MTprotoproxyinstall script updated main script - it creates new style secrets now "ee28919a0bab75ca81bd0652635fccf722676f6f676c652e636f6d (experimental)" and work perfectly! Either with Android and Windows clients!
Cпасибо за поддержку! Вива ля резустион или как там! :)
Мен, может ты нормально объяснишь. На хабре пишут что "ee" в начале секрета это и означает, что поддерживается Fake TLS верно? А то мне один кекс объясняет, что это чистая случайность. Просто после обновление стали появятся "ee"секреты.
Может быть как случайностью, так и знаком что поддерживается Fake TLS. Зависит от длины секрета, если она 32 байта, то случайность, а если больше то Fake TLS.
Может быть как случайностью, так и знаком что поддерживается Fake TLS. Зависит от длины секрета, если она 32 байта, то случайность, а если больше то Fake TLS.
eefeb724b56d620ee8c8f9b71772c51724676f6f676c652e636f6d Этот секрет я так понимаю Fake TLS да?