|
From: | Martin Egholm Nielsen |
Subject: | Re: [Jessie-discuss] Bug when closing stream |
Date: | Wed, 29 Jun 2005 09:05:06 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 |
Hi Casey,
I would guess that it is indeed a concurrency problem. GNU Crypto's CBC mode is not thread-safe, and I have usually taken the approach that synchronization is up to the code using the library, not the library itself, mostly to avoid performance hits in single-threaded applications.I just encountered a problem in Jessie when a SSLSocket was closed:Exception in thread "KeepAlive cleaner" java.lang.ArrayIndexOutOfBoundsExceptionat java.lang.System.arraycopy(Native Method) at gnu.crypto.mode.CBC.decryptBlock(CBC.java:131) at gnu.crypto.mode.BaseMode.update(BaseMode.java:125)at org.metastatic.jessie.provider.SecurityParameters.decrypt (Unknown Source) at org.metastatic.jessie.provider.RecordInput.readRecord (Unknown Source) at org.metastatic.jessie.provider.RecordInput.pollClose (Unknown Source)at org.metastatic.jessie.provider.SSLSocket.close(Unknown Source) at Acme.Serve.Serve$KeepAliveCleaner.run(Serve.java:1471)All that "my" thread really does, is to try to close the ssl- socket when left unused for some time... It may be a concurrency problem - the socket being closed in the same time as someone is trying to actually use it - since it's a keep-alive connection...Well, there there it is then :-)However, it's not trivial to make it thread safe, because one thread may be "caught" in a blocking read-operation, hence the mutex may be locked forever without the second thread ever having a chance...
Well, you would have that problem still, if GNU Crypto's CBC mode were thread safe: CBC is a stateful mode, and closing an SSL socket requires sending a "close notify" message, so you cannot use a socket and close it simultaneously.
But then there is no way to kick an ongoing client connection? E.g. to prevent DoS... // Martin
[Prev in Thread] | Current Thread | [Next in Thread] |