Unexpected EOF handling

[Dmitry Belyavsky]

Dear Tomas,

On Mon, May 11, 2020 at 2:07 PM Tomas Mraz <tmraz at redhat.com> wrote:

> On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:
> > 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.
>
> +1
>
> And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF.
>
> Dmitry, I think this solution should be working well for nginx and
> similar http related applications. They just need to use the
> SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly
> terminate the TLS session will just appear as if they properly
> terminated it.
>

I'm not sure this is the best possible solution because it makes the
application developers doing extra compile-time checks.

But anyway, is it a final decision and the patch can be amended or we are
waiting for objections some more time?

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200511/a49e811f/attachment.html>