On Wed, Sep 5, 2018 at 9:40 AM Robert DiFalco <robert.difalco@gmail.com> wrote:
Is the timeout the only way to handle this kind of TLS handshake error?
It might be easier to answer your original question if you include a Short, Self Contained, Correct (Compilable), Example <http://sscce.org/>. Jean-Paul
Sent from my iPhone
On Aug 30, 2018, at 10:14 AM, Robert DiFalco <robert.difalco@gmail.com> wrote:
I'm having an issue properly handling TLS failure modes. For example consider the EchoServer and EchoClient code. If I use a TLS client with a TCP4 server, I do not get a handshake exception until I abort the connection. But I don't want to abort the connection unless I get a handshake error.
What I'd like to do is to check the handshake status in my protocol before my client sends bytes to the server. I'd like my send message to be able to raise the <class 'OpenSSL.SSL.Error'>: [('SSL routines', 'ssl23_read', 'ssl handshake failure'). But for some reason it seems to get lost until I abort the connection. Does this sound familiar to anyone?
What I've done for now is setup a Timeout mixin so that after my client.send, if I do not get an ACK back (which my particular protocol does) within two minutes, I just abort the connection. This then calls connectionLost with the correct SSL.Error. But if it's in the error queue (and found during the course of abortConnection then isn't there a way to find it sooner? Like before my timeout and before I call send on the client protocol?
Thanks!
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python