On 15 Aug, 04:49 pm, kgeo...@tcpsoft.com wrote: >I've noticed some behavior when negotiating TLS using startTLS(). I'm >starting TLS on both sides of the connection at the same time to >validate >peer certificates using a custom callback. If I call startTLS() >without >any subsequent writes to the socket the negotiation never completes. >However, if I write data immediately post startTLS() the negotiation >(and >the callback to the OpenSSL verify callback) is successful. But I >don't >want to do this because I want to wait until verification to proceed >with >communicating on the channel. So I traced through tcp.py and noticed >that >in Connection.startTLS() reads and writes are stopped while the >negotiation is taking place. However, only reading is reenabled >afterwards. I suppose this is why doing a write unblocks the >connection. >When I do something like this in my code I don't have to make a write: > >self.transport.startTLS(SSLContextFactory(...)) >self.transport.startWriting() > >The context factory makes its own SSL.Context very similar to >_sslverify, >but with a callback I can hook for verification. > >So the question is, why is reading reenabled but not writing? When I >apply the patch below it works.
This sounds like a real bug. Probably it came from a naive copying of some TCP code which doesn't have to do the initial writing that is necessary for SSL. Can you file a ticket? Jean-Paul _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
