Unexpected EOF handling

[Kurt Roeckx]

On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > 
> > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > 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?
> > 
> > This is an excellent summary of the current situation.
> > 
> > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> > long term solution. It's a very confusing API for new applications to
> > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > 
> > That said I also recognise that it is apparently commonplace to shut
> > down a TLS connection without sending close_notify - despite what the
> > standards may say about it (and TBH we can hardly claim the moral
> > high
> > ground here since s_server does exactly this - or at least it does in
> > 1.1.1 and did until very recently in master).
> > 
> > But we do have to consider usages beyond HTTPS. I have no idea if
> > this
> > occurs in other settings or not.
> > 
> > Perhaps what we need is an option for "strict shutdown". With strict
> > shutdown "off" we could treat EOF as if we had received a
> > close_notify
> > gracefully (and don't invalidate the session). Presumably existing
> > code
> > would be able to cope with that???
> 
> Yes, existing code would be able to cope with that with one important
> exception that I am going to talk about below.
> 
> > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > master).
> > 
> > I'm not sure though what the default should be.
> 
> In case we go with this solution, which would be acceptable I think, we
> MUST NOT EVER make it the default because existing applications that
> depend on the existing way how the unclean EOF condition is returned
> might actually depend on it to detect the truncation attack.

I agree that we should not return SSL_ERROR_ZERO_RETURN by default
on an unexpected EOF.

If the default behaviour should be to make it a non-fatal error,
like the old behaviour is, I would really prefer a different
error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.

So I think the suggestion is to have this:
- By default, SSL_ERROR_SSL is returned with
  SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
  marked invalid.
- With an option, SSL_ERROR_ZERO_RETURN is returned, the session
  will stay valid.


Kurt