half-duplex SSL/TLS

[ry]

Currently 'close notify' is sent and then the connection is terminated. should allow for various methods of shutting down SSL

• force close - terminate the TCP without any 'close notify'
• one sided 'close notify' followed by FIN
• 'close notify' on one side, wait for 'close notify' on the other, then TCP shutdown.

(is that it?)

https://github.com/ry/node/blob/97f7c0645118ffb3844fec67345ad0ae7e71f6a9/lib/tls.js#L289-291

[timmattison]

I have been scratching my head all night as to why this doesn't work. I'm looking for the third behavior you listed for a reverse proxy with clients that use half-open SSL/TLS connections.

It looks like the code ignores the allowHalfOpen and httpAllowHalfOpen options. The only place where allowHalfOpen is checked is in lib/net.js in the _onReadable function when bytesRead is zero. The only place where httpAllowHalfOpen is checked is in lib/http.js in the socket.onend callback in the connectionListener function.

It looks like lib/tls.js has no way of seeing the allow half open values so when it decides that SecurePair should be destroyed (_destroy function) or the CryptoStream has ended (end function) it marks readable and writable false and closes down show. Being new to node I'm not sure how to patch this. Any idea if this is on the roadmap somewhere? I'd like to help to get this working but after several hours going over the code it looks like it's going to take me a while.

[strags]

The current server-side behavior seems wrong as well. It seems to me that SSL_shutdown() ought to mirror the semantics of a TCP shutdown(). However, on observing a SSL_RECEIVED_SHUTDOWN, as far as I can tell, nothing really happens, apart from a flag (receivedShutdown) being set (which is not referenced anywhere else). (Interestingly, setting this flag overrides the receivedShutdown() method in the corresponding object's prototype - bizarre).

It should probably dispatch an 'end' event, or close the connection, depending on allowHalfOpen.

[daviddias]

@ry can you confirm if this is still an issue? If so, some examples would be great, thank you.

[indutny]

I think it is fixed during a couple of last rewrites.

[scunningham]

It seems this may have regressed. Sending and alert close followed by a half-close causes the node.js server to shut the socket down immediately without sending a response. Perhaps here?

https://github.com/joyent/node/blob/master/src/tls_wrap.cc#L468

[indutny]

@scunningham is it happening for a server created with tls.createServer()? The EOF practically should not cause socket to die without explicit actions. The https/http module does close socket on EOF, though, but this is configurable with allowHalfOpen option.

[scunningham]

@indutny Problem occurs against the following code. It's easy to see by running the sample code, executing the following:

openssl s_client -msg -connect localhost:8000

terminating with control-D, then watching in Wireshark. You'll see the client send the Close Alert, followed by a FIN. The server will ACK then FIN, then immediately send a FIN of its own, omitting the Close Alert response.

var https = require('https');
var fs = require('fs');

var options = {
cert: fs.readFileSync('/tmp/cert.pem'),
key: fs.readFileSync('/tmp/key.pem')
};
https.createServer(options, function (req, res) {
res.writeHead(200);
res.end("hello world\n");
}).listen(8000);

[scunningham]

Sorry about the font.

[indutny]

As I said about the http/http, the allowHalfOpen option should fix it. The same thing would happen if you will use http server and connect to server via netcat.

[scunningham]

Perhaps you can help me figure out how to set "allowHalfOpen:true" on the a
tlsServer? Passing it through options doesn't seem to do anything.
Manually hacking it doesn't seem to change behavior; if the client drops
the connection, the servers sends FIN immediately.
...

var server = tls.createServer(options, function (s) {
console.log("server connected: " + s.allowHalfOpen);
s.allowHalfOpen = true;
s.server.allowHalfOpen = true;
...

I did notice different behavior going the other direction, ie. when the
server forces the connection down against a client that has allowHalfOpen
set to true. In this case, asking the server to close the connection
causes node.js to send an immediate FIN without sending a CLOSE ALERT
first. The connection stays open, and some time later when the agent calls
.end(), a FIN packet is sent also without a CLOSE ALERT. See code below:

Aside from being unexpected behavior, node.js not gracefully closing a TLS
connection can lead to truncation attacks (see
http://en.wikipedia.org/wiki/Transport_Layer_Security#Truncation_attack and
corresponding paper by Smyth and Pironti). By default, the connections
should attempt to close gracefully without any special
tweaking/configuration required by implementor.

---

var tls = require('tls');
var fs = require('fs');

var options = {
cert: fs.readFileSync('/tmp/cert.pem'),
key: fs.readFileSync('/tmp/key.pem'),
};

var server = tls.createServer(options, function (s) {
console.log("server connected: " + s.allowHalfOpen);

s.end();

s.on('end', function () {
    console.log("server finished.");
});

}).listen(8000);

var coptions = {
host: 'localhost',
port: 8000,
rejectUnauthorized: false,
allowHalfOpen: true
};

var client = tls.connect(coptions, function () {
client.allowHalfOpen = true;
console.log("client connected: " + client.allowHalfOpen);

// wait a couple seconds, then close down our end
setTimeout(function() {
    client.end();
}, 5000);

});

client.on('finish', function() {
console.log("client finished.");
});

On Tue, Jul 15, 2014 at 10:02 PM, Fedor Indutny notifications@github.com
wrote:

As I said about the http/http, the allowHalfOpen option should fix it.
The same thing would happen if you will use http server and connect to
server via netcat.

—
Reply to this email directly or view it on GitHub
#626 (comment).

[indutny]

Oh, actually... I see what you mean. Sorry!

Basically, this is a won't fix in v0.10, but it will work just fine in v0.12 and does already work in v0.11. Please give it a try ;)

[scunningham]

<<
Basically, this is a won't fix in v0.10, but it will work just fine in
v0.12 and does already work in v0.11. Please give it a try ;)

Thanks for you response.

Tried it against v0.11.13 and not working. The above sample code, in
particular, the code in which the server closes the ssl connection on
connect, does not send the appropriate CLOSE alert as described.

Sean

On Wed, Jul 23, 2014 at 9:11 PM, Fedor Indutny notifications@github.com
wrote:

Oh, actually... I see what you mean. Sorry!

Basically, this is a won't fix in v0.10, but it will work just fine in
v0.12 and does already work in v0.11. Please give it a try ;)

—
Reply to this email directly or view it on GitHub
#626 (comment).

[scunningham]

Attached is a pcap which shows the above code running against v0.11.13.
Highlights:

Packet #

11. the SSL handshake is complete
12. client ACK's the server's final handshake packet
13. the server sends a FIN. Note there was no close_notify sent from the
    server.
14. After 5 seconds, the client sends a FIN packet to close connection.
    Notice no close_notify from the client.
15. Server ACK's the client's FIN. Connection is closed.

On Thu, Jul 24, 2014 at 4:55 PM, Sean Cunningham cunningham.sean@gmail.com
wrote:

<<
Basically, this is a won't fix in v0.10, but it will work just fine in
v0.12 and does already work in v0.11. Please give it a try ;)

Thanks for you response.

Tried it against v0.11.13 and not working. The above sample code, in
particular, the code in which the server closes the ssl connection on
connect, does not send the appropriate CLOSE alert as described.

Sean

On Wed, Jul 23, 2014 at 9:11 PM, Fedor Indutny notifications@github.com
wrote:

Oh, actually... I see what you mean. Sorry!

Basically, this is a won't fix in v0.10, but it will work just fine in
v0.12 and does already work in v0.11. Please give it a try ;)

—
Reply to this email directly or view it on GitHub
#626 (comment).

[indutny]

Yeah, I'll figure it out...