Feature Request: add HTTPS proxy

[s3rj1k]

In addition to HTTP proxy, would be nice to have option to use HTTPS proxy (tls+http)
for more security

[john-preston]

@s3rj1k There is no need for https here, because everything is encrypted using MTProto, so no one can see anything that would be hidden by https.

[s3rj1k]

MTProto can be detected by DPI and blocked, but if one would tunnel through HTTPS proxy no one sane would drop those packets.

[stek29]

Same applies for SOCKS (even with passwords) btw.

[s3rj1k]

@stek29 yep. But secure SOCKS (shadowsocks) is kind of hackish protocol.

On the other hand HTTPS is defacto standard, implemented in all major web browsers.

[s3rj1k]

@john-preston any news on this?

[john-preston]

@s3rj1k No news, sorry :( Current proxy implementation works through http://doc.qt.io/qt-5/qnetworkproxy.html and I'm not sure they support https proxy (otherwise it would work already).

[s3rj1k]

made JIRA issue for upstream https://bugreports.qt.io/browse/QTBUG-67709

[101usb]

Proxy authorization data transfers as a plain text (by design in RFC). It is not safe to use your application with a proxy in public networks. Please add support tls/ssl protocol for socks/http proxy

[stek29]

@101usb No, it is as safe to use Telegram with proxy as without proxy (so pretty much safe)

[s3rj1k]

@stek29 we would feel safer with TLS encryption option in proxy :)

[evgenylarin]

@stek29 @101usb mean that proxy credentials could be intercept by MITM and using, because credentials transfers as a plain text.

[john-preston]

@Aokromes I have HTTP and HTTPS requests used in tdesktop, but I'm not sure how you use HTTPS proxy there - I see only HTTP proxy type in docs.

[omkarnathsingh]

I tried a HTTPS proxy from here, https://us-proxy.org/ It worked for me in Tdesktop 1.2.18 alpha, although it displays HTTP in tdesktop UI.

[s3rj1k]

I'll just leave this link here (in russian)

[lgg]

@s3rj1k that link' tl;dr;

One of the biggest Russian ISP blocks MTProxy by checking packet sizes.

[stale]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[s3rj1k]

Still an issue

[ilya-fedin]

Qt folks decided not to support HTTPS proxies, so tdesktop wouldn't have support for them as well:
https://bugreports.qt.io/browse/QTBUG-66601

[s3rj1k]

@ilya-fedin Well this is disappointing to say the least.

[stale]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[s3rj1k]

Still an issue, this brings a bit more sadness :(

[ilya-fedin]

This still needs implementation on Qt level. Given that Qt folks decided not to implement this, this will be never implemented, most likely.

[s3rj1k]

MTProto mode is definitely not implemented by QT, so what stops using some third-party lib to support HTTPS proxy?

[ilya-fedin]

Are you sure there any? According to Qt issue, only browsers have support for this.

[s3rj1k]

@ilya-fedin I will allow to support any feasible network proxy, so I don't think that this is over-engineering.

But yea, less prettier then native Qt API wrapper

[s3rj1k]

And Qt already has SOCKS server code bits :)

[ilya-fedin]

so I don't think that this is over-engineering

Having a proxy server inside a messenger is definitely over-engineering. Not to say how much questions would be from admins of stores with confined environments (Microsoft Store, Mac App Store, Snap Store, Flathub).

[s3rj1k]

Could be an optional plugin maybe.

[ilya-fedin]

tdesktop doesn't have plugin support and won't most likely

[s3rj1k]

Could be a button in GUI that installs separate SOCKS5 server application :)

[ilya-fedin]

Even more over-engineering. You propose solutions that acceptable only for unofficial clients for power users, not for an official client of a messenger for mass market.

[s3rj1k]

Well I propose a solution, you on the other hand say that this is impossible to do in any way, no offense intended.
If tdesktop team does not think that HTTPS proxy is important enough to implement, then please say so and close this request as Wont fix, so that public would know.

[ilya-fedin]

Yeah, it's not important enough to be implemented any time soon, but feature requests that have no plan to be implemented aren't being closed usually here.

[s3rj1k]

@ilya-fedin Are you sure that they are not closed?
What about #6218 ?)

[ilya-fedin]

I see it's closed as a duplicate. But I don't understand why Aokromes mark issues as duplicates of comments.

[s3rj1k]

I don't see any mentions of duplicate issue, it was just brutally closed :)

[ilya-fedin]

When @Aokromes posts a link to another issue or comment and closes, this means he marked the issue as a duplicate

[s3rj1k]

And probably closing them explicitly is a better way of communicating team intentions to public rather when waiting for a bot to auto-close it, in hopes that nobody cares anymore :)

[ilya-fedin]

Not really. If feature requests aren't considered to be implemented any time soon, this doesn't mean that they won't be implemented at all.

[s3rj1k]

It gives a false hope for tdesktop users, almost 3 years have past since initial report

[ilya-fedin]

probably people don't understand that feature requests are just feature requests and if no one says something will be implemented, that won't be implemented any time soon most likely

[s3rj1k]

That is because they are left open without any feedback until бездушная машина (bot) closes them.

There is a reason why Qt closes tickets with Won't fix rather then leaving them hanging there indefinitely until some auto grim-ripper closes it.

Wouldn't you say that knowing about Qt lack of interest in implementing HTTPS proxy API closes some of your open gestalts ?

[ilya-fedin]

There is a reason why Qt closes tickets with Won't fix rather then leaving them hanging there indefinitely until some auto grim-ripper closes it.

Whatever you will write, this won't be changed most likely, sorry.

Wouldn't you say that knowing about Qt lack of interest in implementing HTTPS proxy API closes some of your open gestalts ?

I can't parse that.

[s3rj1k]

So If a read your comments correctly, you say that tdesktop team does not care much about user created issues in github?

[ilya-fedin]

AFAIK there's no "tdesktop team". AFAIK john-preston is the only hired developer here and all his time goes to implementing whatever hiss bosses tell to implement him. But he is the only who reads issues here. In other words, "tdesktop team" (in form of preston) reads that, but that issue tracker is not really official and other part of Telegram team doesn't see these feature requests, most likely.

[s3rj1k]

So how to make an official issue request?

Also this one makes me more sad
#8651 (comment)

Seems like proxy stuff is a big tdesktop problem

[ilya-fedin]

So how to make an official issue request?

Previously it was possible only via in-app support.
Now here is bugs.telegram.org.

[s3rj1k]

https://bugs.telegram.org/c/4358

[ilya-fedin]

(no one there closes issues as won't fix as well, btw)

[s3rj1k]

(no one there closes issues as won't fix as well, btw)

well, lol :)