Node 11.9+ Exception on openssl digital envelope routines cipher parameter evp_lib.c #27213
Comments
|
When you say "crashes" you mean it throws an exception rather than abort the process outright? Do you have an easy way to reproduce? What does the |
|
Hmm? Line 170 in events.js at throw er has er in it is message stack and Symbol kEpandStackSymbol expands with: So nothing found like you asked for. Going up the stack 'this' is a TLSSocket nothing called opensslErrorStack there either. This is normal just a particular state? I am using the npm websocket library would be a step to reproduce. |
MasterJames
changed the title
MasterJames
changed the title
|
How can I reproduce that 'cipher parameter error' exception that you mention? New enough v11.x releases attach that UNABLE_TO_GET_ISSUER_CERT means Node.js cannot verify the peer's TLS certificate because one or more certificates in its certificate chain are untrusted (e.g., unknown or self-signed CA.) |
To be exceedingly clear, they attach it to the Error object that is thrown (not the TLSSocket). This would likely be easy to figure out if you posted a standalone reprodution. Without it, I'm not even clear from the bug report if this is a client or a server that is throwing. Are you sure this is v11.13.0? The first tls file:line ref in the report is to |
|
Okay thanks for the responses I will do my best to try and help get to the bottom of this. It fails first on the 'server' side as describe. Yes subsequently there's a problem on the browser side but it's a module load time type error as the server is frozen on the EventEmitter.prototype.emit = function emit( I only mentioned the TLSSocket as I searched for opensslErrorStack in 'er' and it it is not there? If I ask JSON.stringify(er) I get an empty object {} opening the err in the Scope inspector under Block is Console trace after error displayed as I think the message UNABLE_TO_GET_ISSUER_CERT I foolishly mentioned is just a distraction because I didn't attach a client key. I would like to try distilling 2 years work in an example but it's server code I am unaware of any fiddle for that. If there is a way let me know but I really doubt I will be able to upload code that is reproducible. Maybe I need a suggestion or an example of how to use sockets without this npm package 'websockets' as I guess your recent changes since 11.8 are no longer working with it I'm supposing. Maybe this is a good question to ask? If I look further into 'er' there is proto within proto but no opensslErrorStack to be found after extensive searching. I can inspect that Symbol and it shows er["Symbol(kExpandStackSymbol)"] is a function but executing it fails and it's otherwise undefined so I guess it's crashed at that point. As I move up the stack the next item is line 481 in domain.js see next post ... |
|
JSON.stringify(this) minus data buffers 'this' is the TLSSocket Not that this would be much help I'm just showing you what information is available next in the stack trace. from the doc you referenced https://nodejs.org/docs/v11.14.0/api/errors.html#errors_class_error
|
|
Newly released Version 12 of nodejs also not working. |
It is the node src, download and untar it, or look on github, the exact file path is in your question. Between 11.8 and 11.9, OpenSSL was updated from 1.1.0 to 1.1.1a, you could look at the openssl changelog to see the differences, though I'd be surprised if it was illuminating. You don't have a reproduction we can run, and I'm not really clear on your situation. Server is node, using the websocket package. Client is a browser? Using websockets from where? And this happens during websocket connection? Or https? Or after connection, during data exchange? Also, the error message suggests problems verifying a peer cert, so are you doing client auth, that is, the client has a cert? I'd suggest trying to strip this down. I appreciate that your app is likely large, but building a tiny server that offers a websocket connection, and then seeing if it has the same problem when your browser client connects would be the first step in problem isolation. The second would be replacing the browser with a node client. Somewhere along there, you might get a working system, at which point you could ask yourself how its different from your large system where its not working. Or, if your system doesn't work, you will end up with a repro we can run. #27376 would probably help diagnose this, but it hasn't landed yet, much less gotten released. |
|
Thanks for the input Sam. My Ubuntu version shows it's openssl version is OpenSSL 1.1.0g 2 Nov 2017 |
This should not be relevant. node has its own builtin version of openssl, check that version with |
|
-p process.version is showing the same as --version either 10.8 works or anything after that with the internal openssl 1.1.1 does not. |
|
I managed to get Ubuntu 19 working despite a major fault with running BIND locally and some new netplan using 127.0.0.53 instead of 127.0.0.1 etc. (but that's another story). Anyway I have also got the latest version of nodejs via 'n' so 12.2.0 is also not working and more importantly the openssl version has nothing to do with this problem, which remains. |
|
A trace with |
|
Oh okay cool --trace-tls seems like a helpful thing thanks for the input. It sure reveals all kinds of extra output. Here is the bit before the error... I have moved to Ubuntu 19.04 despite various issues with that in progress version. One being updated to openssl 1.1.1b which I've done on this Ubuntu 18 as well. It seems like I should switch to the internal TLS tools and dump turtle's websocket library, so it's a breaking change that was inevitable I suppose. I think it might be something to do with the particular cipher and as it is complicated to get all the bit's and pieces working together hard to track down what breaks when other then it crashes on a version change. I believe this is what it is using in this case cipher_suite {0x13, 0x02} TLS_AES_256_GCM_SHA384 |
|
I've tried without success to use 'tls' sockets to repair this issue and as of node 12.3.1 this is still not working.
Based on the output from the new trace-tls flag it would seem TLS 1.3 is not being negotiated, but the same keys can make a 'tls' connection with 1.3 it's just the socket is nothing like how 'https' works. See here for that attempt... |
|
Still errors in 12.10 |
|
Just tried 13.1.0 and unfortunately it still errors in this way. |
|
Same problem in 13.3.0
|
|
I believe I've asked about it before but how can I reproduce (easily)? A small test case using only builtin modules is preferred; anything that depends on 100s or 1,000s of lines of third-party code is unlikely to get looked at. |
|
Hi I was just checking what's happening here. It still has not been magically fixed. Just tested versions 12.16.3 and 14.2.0 with the same results. I can say I am using this npm websocket package and thought maybe that is part of the problem. |
jasnell
added
the
help wanted
|
Seeing there's been no follow-up in almost two years, can I suggest we close this issue? |
Version: 11.13 crashes but in 11.8 it works (fails/waiting since 11.9)
Platform: Linux 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Subsystem: ../deps/openssl/openssl/crypto/evp/evp_lib.c:81
Error:
error:060CC07A:digital envelope routines:EVP_CIPHER_asn1_to_param:cipher parameter error:../deps/openssl/openssl/crypto/evp/evp_lib.c:81It is a pretty cryptic error (ha ha no pun intended).
I guess it has to do with openssl encryption maybe there is something else I should update.
I pass some encrypted stuff over a socket to nodejs from Chrome and get this error message above, while in node 11.8 there is no problem.
This is via SSL only, and might be related to elliptic encryption.
Unrelated to node execution the keys are generated this way.
openssl ecparam -genkey -name secp384r1 -out server-key.pembut it connects okay initially I guess it is more to do with sending over the socket.
The text was updated successfully, but these errors were encountered: