[PATCH 4/5] secur32: Perform TLS handshake even if input is empty.

[Hans Leidekker]

On Wed, 2021-02-17 at 12:23 +0100, Rémi Bernon wrote:
> On 2/15/21 3:32 PM, Hans Leidekker wrote:
> > On Mon, 2021-02-15 at 13:26 +0100, Rémi Bernon wrote:
> > > On 2/15/21 1:22 PM, Marvin wrote:
> > > > === debiant2 (64 bit WoW report) ===
> > > > 
> > > > secur32:
> > > > schannel.c:818: Test failed: Output buffer size changed.
> > > > schannel.c:833: Test failed: Output buffer size changed.
> > > > schannel.c:842: Test failed: Output buffer size changed.
> > > > schannel: Timeout
> > > > 
> > > 
> > > I guess that speaks for itself, but I'm still interested to discuss how
> > > to properly test the re-handshake, if there are ways.
> > 
> > We could set up a test on test.winehq.org. Apache docs suggest that
> > changing SSL parameters trigger a re-handshake. Maybe something like
> > this will work:
> > 
> > <Directory clientcert>
> > SSLVerifyClient require
> > </Directory>
> > 
> > 
> 
> I don't really know much about Apache configuration, but isn't this 
> going to require a client certificate, which we don't have? Is it going 
> to fail but after the re-handshake (which would allow us to test it)?

It's supposed to fail with ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED, after
which the client should set the cert context with 
WinHttpSetOption(WINHTTP_OPTION_CLIENT_CERT_CONTEXT) and try again. I think
that's an interesting test case too.

We could send a self-signed certificate, which of course makes the re-handshake
fail. If we really need the re-handshake to succeed 'optional_no_ca' instead of
'require' may help. I'll see if I can make this work.