Monitor fails due to self signed cert only when using socks5 proxy

[clintkev251]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

I have a single monitor in my Uptime Kuma instance which checks a server which is using a self-signed cert (a PiKVM). This was working fine when I was not using any proxy and had "Ignore TLS/SSL error for HTTPS websites" checked. However after adding the proxy (which is a socks5 (+DNS) proxy), the monitor fails due to this self signed certificate.

👟 Reproduction steps

Create an HTTP or HTTP keyword monitor which makes requests to a server with a self signed certificate and check "Ignore TLS/SSL error for HTTPS websites". Then create a Socks5 (+DNS) proxy and apply it to the monitor.

👀 Expected behavior

The server continues to be registered as ok

😓 Actual Behavior

The monitor registers the server as down due to the self-signed certificate.

🐻 Uptime-Kuma Version

1.21.0

💻 Operating System and Arch

Debian 5.10.162-1 (2023-01-21) x86_64

🌐 Browser

N/A

🐋 Docker Version

Docker 23.0.1

🟩 NodeJS Version

No response

📝 Relevant log output

2023-03-25T20:38:44-04:00 [MONITOR] WARN: Monitor #55 'PiKVM': Failing: self signed certificate | Interval: 120 seconds | Type: keyword | Down Count: 0 | Resend Interval: 0

[zanewgray]

I am on 1.23.2 (running on Rancher RKE2 Kubernetes) and seem to be running into this exact issue. Proxy is a HTTP Squid proxy (not SOCKS).

Any chance that the fix in 1.21.2 only applies to SOCKS proxies?

[CommanderStorm]

Yes, the fix only applies to socks, socks5, socks5h, socks4.

Given that I don't have an HTTP Squid proxy configured, could you test if adding the respective option to HttpProxyAgent/HttpProxyAgent above works?

⇒ Could you provide a PR via https://github.com/louislam/uptime-kuma/blob/bbaba29222eccdcda0a5a1e1e6355b8b0da057b9/CONTRIBUTING.md

[zanewgray]

Thanks for clarifying @CommanderStorm.

Regarding the "...could you test if adding the respective option to HttpProxyAgent/HttpProxyAgent above works?" request - I am honestly unsure how to do this. I suspect that I need to edity my server/proxy.js file, correct? Any chance that you could provide step-by-step instructions?

I'll get a PR submitted for this and reference #2981.

[zanewgray]

So I exec'd into the pod, added the nano package to the Debian build, and edited the server\proxy.js file to include the following:

...
            case "socks4":
                agent = new SocksProxyAgent({
                    ...httpAgentOptions,
                    tls: {
                        rejectUnauthorized: httpsAgentOptions.rejectUnauthorized,
                    },
                    ...httpsAgentOptions,
                    tls: {
                        rejectUnauthorized: httpsAgentOptions.rejectUnauthorized,
                    },
                    ...proxyOptions,
                    tls: {
                        rejectUnauthorized: httpsAgentOptions.rejectUnauthorized,
                    },
                });
...

Unfortunately, as I am running this on Kubernetes instead of Docker, I do not have an option to restart the container. I can only scale the deployment down and back up, which removes the changes to the proxy.js file.

I have also attempted to just kill the container processes (e.g. kubectl exec POD_NAME -c CONTAINER_NAME /sbin/killall5 and kubectl exec POD_NAME -c CONTAINER_NAME reboot) inside the pod in hopes that it would just restart the container, but retain the file changes. But this did not work either.

I'll shift my focus on submitting the PR instead.

[chakflying]

I did a cursory search and it seems like there are a lot of complications with passing rejectUnauthorized to the proxy library that we are using, and just adding the parameter won't work. (TooTallNate/proxy-agents#89)

I would advice against creating such a PR unless you can test and verify that it works.

[zanewgray]

I have tried a few more tests that assume that server/proxy.js is not called unless a proxy is configured. With the above configurations adjustments in place, I still received the "self signed certificate" error.

At this point, I am unable to confirm that the requested changes actually work (specifically, I cannot confirm that server/proxy.js is called only on container boot and then never again).

Per @chakflying, I'll hold off on the PR creation for now.