diff options
author | Nick Hudson <nick.hudson@isode.com> | 2013-08-12 14:12:41 (GMT) |
---|---|---|
committer | Nick Hudson <nick.hudson@isode.com> | 2013-09-02 16:19:08 (GMT) |
commit | d10646423d70934b598b5d8ff2d8910034941029 (patch) | |
tree | 982621f5c98459fb477e753f0a1589817df8d258 /.gitignore | |
parent | 34e195e8e2db1de0b71460afcce2417d34fc7717 (diff) | |
download | stroke-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 '.gitignore')
0 files changed, 0 insertions, 0 deletions