Hi, We introduced a change in the 1.1.1e release that changed how we handled an unexpected EOF. This broke various software which resulted in the release of 1.1.1f that reverted that change. In master we still have the 1.1.1e behaviour.
The change itself is small, it just calls SSLfatal() with a new error code. This has at least 2 effects: - The error code was changed from SSL_ERROR_SYSCALL with errno 0 to SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING - The session is marked as in error, and so can't be used to resume. There is code written that now checks for the SSL_ERROR_SYSCALL with errno 0 case, while we never documented that behaviour. The 1.1.1 manpage of SSL_get_error() currently reports this as a bug and that it will change to SSL_ERROR_SSL / SSL_R_UNEXPECTED_EOF_WHILE_READING. Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall in at least 2 categories: - Ignore the error - Check for the error, for instance in a test suite Not sending the close notify alert is a violation of the TLS specifications, but there is software out there doesn't send it, so there is a need to be able to deal with peers that don't send it. When the close notify alert wasn't received, but we did get an EOF, there are 2 cases: - It's a fatal error, the protocol needs the close notify alert to prevent a truncation attack - The protocol running on top of SSL can detect a truncation attack itself, and does so. It doesn't need the close notify alert. It's not a fatal error. They just want to check that that is what happened. The problem is that we can't make a distiction between the 2 cases, so the only thing we can do currently is to look at it as a fatal error. So the documentation was changed to say that if you're in the 2nd cases, and need to talk to a peer that doesn't send the close notify alert, you should not wait for the close notify alert, so that you don't get an error. The alternative is that we add an option that does tell us if we should look at it as a fatal error or not. There is at least a request that we keep returning the old error code (SSL_ERROR_SYSCALL with errno 0). I think that from an API point of view this is very confusing. We'd then have SSL_ERROR_SYSCALL as documented that it's fatal, except when errno is 0. If errno is 0, it can either be fatal or not, and we're not telling you which one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL with errno 0 is always the unexpected EOF, we returned that combination because of a bug in OpenSSL. So I think we need at least to agree on: - Do we want an option that makes the unexpected EOF either a fatal error or a non-fatal error? - Which error should we return? Kurt