-
Notifications
You must be signed in to change notification settings - Fork 15.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Socket hang up" with Electron 4 (and greater) when contacting Microsoft IIS #18557
Comments
Electron 4 uses BoringSSL instead of OpenSSL in Node.js (it always used BoringSSL when connecting from Chromium; the only change is that now Node.js uses it too). BoringSSL is generally less forgiving than OpenSSL, and generally aims not to support configurations that are known to be insecure (such as SSLv3). It seems like your IIS server is misconfigured. I'm closing this because I don't believe there's anything to be fixed in Electron related to this, but do let me know what you find and we can reopen if we do uncover an issue we can address. |
Thanks a lot for the clarification @nornagon! I'll try to get in contact with the admins and check whether they can change the configuration. |
@nornagon, there is just one strange thing: When I'm using Chrome version 74 (currently the latest one), I'm getting the correct response from that URL! Chrome (which obviously has BoringSSL inside) is answering that strange package which I mentioned above (and which causes the "Socket hang up" in Electron), with an own "Encrypted Handshake" message. So could it be that there is a difference (e.g. compile options) how BoringSSL is compiled for NodeJS when building Electron (compared to how it is compiled for Chrome)? |
Hm, I doubt it'd be a compilation issue. Do you see the same behaviour when you try accessing the server through web content in Electron 4? Node and Chromium in Electron both use the same BoringSSL module. The code you posted uses the |
I can confirm that when using this code:
it works correctly. I did this test with Electron 4. |
I also checked the Wireshark trace and indeed that strange "Encrypted Handshake" package from the sever is answered by Chromium with an own "Encrypted Handshake" package. So there must be a difference how BoringSSL is used for Chromium and for NodeJS in Electron 4. |
Yep, when using node.js's API, BoringSSL will be invoked slightly differently. If it works for you, you could try using Electron's net module, which uses Chromium's networking stack instead of Node's. Unfortunately it's hard for me to tell what the issue might be without a repro I can run locally, but do let me know what you uncover—it's definitely possible there's a bug in the way that Node is calling BoringSSL! |
Unfortunately the net module does not work correctly with port 447. With port 443 everything works well, but when I'm calling the URL mentioned on top which contacts port 447, I'm not getting a response. Looks like the "response" event is not fired in this case. And in turn this code is not triggered:
Also:
is not triggered. Nevertheless I can see a successful negotiation and data exchange sequence on Wireshark. Also I see that in this case (as expected) that packet #41 is answered by the BoringSSL stack. |
Ah, that does seem like a bug in the |
Thank you for this thread. It was indeed very helpful. I too was hit by this issue pretty badly. Tried a number of solutions but unfortunately nothing worked. Even using I did come up with a workaround so I thought I would share it here. It would require Basically I wrote a JS file which uses Here's my request processor JS file looks like:
and this is how I call it from my Electron App:
As mentioned above, only catch here is that node must be installed on the target machine which is what I specified in the I hope somebody will find this workaround useful hence thought of sharing it. |
Expected Behavior
When sending this request from the main process I should receive a SOAP response (port 447 is intended and not a typo!):
Actual behavior
When running the request with Electron versions greater or equal 4.0.0 I'm getting "Socket hang up".
To Reproduce
Put the code above in the main process and run it with Electron 4.
Additional Information
When running the request above natively in Node 10.11.0 or in Electron 3.x.x everything works fine. Since Electron 4 has Node 10.11.0 inside as well I wouldn't have expected any difference. But Node 10.11.0 behaves differently in Electron 4 compared to running it natively. E.g. in Electron 4 Node 10.11.0 offers a lot less ciphers for TLS negotiation compared to original Node 10.11.0.
Another thing which I found is that IIS for some reason sends another "Encrypted Handshake Message" (see packet #41 in attached electron4.pcap in Wireshark.zip), after the session was already successfully established. Looks like this is something Node in Electron 4 does not like. As you can see in electron3.pcap there is such package as well (#91). But in this case Node answers with package #92.
Not sure if I'm right, but after searching a lot through the web, my impression is that in Electron 4, Node is no longer compiled with OpenSSL, but instead with Google's BoringSSL library. This could explain the differing behavior.
In fact there are two questions.
Why is IIS sending an additional TLS-Finish ("Encrypted Handshake") Message? I didn't see this on any other server. I'll try to get more information from them, whether this potentially is some miss-configuration.
Why is Electron 4 / Node reacting differently now?
The text was updated successfully, but these errors were encountered: