Re: [Jessie-discuss] Bug when closing stream

[Martin Egholm Nielsen]

Hi Casey,

> > > > I just encountered a problem in Jessie when a SSLSocket was closed:
> > > >
> > > > Exception in thread "KeepAlive cleaner"   
> > > > java.lang.ArrayIndexOutOfBoundsException
> > > >     at 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...
> > > 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.
> > 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