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

PR-URL: https://github.com/nodejs/node/pull/25997
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit is contained in:
Sam Roberts 2019-02-07 13:27:14 -08:00 committed by Daniel Bevenius
parent 006e78cecb
commit 666beb0421
2 changed files with 3 additions and 2 deletions

View File

@ -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());

View File

@ -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