On 2020-11-11 18:12, william@welliver.org wrote:
Hi all-
Just wanted to provide an update on this:
I've tracked down the root of the problem, and it's more concerning than I originally realized, so I'll restate the problem in terms of what I now know to be happening (verified in 8.0.702 and 8.0/HEAD:
If you create an SSLFile object and set the object to non-blocking mode before handshaking completes, any alert messages will cause the following to occur:
1. state of the connect to be set to local_fail 2. the close callbacks on the user side will be called 3. the outbound connection will be left open 4. no alert messages will actually be sent (though they are queued internally)
The pike end user will not be aware that the network connection is still open, and further, the connection cannot be closed through the SSLFile api, as the internal state indicates the connection is already closed. The connected peer will remain connected until they (hopefully) time out. I have mostly been concerned with server mode SSLFile, but I suspect the client behavior would be similar.
Critically, everything works happily with the SSLFile set to non-blocking mode before accept() is called, so long as no alerts are generated during the handshake. It's possible that a race condition could enable this even if the order is switched. I am working around the problem by waiting to set the connection non-blocking in the accept callback.
My initial statement-of-problem suggested that the cause was limited to configuration error, but I now think the reality is that a denial of service situation could be caused by a client that advertised cipher preferences unsupported by the pike SSL peer.
Ultimately, I think the proper solution is above my pay grade, but I have verified that the alert message makes it into the alert queue, and that the write callback on the stream is set, but never gets called. I believe this is the source of the problem.
Any thoughts or suggestions are welcome!
Bill