RE: SSL alert number 10 after quite exactly 1MB transfered
Let me try one more time to explain the problem with an unrealistic, but I hope easy to follow, example. Consider:
A <-> B
Now, imagine A sends a message to B requesting some unit of data. B begins sending a very, very large chunk of data to A, many tens of MB. After 10 MB or so, A realizes this is not what it expected, so it sends an "abort/close" command to B. A then waits for B to close the connection in response to the abort/close command. B is multi-threaded, always trying to both receive and send concurrently, so it detects the "abort" command and stops sending.
There is no way this can deadlock. Whenever A sends the abort/close, B will get it. B never waits for A to receive anything before it receives itself.
Now, interpose your proxy:
A <-> proxy <-> B
Now, A sends the message to B requesting the data. B starts blasting the data to the proxy, which you blast to A. Now, A stops receiving the data and sends the "abort/close" command. But what happens? Your proxy will not read from A until it finishes sending the data it received from B. But A will not call 'read', it is waiting for the connection to close.
So your proxy will wait forever trying to send to A, when it could make forward progress by receiving from A, sending to B, and then handling the connection close.
So your proxy breaks a protocol that was unbreakable without the proxy.
This is the easiest to understand breakage. It is not the only way you can introduct breakage. A proxy must not ever say "I will not do X until I can do Y" when being able to do Y requires someone else doing something. Assuming the protocol you are proxying worked in the first place, it was deadlock free. But if you introduce additional ordering dependencies (without knowing the existing ones) you can introduce deadlocks.
In general, most protocols require a "you must not refuse to receive just because you cannot send" rule because this is the rule TCP itself provides. Your proxy violates this rule because it uses blocking sends when it has no idea whether a receive from that same endpoint would succeed.
OpenSSL Project [url]http://www.openssl.org[/url]
User Support Mailing List [email]firstname.lastname@example.org[/email]
Automated List Manager [email]email@example.com[/email]