[Twisted-Python] Problems with TLS connection not shutting down.

Michael Williamson williamson.michaelr at gmail.com
Thu Mar 28 18:55:15 EDT 2013

Ah, I never tried abortConnection, but I'm doing something similar - I just
call loseConnection() and that does the trick.  And yes, I believe that the
TCP connection does stay alive because I was watching closeSocket() and it
was never called.

I wish I could be more helpful with regard to code samples to reproduce
this - but right now my stuff is a mess.

We're using the wokkel library, calling stopService() when we want
everything to be cleaned up.  They override that function, but I believe
they're doing everything correctly.  Basically, they're just calling
connection.disconnect() - and eventually the shutdownTLS() gets invoked.

Maybe most people just never care about having to clean up their
connections during a single session?  As for a fix - maybe it's not
necessary to do the test for
if shutdownSuccess in _shutdownTLS() ?

According to the ssl spec, it's not absolutely necessary to wait for the
server to return the close handshake.

That being said, that seems lousy - and it really seems like something else
must be going on.

On Thu, Mar 28, 2013 at 4:36 PM, Glyph <glyph at twistedmatrix.com> wrote:

> On Mar 28, 2013, at 9:24 AM, Michael Williamson <
> williamson.michaelr at gmail.com> wrote:
> > Hi, I'm having an issue where a tls connection never seems to shutdown
> properly, and as a result, all the associated cleanup never happens.
> >
> > Basically we're trying to implement a jabber client and allow the user
> to sign out and then re-sign back in without completely quitting the
> program.  When the user tries to sign back in, Twisted goes nuts because
> the original connection was never shutdown properly.
> >
> > So, I traced through the code with the debugger and I came to the
> _shutdownTLS() function in tls.py.  I believe that what's supposed to
> happen is that the first time through, the self._tlsConnection.shutdown()
> returns False because the shutdown is initiated.  Then, when the 2nd part
> of the shutdown handshake comes back from the server, dataReceived is
> called, which calls shutdownTLS again, and then the cleanup can continue.
> >
> > The problem is that after the initial call to shutdownTLS, I never see
> anymore data from the server.  I'm not sure if it's a server issue (we're
> just connecting to the Google jabber servers) where they don't close down
> their SSL connections correctly, or if I'm just doing something silly.  So
> anyway, I could solve this by overriding a bunch of stuff and ensuring that
> self.transport.loseConnection() gets called no matter what, even when the
> server doesn't respond with the second part of the close handshake, but I
> figured I'd ask here first.
> >
> > So, any TLS experts out there?  Thanks for any help or information - I
> really appreciate it,
> Sadly I don't know enough about TLS specifics to tell you for sure.
> It sounds like you may have spotted a bug.  More investigation is required
> though.  Does .abortConnection() do what you expect?  In your current
> problematic scenario, does the TCP connection to your peer stay alive?
> -glyph
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20130328/c0ad483e/attachment.htm 

More information about the Twisted-Python mailing list