From: Hans Leidekker Subject: Re: [PATCH 4/5] secur32: Perform TLS handshake even if input is empty. Message-Id: <3b88c914ba04a4064b782a874cf3606111d5905a.camel@codeweavers.com> Date: Wed, 17 Feb 2021 14:50:02 +0100 In-Reply-To: <6bc572ee-e05c-d6ee-6c8e-c241e129de8c@codeweavers.com> References: <20210215114723.3898056-4-rbernon@codeweavers.com> <78456e41-4993-2d6a-6151-1d78bba111ff@codeweavers.com> <522e1621781981d6b23f69be961ecf728d1c99a8.camel@codeweavers.com> <6bc572ee-e05c-d6ee-6c8e-c241e129de8c@codeweavers.com> 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: > > > > > > SSLVerifyClient require > > > > > > > > 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.