Using NTLM authentication in HTTP monitor causes error:0308010C:digital envelope routines::unsupported

[Tabisch]

📑 I have found these related issues/pull requests

Cloud be related to #2243

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

Description

Using NTLM authentication in the HTTP Monitor causes monitor to throw "error:0308010C:digital envelope routines::unsupported" as error.

Using environment vairable NODE_OPTIONS="--openssl-legacy-provider" makes the monitor work again. Doing this results in some socket breaking,

[MONITOR] ERROR: Caught error
[MONITOR] ERROR: No socket found

First encountered on 17.11.2023.

[!CAUTION] Edit by @Commanderstorm: from the docs Changes to the default cipher suite are typically made in order to strengthen the default security for applications running within Node.js. Reverting back to the defaults used by older releases can weaken the security of your applications. The legacy cipher suites should only be used if absolutely necessary.

👟 Reproduction steps

Create monitor with NTML authentication.

👀 Expected behavior

Monitor should start monitoring target.

😓 Actual Behavior

Monitoring fails with error "[MONITOR] WARN: Monitor #37 'x': Failing: error:0308010C:digital envelope routines::unsupported | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0"

🐻 Uptime-Kuma Version

1.23.11

💻 Operating System and Arch

Debian 11

🌐 Browser

Google Chrome 122.0.6261.95

🖥️ Deployment Environment

• Runtime: Docker 25.0.3, build 4debf41
• Database:
• Filesystem used to store the database on: ext4
• number of monitors: 17

📝 Relevant log output

No response

[CommanderStorm]

What digital envelope routines is your counterpart trying to use? What are you trying to monitor concretely?

[Tabisch]

Thank you for awnsering this quickly.

One is SQL Server Reporting Services from a MSSQL16 running on a Windows Server 2019. The other one is a sharepoint running on Windows Server 2012R2. I currently cant tell you the excat version of IIS the sharepoint is using. I can get you that info tomorrow when im back at work, if you need the exact version.

About the digital envelope routines. Can you tell me how i can look that up? Its the first time i have heard about this and when i google that it is just telling me about the NODE_OPTIONS variable that i set in environment.

[!CAUTION] Edit by @Commanderstorm: from the docs Changes to the default cipher suite are typically made in order to strengthen the default security for applications running within Node.js. Reverting back to the defaults used by older releases can weaken the security of your applications. The legacy cipher suites should only be used if absolutely necessary.

[morla10111]

Same issue here.Trying to check Share Point 2019.

[CommanderStorm]

The issue is that there is some mismatch between the routines node thinks are secure and your OS thinks are secure.

If you connect via https, which crypto method do you use? Is it one of the deprecated ones in https://www.openssl.org/docs/man3.1/man7/OSSL_PROVIDER-legacy.html that are no longer supported since the industry-wide shift to ossl3?

@morla10111 2019 was 5 years ago. Have you considered updating? @Tabisch 2012 was 12 years ago.

This issue might also be related to the axios upgrade drama around 1.0 (axios does not publish what they changed in 1.0 => making migration extremely risky) We are currently using a older version of ntlm because of this https://github.com/Catbuttes/axios-ntlm Given that

[morla10111]

hey @CommanderStorm, thank you for your effort on this issue.

SharePoint 2019 is the most recent Version :)

I have no issue using curl from the container like so:

curl --cacert /config/ca.bundle  --ntlm -u username https://sp.domain/
....
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
...

[morla10111]

hrrrrmmmm ... setting

NODE_OPTIONS=--openssl-legacy-provider

makes the monitor work. Will investigate further.

[!CAUTION] Edit by @Commanderstorm: from the docs Changes to the default cipher suite are typically made in order to strengthen the default security for applications running within Node.js. Reverting back to the defaults used by older releases can weaken the security of your applications. The legacy cipher suites should only be used if absolutely necessary.

[CommanderStorm]

SharePoint 2019 is the most recent Version :)

Somewhat doubt that one, because of the support status. Anyway ^^

[CommanderStorm]

TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

That is not a supported cypher according to https://node.readthedocs.io/en/latest/api/tls/#modifying-the-default-cipher-suite It is also considered weak => Understandable that node is not supporting to fall back this far.[^1]

What is interesting is that in the docker image we provide, node apparently does support said cypher. I don't know what is going on there.

node -p crypto.constants.defaultCoreCipherList | tr ':' '\n'

I am not convinced that this is a bug in uptime-kuma, nor something that we can/should fix (setting NODE_OPTIONS=--openssl-legacy-provider is not recommended by the docs => as a "library", we should stick with the security peoples guidance). I don't know if the docs can be updated to better help people here. Likewise, I don't see how/what should be changed.

We can reopen if this is indeed a problem by us or that we can fix without weakening the security.

[^1]: I thought that nowadays everything on the internet would be using TLS1.3 (=using PFS)...