Re: [Jessie-discuss] Bug when closing stream

[Casey Marshall]

On Jun 29, 2005, at 12:05 AM, Martin Egholm Nielsen wrote:


> 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...

Yes, you can forcibly close the underlying TCP socket. The JSSE API  
lets you wrap an existing socket with an SSL layer, and you can close  
that socket if you need to.