Unexpected EOF handling
tmraz at redhat.com
Mon May 11 11:07:30 UTC 2020
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.
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
No matter how far down the wrong road you've gone, turn back.
[You'll know whether the road is wrong if you carefully listen to your
More information about the openssl-project