summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNick Hudson <nick.hudson@isode.com>2013-08-12 14:12:41 (GMT)
committerNick Hudson <nick.hudson@isode.com>2013-09-02 16:19:08 (GMT)
commitd10646423d70934b598b5d8ff2d8910034941029 (patch)
tree982621f5c98459fb477e753f0a1589817df8d258 /Makefile
parent34e195e8e2db1de0b71460afcce2417d34fc7717 (diff)
downloadstroke-d10646423d70934b598b5d8ff2d8910034941029.zip
stroke-d10646423d70934b598b5d8ff2d8910034941029.tar.bz2
Changes to handle close notify gracefully
It was noticed that in certain cases, Stroke got stuck when connecting to a server over TLS, and the server closed down the connection. Investigation showed that this appears to be caused by the JSSEContext code not properly coping with a "close notify" SSL message. What happens in this case is that the SSLEngine generates a response to the server's "close notify", and expects this to be sent back over the network. The original JSSEContext code saw the "CLOSED" status from the SSLEngine.unwrap(), but assumed that no more data would be generated by the engine (which was wrong, because the engine wants to send a close response back), and so got stuck in a loop. This patch therefore fixes the JSSEContext code to deal properly when it sees a CLOSED from unwrap. After the close has been received, an error will be emitted by JSSEContext so that the application knows that the SSLEngine can no longer be used (in practice we have always seen the socket closing, which generates its own error to the application, but it was recommended that we should have this check in case a server sends a close notify and does NOT close the socket as well). It appears that many servers don't actually send the "close notify", and just drop the connection, which is (presumably) why we'd not seen this behaviour before. Test-information: Tested by connecting to the aforementioned server. This time, when the connection times out (and the closenotify is sent), we no longer see a loop, but the application realises what's happens and attempts to reconnect. I have been running with this patch in my copy of MLC for two weeks and have noticed no difference in behaviour - so far as I can tell the code is not exercised when talking to M-Link but at any rate the patch isn't causing anything to break. Change-Id: Id007c923c510ef1b4ce53192105b00296c65c757
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions