On Thu Jun 29 19:08:39 2023 +0000, Hans Leidekker wrote:
In any case, this has nothing to do with client certificate as the
returned ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED error in the code seems to suggest. That may be true for Gears 5 but the winhttp tests show that renegotiate can also be initiated because the server wants to authenticate the client. ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED should be returned to the app in that case to allow it to supply a certificate. I believe in other cases renegotiate should be handled transparently like in your patches, but it's not clear to me how to distinguish them. Note that this is also discussed in bug https://bugs.winehq.org/show_bug.cgi?id=55105
Ah yeah I remember now that you mentioned that detail in the past. Then it doesn't look obvious from the secur32 API either how to decide between the TLS re-handshake and a renegotiation because of a missing certificate.
Writing a similar test against the game servers, the same call sequence seems to both satisfy test.winehq.org and the game server, as in: they both succeed a second InitializeSecurityContextA call sequence (even if I remove the part that adds a client certificate from the WineHQ test).
There's a visible difference in the content of the stream header / tail buffers returned by DecryptMessage, especially on Windows (not so much different on Wine, but still a bit), but I don't know if we can interpret this data somehow.
There's also a difference on Windows where the second InitializeSecurityContextA sequence completes with SEC_E_OK for the WineHQ test, and with SEC_E_INCOMPLETE_MESSAGE for the game server (which I understand meaning that the HTTP request should continue). It may be meaningless though, it's just a quick and dirty test.