search

thebrumby / HotWalletClaimer

Looking to optimize HOT earnings on Near Protocol, Wave on SUI, Vertus on TON, or other supported apps like Hamster Kombat? This Python script monitors and claims rewards for your favorite Telegram crypto games. It avoids API injections by simulating mouse movements in a real browser.
MIT License
178 stars 48 forks source link

502 Bad GateWay when using third-party proxy config #204

Closed phamvanhanh6720 closed 1 month ago

phamvanhanh6720 commented 1 month ago

Hi @thebrumby I setup a third-party proxy and it's tested ok. However, when I run any game scripts, I got the below error image

phamvanhanh6720 commented 1 month ago

I think you should use http instead of https. I change to http and it's working now image

thebrumby commented 1 month ago

Hi @phamvanhanh6720,

Firstly, thank you for using the built-in screenshots before raising this support ticket; it has saved us both a lot of time and allowed for a quicker diagnosis of the issue.

As you may know, HTTPS is designed to enforce a secure, encrypted connection between your script running on your PC or VPS and the services it interacts with, such as Telegram, the game server, or a VPN. Encryption protects sensitive data, like authentication credentials, from being read by others.

In your first screenshot, the error message indicates that the server you're connecting to does not support TLS (Transport Layer Security), which is the protocol that underpins HTTPS. The message explicitly states that the server "does not speak TLS," which I believe is an error generated by the MITM Proxy on our side.

When you changed the connection type from HTTPS to HTTP in line 65, the connection started working because you effectively agreed to communicate on the remote server's terms—using an unencrypted connection. HTTP does not enforce encryption, which is why it bypasses the TLS requirement and works with a server that doesn't support TLS.

Interestingly, the URL I use for web.telegram.org in each game script explicitly starts with HTTPS, and it seems that this does not produce any errors for you. This suggests that once the initial connection is established (even if it starts with HTTP), the communication later down the line does indeed switch to a secure HTTPS connection. However, it's worth noting that our script overrides certificate errors, which means the connection might not be as secure as it appears, even if it switches to HTTPS.

While using HTTP may work for you and resolves your immediate issue, it's important to consider the potential security risks. Performing authentication over an unsecured connection (HTTP) means that your credentials could be intercepted by any relay point between your PC/VPS, your VPN, or potentially even TG web and the game's final server. Exposing your login credentials over an unsecured connection could allow someone else to log into your VPN as if they were you.

If you are comfortable with the trade-offs and fully aware of the risks, using HTTP may be acceptable for your specific use case. However, for the version of the script in the repository, I'll continue to enforce the use of an encrypted HTTPS connection to ensure that all data is securely transmitted.

I did my testing of the proxy using smartproxy.com, who were expensive, but correctly handle these kinds of connections.

Best regards, Phil