Re: Memoryleak in SSL.Connection

On Thu, 15 Apr 2004 08:48:04 +0800
Ng Pheng Siong <[email protected]> wrote:

> On Wed, Apr 14, 2004 at 11:21:17AM +0200, Andre Reitz wrote:
> >  calling
> >     set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN)
> >  before destructor __del__ comes
> >  stops my multi-threaded server from hanging.
> >
> >  if I do not call
> >     set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN)
> >  the complete server sometimes hangs in
> >    m2.bio_free(self.sslbio)  of Connection.__del__
> >
> > Why?
> >   does bio_free still want to communicate with the client?
> >   (which is already disconnected?)
> 
> M2Crypto's bio_free calls OpenSSL API BIO_free calls OpenSSL internal
> ssl_free calls OpenSSL API SSL_shutdown and others.
> 
> SSL_shutdown tears down the SSL connection, including handling the closure
> alert messages I mentioned in the earlier post.
> 
> The statement set_shutdown(...) tells OpenSSL to not send nor wait for the
> closure alerts.
> 
> The alerts are actually a security feature that defends against *truncation
> attacks*.
> 
> I've been thinking of creating, say, classes SSL.SContext and
> SSL.SConnection that presents a simpler API, with more defaults and fewer
> methods.
> 
> OTOH, I'm reluctant to hide any security feature that inconveniences the
> app programmer under the hood because I think that's saying, "Trust me,
> I've figured this out and have decided for you what you need to know."
> 
> Trust me you can ;-) but decide for yourself you should.
> 
> What does the list think?
> 

Well I think that M2Crypto is ok as it is.

The only change I would make is:
add: 
  set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN)
to 
  Connection.__del__

(If the application-Programmer doesn't call close() or shutdown() 
 in a correct way)

I think that if the __del__ method gets called, and the connection
isn't really already "shutdown" the worst thing that could happen,
is that __del__ doesn't succeed in any case.

My approach would be to regard the __del__ method as some kind of
a "disconnect which always succeeds without problems or errors"-method.


Greetings, Andre'

> --
> Ng Pheng Siong <[email protected]>
> 
> http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
> http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers


-- 
__________________________________________________________________________

Als Technologieunternehmen konzipieren und entwickeln wir maßgeschneiderte Feedback- und
Monitoring-Systeme - wie beispielsweise Lösungen für Beschwerde- und Ideenmanagement.
Mit dem Inquery® Survey Server bieten wir eine der leistungsfähigsten Standardlösungen für
Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an.
__________________________________________________________________________


Inworks GmbH
Andre Reitz, Leiter Entwicklung
Hörvelsinger Weg 39, 89081 Ulm, Germany
Tel +49 (0) 731 / 93807-21
Fax +49(0)731/93807-18
Internet: http://www.inworks.de