Dear Kurt On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx <k...@roeckx.be> 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. > If I remember correctly, session resumption is a way to significantly reduce a server's workload. So I think that by default (and maybe the only option) we should prefer the old behaviour. -- SY, Dmitry Belyavsky