I'm getting EPROTO errors on Node 8 and above
test.js
var https = require('https');
var fs = require('fs');
console.log('Node', process.version);
var writeStream = fs.createWriteStream('test.html');
writeStream.on('finish', function () {
console.log('Finish');
})
https.get('https://handbrake.fr/nightly.php', function (res) {
res.pipe(writeStream);
});
$ node test.js
Node v4.8.7
Finish
$ node test.js
Node v5.12.0
Finish
$ node test.js
Node v6.13.1
Finish
$ node test.js
Node v7.10.1
Finish
$ node test.js
Node v8.10.0
events.js:183
throw er; // Unhandled 'error' event
^
Error: write EPROTO 101057795:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:openssl\ssl\s23_clnt.c:802:
at _errnoException (util.js:1022:11)
at WriteWrap.afterWrite [as oncomplete] (net.js:880:14)
$ node test.js
Node v9.8.0
events.js:165
throw er; // Unhandled 'error' event
^
Error: write EPROTO 101057795:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:openssl\ssl\s23_clnt.c:802:
at WriteWrap.afterWrite [as oncomplete] (net.js:841:14)
Emitted 'error' event at:
at TLSSocket.socketErrorListener (_http_client.js:394:9)
at TLSSocket.emit (events.js:180:13)
at onwriteError (_stream_writable.js:427:12)
at onwrite (_stream_writable.js:449:5)
at _destroy (internal/streams/destroy.js:39:7)
at TLSSocket.Socket._destroy (net.js:545:3)
at TLSSocket.destroy (internal/streams/destroy.js:32:8)
at WriteWrap.afterWrite [as oncomplete] (net.js:843:10)
Version: 4-9 (arch. 64-bit) (listed in console log above)
Platform: Windows 10 (64-bit)
Note: handbrake.fr
has A+ grade SSL (ref)
Looks like this was introduced somewhere between v8.5.0 and v8.6.0.
Also, this doesn’t appear to reproduce on master
for me?
@addaleax Yeah it works in v10
$ node-nightly test.js
Node v10.0.0-nightly20180314040dd244de
Finish
git bisect points to: https://github.com/nodejs/node/pull/15206
/cc @rogaps @jasnell @bnoordhuis @tniessen
And reverse git bisect says that the fix for this on master
is af78840b194528a147e4683aed27a320f9764ea5 (#16853), which was labelled semver-major
.
I am not sure in what way that is actually a breaking change.
The semver label on the fix can be reduced. I think it was purely
defensive...
On Mar 14, 2018 17:47, "Anna Henningsen" notifications@github.com wrote:
And reverse git bisect says that the fix for this on master is af78840
https://github.com/nodejs/node/commit/af78840b194528a147e4683aed27a320f9764ea5
(#16853 https://github.com/nodejs/node/pull/16853), which was labelled
semver-major.I am not sure in what way that is actually a breaking change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/node/issues/19359#issuecomment-373185822, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2ef4B_zn0sV1gIS0jpKRArkqoQABzks5teY_bgaJpZM4SrLds
.
This happens because of mismatched ecdhCurves. Before the fix, node uses prime256v1 as default. This is the related issue #16196
I'll close this out because it's essentially a duplicate of #16196 but thank you for writing up a good bug report. If anyone has ideas on what direction to take, please chime in on that issue.
I try this.
_NODE_TLS_REJECT_UNAUTHORIZED=0 yarn install_
and my issue is solved.
No, you just swapped one issue for another. NODE_TLS_REJECT_UNAUTHORIZED=0
turns off TLS certificate validation; it's no better than unencrypted HTTP in terms of security.
If anyone is having this issue in Gridsome just FYI that it probably has something to do with your gridsome.server.js file.
Default file should look something like this:
// Server API makes it possible to hook into various parts of Gridsome
// on server-side and add custom data to the GraphQL data layer.
// Learn more: https://gridsome.org/docs/server-api/
// Changes here require a server restart.
// To restart press CTRL + C in terminal and run gridsome develop
module.exports = function (api) {
api.loadSource(({ addCollection }) => {
// Use the Data Store API here: https://gridsome.org/docs/data-store-api/
})
api.createPages(({ createPage }) => {
// Use the Pages API here: https://gridsome.org/docs/pages-api/
})
}
Most helpful comment
No, you just swapped one issue for another.
NODE_TLS_REJECT_UNAUTHORIZED=0
turns off TLS certificate validation; it's no better than unencrypted HTTP in terms of security.