https://bugs.winehq.org/show_bug.cgi?id=46161
Bug ID: 46161 Summary: Wine: Wrong GnuTLS usage? Product: Wine Version: 3.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jaapbuurman@gmail.com Distribution: ---
I am using Wine from WineHQ's official repository to run World of Warcraft. I use the Twitch client to keep my addons updated. On my desktop PC that is running Arch with GnuTLS 3.5.19 this is working fine. However, on my Laptop running Ubuntu 18.10 (Fresh install) with GnuTLS 3.6.4 it is unable to find and sync my addons. When I start the Twitch client from the terminal, the log is being spammed with the following messages:
GnuTLS error: A packet with illegal or unsupported version was received.
Said errors are missing when I do the same to run Twitch on my Arch Desktop PC and it syncs just fine.
I first assumed this was a GnuTLS bug and opened an issue there, but one of the developers recommended to open a bug here since according to him it looked like a Wine bug instead.
Issue tracker at GnuTLS: https://gitlab.com/gnutls/gnutls/issues/621
I quote:
I suspect something is wrong in wine. The application via wine seems to advertise TLS1.3 and TLS1.0, and that confuses the server who selects TLS1.2 (advertising protocols which are not continuous is quite risky, as we see from the server's behavior):
gnutls[2]: Advertizing version 3.4 gnutls[2]: Advertizing version 3.1
My high level understanding of the wine code is that it allows an application to specifically remove some versions of TLS and keep some others, however it is not ready for TLS1.3. That's the reason the application you use ends up advertising TLS1.3 and TLS1.0, although probably the intention was to only have TLS1.0 there. Seeing wine's schan_imp_create_session it did not anticipate a new protocol being added to the list. I suggest opening an issue at the wine issue tracker.
I think they need to either add support for TLS1.3 if schannel has it, or remove all enabled versions using -VERS-ALL before adding one explicitly selected by the application. It is a long shot though, as I do not claim to fully comprehend the code.
https://bugs.winehq.org/show_bug.cgi?id=46161
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcel@meulemans.org
--- Comment #1 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 46167 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=46161
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |secur32 CC| |o.dierick@piezo-forte.be
https://bugs.winehq.org/show_bug.cgi?id=46161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46161
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #2 from Jacek Caban jacek@codeweavers.com --- Created attachment 62817 --> https://bugs.winehq.org/attachment.cgi?id=62817 WIP
Thanks for the report. The attached patch should help (it's not really tested, my gnutls doesn't support TLS 1.3 yet). Please give it a try.
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #3 from jaapbuurman@gmail.com --- Thank you very much for the patch! Unfortunately, I will only be able to try the patch and compile Wine this weekend. If anyone is up for testing out the patch before that, that would be very welcome :)
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #4 from Hans Leidekker hans@meelstraat.net --- Created attachment 62828 --> https://bugs.winehq.org/attachment.cgi?id=62828 trace
Here's a +secur32 trace from running this command with the patch applied:
$ wine iexplore https://tls13.crypto.mozilla.org
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #5 from Jacek Caban jacek@codeweavers.com --- Thanks for logs. For TLS 1.3 to be used, we'd need to add to protocol_config_keys in schannel.c as well. I tried that, but for some reason, the connection fails. It needs a closer look.
Also it seems that TLS 1.3 is not yet supported on Windows. PSDK has defines for it ready, but there doesn't seem to be the actual implementation. Still, we could have it, perhaps disabled by default...
However, I think that the original bug was about TLS 1.3 being used when it shouldn't be. That's because our gnutls backend doesn't disable it when it should. This part should work with the attached patch (I will attach a new version, because includes part is in Wine already).
https://bugs.winehq.org/show_bug.cgi?id=46161
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62817|0 |1 is obsolete| |
--- Comment #6 from Jacek Caban jacek@codeweavers.com --- Created attachment 62841 --> https://bugs.winehq.org/attachment.cgi?id=62841 WIP
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #7 from Marcel marcel@meulemans.org --- For me Jacek's patch did not work because TLS 1.3 is still negotiated due to it being part of the "NORMAL" priority string being passed to gnutls_priority_set_direct() in schan_imp_create_session(). I got it work correctly with TLS 1.3 enabled servers (not https://tls13.crypto.mozilla.org which support ONLY TLS 1.3) by removing protocols supported by gnutls but no by wine in the priority string passed to gnutls_priority_set_direct. See attached patch.
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #8 from Marcel marcel@meulemans.org --- Created attachment 62844 --> https://bugs.winehq.org/attachment.cgi?id=62844 Removes protocols not supported by wine code
The remove protocols not supported by wine code. Not the most elegant way, but it illustrates the idea.
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #9 from jaapbuurman@gmail.com --- Is there anything I can do at the moment to help fix this issue? :)
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #10 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to jaapbuurman from comment #9)
Is there anything I can do at the moment to help fix this issue? :)
If you can compile wine, you may try the patch from comment #6 with/without the patch from comment #8 and comment if any combination fixes the issue for you.
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #11 from Jacek Caban jacek@codeweavers.com --- (In reply to Marcel from comment #7)
For me Jacek's patch did not work because TLS 1.3 is still negotiated due to it being part of the "NORMAL" priority string being passed to gnutls_priority_set_direct() in schan_imp_create_session(). I got it work correctly with TLS 1.3 enabled servers (not https://tls13.crypto.mozilla.org which support ONLY TLS 1.3) by removing protocols supported by gnutls but no by wine in the priority string passed to gnutls_priority_set_direct. See attached patch.
With my patch, we should pass -VERS-TLS1.3, so it shouldn't be a problem that it's part of NORMAL. Is it not passed for some reason?
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #12 from Marcel marcel@meulemans.org --- Created attachment 62952 --> https://bugs.winehq.org/attachment.cgi?id=62952 Easier removing protocols not supported by wine code
(In reply to Jacek Caban from comment #11)
With my patch, we should pass -VERS-TLS1.3, so it shouldn't be a problem that it's part of NORMAL. Is it not passed for some reason?
I think you missed the same fix in "schan_imp_create_session" which still advertises TLS1.3 via NORMAL. And I misread your solution and came up with some overly complex code (see new patch).
Also I think you may have missed the header file with the define for SP_PROT_TLS1_2_CLIENT?
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #13 from Jacek Caban jacek@codeweavers.com --- Not really, note that as long as the code in schannel.c is not aware of TLS1.3 (and I tested that although TLS1.3 is defined in headers, Windows doesn't support it so I'm not sure we want to), it will never be actually enabled. My patch made only gnutls backend aware of TLS1.3, which meant in practice that it would be always disabled, so we'd always append -VERS-TLS1.3 to the priority string.
Headers are already in Git: https://source.winehq.org/git/wine.git/commitdiff/40c847d8074770681d1c6434fd...
I took another look at this and sent a simpler patch: https://source.winehq.org/patches/data/155698
https://bugs.winehq.org/show_bug.cgi?id=46161
--- Comment #14 from Marcel marcel@meulemans.org --- Indeed, just tried the latest master (which includes your latest patch) and it works like a charm. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=46161
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |5cc5b102c1b0a66aa63b66f43f2 | |da9a1a9d15ab6
--- Comment #15 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Marcel from comment #14)
Indeed, just tried the latest master (which includes your latest patch) and it works like a charm. Thanks!
Marking fixed then. Thanks for reporting back.
https://bugs.winehq.org/show_bug.cgi?id=46161
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc1.
-
wine-bugs＠winehq.org