0

I had a tcp proxy in python the version is 2.6.

It works fine in any cases with following logic client ---> proxy ---> server

I wrapped the tcp with tls from proxy to server. client ---> proxy ==++ssl++==> server

That works fine in some cases and fails in others.

The error is that the server is waiting for more information from the client, but client sends nothing more. At the 26th round trip.(Certainly, the round trip number of successful case also larger than 26.)

I cannot tell more about the detail but I thought the SSL should be transparent to the logic. Any Idea that part of the functionality fails? How should I debug it?

Edit: In python 2.6, the tls version can only be 1.0.

templefox
  • 475
  • 1
  • 5
  • 17

1 Answers1

1

It is hard to tell what you are doing without any example demonstrating the problem but depending on how your application works SSL/TLS is not just a transparent replacement for TCP sockets. While it might be transparent in most cases if you use only blocking sockets it gets different with non-blocking I/O. In this case you have to deal with user space buffering where select will not report available data even thought there are unread data. You also have to deal with situations where you temporarily fail to write because the TLS stack needs a read first or the other way.

For more details about differences with non-blocking I/O and select see Behavior of python's select() with partial recv() on SSL socket or select and ssl in python. Additionally non-blocking I/O needs special handling with accept and connect too but I doubt that there is useful support for it in the old python version you are using.

Community
  • 1
  • 1
Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • I think you nearly get the answer. The I/O is no-blocking with select, the tcp proxy itself is intercept. Could you offer more detail about **user space buffering**? Does it mean I need to **flush** it somehow? – templefox Nov 18 '16 at 09:51