Unexpected EOF handling

[Tomas Mraz]

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.

The existing legacy way does not really prevent applications from
detecting the truncation attack because the condition is reported to
the application albeit in this legacy undocumented way. So changing the
default to mean - never report the unclean EOF condition at all, simply
return as if the shutdown was clean, would actually mean a security
issue for these existing applications that care about the unclean EOF.

So yes, perhaps it would be better for the SSL_OP to actually fully
ignore the unclean EOF instead of returning this undocumented error
condition, but it must not be a default (not even in SSL_OP_ALL).

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]