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[bot]]

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[bot]]

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 https://github.com/curl/curl/blob/master/docs/cmdline-opts/version.d#L41 curl supports HTTPS proxies

[ilya-fedin]

I don't think it's possible to use Qt's network APIs and curl's proxy support simultaneously. Migrating from Qt's network APIs to curl's ones is not an option, most likely.

[s3rj1k]

@ilya-fedin Then how is Qt network API currently works with MTProto?

[ilya-fedin]

Then how is Qt network API currently works with MTProto?

MTProto is implemented from scratch using Qt network APIs. Don't expect that the same amount of work will be repeated to support HTTPS proxies, of course.

[s3rj1k]

@ilya-fedin No need to implement whole HTTPS support, only bridge between SOCKS5 native support in Qt network APIs and internal SOCKS5 layer to HTTPS, that way any proxy protocol could be implemented without a need of Qt support

[s3rj1k]

Would be perfectly fine if telegram desktop would start SOCKS5 proxy bound to localhost

[ilya-fedin]

No need to implement whole HTTPS support, only bridge between SOCKS5 native support in Qt network APIs and internal SOCKS5 layer to HTTPS, that way any proxy protocol could be implemented without a need of Qt support

Well, if you know how to implement, maybe you create a PR?

[s3rj1k]

@ilya-fedin If I could, I would have, but sadly I do not have needed expertise in C/C++

I could write one in Go :)

[ilya-fedin]

'bridge between SOCKS5 native support in Qt network APIs and internal SOCKS5 layer to HTTPS' doesn't sound like something easy to implement. If HTTPS proxies have SOCKS inside then it's even more complicated than I thought.

[s3rj1k]

@ilya-fedin No, I was talking about different thing.

• TelegramDesktop starts in a separated thread SOCK5 server, that accepts connections on loopback
• Qt network API calls are pointed to that SOCKS5 server
• SOCKS5 server acts as a MITM proxy and proxies all connection to remote HTTPS proxy

That way there is no need to implement a wrapper for Qt network API

[ilya-fedin]

I don't think such over-engineering is acceptable

[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 https://github.com/telegramdesktop/tdesktop/issues/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.