SSL_read()=0 passthrough is not good

[markokr]

I see you have changed tls_read/tls_write to let 0 passthrough without checks. But is it really smart thing to do?

I remember some SSL2-era security problem caused by inability to differentiate between tcp abort and peer-requested shutdown. Currently 0 from tls_read says it was proper shutdown. Seems now you are changing it to "either it was shut down or we just lost tcp connection". I suppose its possible to check tls_close() error to see if something was off, but it does not seem like improvement.

[4a6f656c]

The intention is to make tls_read(3)/tls_write(3) follow as closely as possible to the semantics of read(2)/write(2). This means that they should return 0 on EOF - the challenge is that with read(2)/write(2) you would then go and check errno in order to see if the EOF was unexpected. In this case, I think we just need to ensure that tls_close() can indicate the difference between EOF with close-notify and unexpected EOF without close-notify. The application then gets to decide if that is a problem or not.

[markokr]

Unexpected EOF of underlying transport should not be "end of data" but EIO, where read() also returns -1.

Zero should be reserved only for successful EOF.

[markokr]

I have been convinced current behaviour is more practical.

Closing.