<div dir="ltr"><div dir="ltr">Dear Tomas,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 2:07 PM Tomas Mraz <<a href="mailto:tmraz@redhat.com">tmraz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:<br>
> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:<br>
> > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:<br>
> > > On 07/05/2020 12:22, Kurt Roeckx wrote:<br>
> > > > So I think we need at least to agree on:<br>
> > > > - Do we want an option that makes the unexpected EOF either a<br>
> > > > fatal<br>
> > > >   error or a non-fatal error?<br>
> > > > - Which error should we return?<br>
> > > <br>
> > > This is an excellent summary of the current situation.<br>
> > > <br>
> > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno<br>
> > > as a<br>
> > > long term solution. It's a very confusing API for new<br>
> > > applications to<br>
> > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error -<br>
> > > except<br>
> > > when its not. SSL_ERROR_SYSCALL should mean fatal error.<br>
> > > <br>
> > > That said I also recognise that it is apparently commonplace to<br>
> > > shut<br>
> > > down a TLS connection without sending close_notify - despite what<br>
> > > the<br>
> > > standards may say about it (and TBH we can hardly claim the moral<br>
> > > high<br>
> > > ground here since s_server does exactly this - or at least it<br>
> > > does in<br>
> > > 1.1.1 and did until very recently in master).<br>
> > > <br>
> > > But we do have to consider usages beyond HTTPS. I have no idea if<br>
> > > this<br>
> > > occurs in other settings or not.<br>
> > > <br>
> > > Perhaps what we need is an option for "strict shutdown". With<br>
> > > strict<br>
> > > shutdown "off" we could treat EOF as if we had received a<br>
> > > close_notify<br>
> > > gracefully (and don't invalidate the session). Presumably<br>
> > > existing<br>
> > > code<br>
> > > would be able to cope with that???<br>
> > <br>
> > Yes, existing code would be able to cope with that with one<br>
> > important<br>
> > exception that I am going to talk about below.<br>
> > <br>
> > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in<br>
> > > master).<br>
> > > <br>
> > > I'm not sure though what the default should be.<br>
> > <br>
> > In case we go with this solution, which would be acceptable I<br>
> > think, we<br>
> > MUST NOT EVER make it the default because existing applications<br>
> > that<br>
> > depend on the existing way how the unclean EOF condition is<br>
> > returned<br>
> > might actually depend on it to detect the truncation attack.<br>
> <br>
> I agree that we should not return SSL_ERROR_ZERO_RETURN by default<br>
> on an unexpected EOF.<br>
> <br>
> If the default behaviour should be to make it a non-fatal error,<br>
> like the old behaviour is, I would really prefer a different<br>
> error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.<br>
> <br>
> So I think the suggestion is to have this:<br>
> - By default, SSL_ERROR_SSL is returned with<br>
>   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be<br>
>   marked invalid.<br>
> - With an option, SSL_ERROR_ZERO_RETURN is returned, the session<br>
>   will stay valid.<br>
<br>
+1<br>
<br>
And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF.<br>
<br>
Dmitry, I think this solution should be working well for nginx and<br>
similar http related applications. They just need to use the<br>
SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly<br>
terminate the TLS session will just appear as if they properly<br>
terminated it.<br></blockquote><div><br></div><div>I'm not sure this is the best possible solution because it makes the application developers doing extra compile-time checks.</div><div><br></div><div>But anyway, is it a final decision and the patch can be amended or we are waiting for objections some more time?</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>