Unexpected EOF handling

[Kurt Roeckx]

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