From c8ced8e784cc95f5f74e48476c5fbe24f6efe127 Mon Sep 17 00:00:00 2001 From: Sam Roberts Date: Thu, 7 Feb 2019 13:27:14 -0800 Subject: [PATCH] tls: renegotiate should take care of its own state In the initial version of this test there were two zero-length writes to force tls state to cycle. The second is not necessary, at least not now, but the first was. The renegotiate() API should ensure that packet exchange takes place, not its users, so move the zero-length write into tls. See: https://github.com/nodejs/node/pull/14239 See: https://github.com/nodejs/node/commit/b1909d3a70f9 --- lib/_tls_wrap.js | 3 +++ test/parallel/test-tls-disable-renegotiation.js | 2 -- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/_tls_wrap.js b/lib/_tls_wrap.js index 79b9c6d3951a2f..483c380cb83237 100644 --- a/lib/_tls_wrap.js +++ b/lib/_tls_wrap.js @@ -621,6 +621,9 @@ TLSSocket.prototype.renegotiate = function(options, callback) { this._requestCert = requestCert; this._rejectUnauthorized = rejectUnauthorized; } + // Ensure that we'll cycle through internal openssl's state + this.write(''); + if (!this._handle.renegotiate()) { if (callback) { process.nextTick(callback, new ERR_TLS_RENEGOTIATE()); diff --git a/test/parallel/test-tls-disable-renegotiation.js b/test/parallel/test-tls-disable-renegotiation.js index da492713a0742a..13e08112e596d6 100644 --- a/test/parallel/test-tls-disable-renegotiation.js +++ b/test/parallel/test-tls-disable-renegotiation.js @@ -46,7 +46,6 @@ server.listen(0, common.mustCall(() => { port }; const client = tls.connect(options, common.mustCall(() => { - client.write(''); common.expectsError(() => client.renegotiate(), { code: 'ERR_INVALID_ARG_TYPE', @@ -78,7 +77,6 @@ server.listen(0, common.mustCall(() => { // data event on the server. After that data // is received, disableRenegotiation is called. client.write('data', common.mustCall(() => { - client.write(''); // This second renegotiation attempt should fail // and the callback should never be invoked. The // server will simply drop the connection after