EPROTO C0BAF076:error:0A000152 error reported in PM2 log from this version

[akc42]

Version

18.12.1

Platform

Linux pas 5.10.63-v7+ #1457 SMP Tue Sep 28 11:25:31 BST 2021 armv7l GNU/Linux

Subsystem

at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16)

What steps will reproduce the bug?

This is a raspberry pi node.js api http server mainly proxied to from nginx http/2 server front ending Chrome browser clients.

There are a few internal processes running on the raspberry pi that are also nodejs based using the http connector directly.

the actual fault printed in the logs is

 Error: write EPROTO C0BAF076:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:
 
     at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) {
   errno: -71,
   code: 'EPROTO',
   syscall: 'write'
 }

the process that fails also makes calls to a sqlserver database using the tedious connection to another machine. So I don't know if this an incoming our outgoing connection fail

How often does it reproduce? Is there a required condition?

This is a production system which was upgraded to 18.12.1 last night (from 16.17.0) and has been running all day with the normal 5 or 6 users. The first time it failed was midday today, but then but since about 3:20 this afternoon until now about every 20 minutes.

What is the expected behavior?

no failures

What do you see instead?

The information given above in the logs.

Additional information

No response

[Trott]

That would seem to be a message coming from OpenSSL. Do you know if you're node binary has OpenSSL bundled or if it is using your system OpenSSL?

[akc42]

@Trott I haven't specifically linked it, I use nvm and I just did an nvm install v18.12.1 on the raspberry pi to install node. I then set that version as the default. For now I have reverted to v16.17.0 (although I see that needs updating).

The raspberry pi is running Debian stable and hasn't been updated for a while. openssl is installed

[targos]

It's possible that running Node.js with --openssl-legacy-provider fixes this.

[afbpinheiro]

I'm having the same problem, also after upgrading from node v16.15.1 to v18.12.1.
Sadly @targos solution doesn't work.

Here's a small snippet so anyone reproduce the problem:

https.get('https://scsanctions.un.org', (res) => {
    console.log(res);
}).on('error', (err) => {
    console.log(err);
});

[targos]

@afbpinheiro thanks for the small reproduction. /cc @nodejs/crypto I confirm that it starts failing with Node.js 17 and --openssl-legacy-provider doesn't make it work.

[arhart]

Is this expected behavior? a scan reports for scsanctions.un.org "There is no support for secure renegotiation." and "This server supports TLS 1.1. Grade capped to B."

[arhart]

Possibly related workaround to disable the security check: https://stackoverflow.com/a/72245418

[afbpinheiro]

@arhart, genuinely asking: why should this be expected behavior?

[bnoordhuis]

Because it's unsafe. It essentially allows a man-in-the-middle attacker to hijack HTTPS sessions. The option to enable it is called SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION for a reason.

[afbpinheiro]

@bnoordhuis I know it's unsafe and I know why it's unsafe, I just don't understand why throwing an error in those situations could be considered the default behavior. Therefore my question.

[bnoordhuis]

What else would you have it do? Quietly do the unsafe thing anyway?

[afbpinheiro]

There are multiple possibilites:

1. Keep the same behavior as pre-v17 versions, the "quietly do the unsafe thing anyway" option
2. Emit a warning stating the possible consequences of the connection but do it anyway
3. Throw an error explaining the possible consequences and have a flag so the user can decide to do it anyway

Each option has its own trade-offs and I don't have the knowledge to weight their advantages and disadvantages.
I just don't see how throwing an error and make the user find a workaround because node won't make the request can be considered default behavior.

In my use case, I use node to connect to third parties, from which I don't have authority to decide how to manage the security of their website. I can't do much more than request them to do it.
From node's side, I can just downgrade the version as a workaround, sure. But I think the current (possible default) behavior is just not ok.

[targos]

You can opt into the insecure behavior by passing secureOptions: crypto.constants.SSL_OP_LEGACY_SERVER_CONNECT in the options for your connection.