[Bug 53344] New: Legacy TLS applications: GnuTLS priority string overrides are ignored in schan_create_session() (patch included)
https://bugs.winehq.org/show_bug.cgi?id=53344 Bug ID: 53344 Summary: Legacy TLS applications: GnuTLS priority string overrides are ignored in schan_create_session() (patch included) Product: Wine Version: 7.12 Hardware: x86-64 URL: https://support.hpe.com/connect/s/softwaredetails?lang uage=en_US&softwareId=MTX_bc8e3ffa59904ec3b505d9964d OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs(a)winehq.org Reporter: cflwxa(a)knowledgemd.com Distribution: Debian Created attachment 72727 --> https://bugs.winehq.org/attachment.cgi?id=72727 trace+secur32,warn+secur32 and GNUTLS_DEBUG_LEVEL=11 I use Wine devel 7.12 from the winehq repos and winetricks 20220411 from github. Context: I am trying to run the "HPE Lights-Out Standalone Remote Console" (HPLOCONS.exe, https://support.hpe.com/connect/s/softwaredetails?language=en_US&softwareId=...) to connect to an iLO 3 interface of an HP ProLiant server. iLO 3 only supports legacy ciphers (3DES, RC4). Because the Wine schannel implementation uses GnuTLS, I added an override config like so: sudo mkdir -p /etc/gnutls sudo tee /etc/gnutls/config_hplocons <<EOF [overrides] default-priority-string = NORMAL:+3DES-CBC:+ARCFOUR-128 EOF Then I set up a wine prefix like so: env WINEARCH=win32 WINEPREFIX=~/.local/share/wineprefixes/hplocons wineboot --init env WINEARCH=win32 WINEPREFIX=~/.local/share/wineprefixes/hplocons winetricks -q dotnet471 d3dcompiler_47 corefonts fontfix winver= wget https://downloads.hpe.com/pub/softlib2/software1/pubsw-windows/p390407056/v1... env WINEARCH=win32 WINEPREFIX=~/.local/share/wineprefixes/hplocons wine Setup.exe And successfully run HPLOCONS: env WINEARCH=win32 WINEPREFIX=~/.local/share/wineprefixes/hplocons WINEDEBUG=trace+secur32,warn+secur32 GNUTLS_SYSTEM_PRIORITY_FILE=/etc/gnutls/config_hplocons GNUTLS_DEBUG_LEVEL=11 LC_ALL=C wine start 'C:\Program Files\Hewlett Packard Enterprise\HPE iLO Integrated Remote Console\HPLOCONS.exe' When trying to connect to iLO, I get "The request was aborted: Could not create SSL/TLS secure channel." The trace logs and gnutls debug logs (attached) show that schan_create_session() in dlls\secur32\schannel_gnutls.c ignores my priority string override and instead, uses "NORMAL" without TLS 1.3 ciphersuites. A look at the source code confirms that schan_create_session() does indeed not incorporate the system defaults. Also note that process_attach() sets GNUTLS_SYSTEM_PRIORITY_FILE to "/dev/null" if it was unset, which has the consequence that everything in the default /etc/gnutls/config file is always ignored. I further confirmed that this is a Wine issue by running gnutls-cli: # Succeeds env GNUTLS_SYSTEM_PRIORITY_FILE=/etc/gnutls/config_hplocons gnutls-cli --insecure <iLO-IP> # Fails with "Received alert [40]: Handshake failed" gnutls-cli --insecure <iLO-IP> To be able to run legacy applications, I think Wine should respect GnuTLS overrides. I attached an untested patch proposal. Note that this patch does not change behaviour if the default priority string is "NORMAL". Also note that Wine would require gnutls 3.6.3 due to the use of gnutls_set_default_priority_append(). Perhaps check_supported_protocols() should also be patched in a similar way. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #1 from iLOveBugs <cflwxa(a)knowledgemd.com> --- Created attachment 72728 --> https://bugs.winehq.org/attachment.cgi?id=72728 minimal patch proposal (requires GnuTLS 3.6.3) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 iLOveBugs <cflwxa(a)knowledgemd.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Legacy TLS applications: |HPLOCONS (legacy TLS |GnuTLS priority string |applications): GnuTLS |overrides are ignored in |priority string overrides |schan_create_session() |are ignored in |(patch included) |schan_create_session() | |(patch included) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 iLOveBugs <cflwxa(a)knowledgemd.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #72728|0 |1 is obsolete| | Attachment #72728|minimal patch proposal |please delete description|(requires GnuTLS 3.6.3) | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #2 from iLOveBugs <cflwxa(a)knowledgemd.com> --- Created attachment 72729 --> https://bugs.winehq.org/attachment.cgi?id=72729 minimal patch proposal (requires GnuTLS 3.6.3), untested -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- We need the protocols to match the expectations of Windows applications. The reason we set GNUTLS_SYSTEM_PRIORITY_FILE to /dev/null is that some distributions started disabling versions below 1.2 which broke some apps. Why do you need to remove "NORMAL" from the priority string? Please use diff -up to generate patches. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 iLOveBugs <cflwxa(a)knowledgemd.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #72729|0 |1 is obsolete| | --- Comment #4 from iLOveBugs <cflwxa(a)knowledgemd.com> --- Created attachment 72731 --> https://bugs.winehq.org/attachment.cgi?id=72731 minimal patch proposal (requires GnuTLS 3.6.3), untested -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #5 from iLOveBugs <cflwxa(a)knowledgemd.com> --- The current behaviour is that the priority string is constructed in the "priority" variable and then set in the session. My patch initializes the priority string in the session object "s" with the system's default priority string (which the user can override with GNUTLS_SYSTEM_PRIORITY_FILE), which always starts with a keyword like NORMAL. Then instead of using "priority" to set the session priority, "priority" is appended. Before: 1. priority is initialized with "NORMAL:%LATEST_RECORD_VERSION" 2. ":-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0" is appended to priority 3. session priority is set to priority 4. Result: "NORMAL:%LATEST_RECORD_VERSION:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0" With patch: 1. priority is initialized with "%LATEST_RECORD_VERSION" (not a valid priority string anymore, maybe name it priority_append instead?) 2. system default priority string is prepended to session priority (the default is "NORMAL", set by "--with-default-priority-string" during compilation or overridden by GNUTLS_SYSTEM_PRIORITY_FILE at runtime) 3. ":-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0" is appended to priority 4. priority is appended to session priority (gnutls_set_default_priority_append adds leading ":") 5. Result: "<system default priority string>:%LATEST_RECORD_VERSION:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0" The reason I do it like this is that there is no getter function gnutls_get_default_priority and I tried to interact with GnuTLS in a stable way. I have attached a new patch made with "diff -up". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #6 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to iLOveBugs from comment #5)
With patch: 1. priority is initialized with "%LATEST_RECORD_VERSION" (not a valid priority string anymore, maybe name it priority_append instead?) 2. system default priority string is prepended to session priority (the default is "NORMAL", set by "--with-default-priority-string" during compilation or overridden by GNUTLS_SYSTEM_PRIORITY_FILE at runtime) 3. ":-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0" is appended to priority 4. priority is appended to session priority (gnutls_set_default_priority_append adds leading ":") 5. Result: "<system default priority string>:%LATEST_RECORD_VERSION:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS- TLS1.0"
The reason I do it like this is that there is no getter function gnutls_get_default_priority and I tried to interact with GnuTLS in a stable way.
The downside is that this make it less predictable which priority is used because distributions may choose to change the default through --with-default-priority-string. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #7 from iLOveBugs <cflwxa(a)knowledgemd.com> --- Created attachment 72734 --> https://bugs.winehq.org/attachment.cgi?id=72734 alternative patch proposal, untested How about this then? Just override the priority string if the user specified a manual override via GNUTLS_SYSTEM_PRIORITY_FILE. Otherwise, leave the existing code logic as is. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #8 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to iLOveBugs from comment #7)
Created attachment 72734 [details] alternative patch proposal, untested
How about this then? Just override the priority string if the user specified a manual override via GNUTLS_SYSTEM_PRIORITY_FILE. Otherwise, leave the existing code logic as is.
Yes, that's better. I would make env_str a global variable however so we don't need to query it twice. You can't concatenate to env_str like that but why would you? I think it would be better to expect the override to specify the full priority string. The user may want %COMPAT instead of %LATEST_RECORD_VERSION for example. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- Created attachment 72736 --> https://bugs.winehq.org/attachment.cgi?id=72736 patch Does this work for you? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 --- Comment #10 from iLOveBugs <cflwxa(a)knowledgemd.com> --- Yes, that looks good, thank you very much. I also realized my last patch was nonsense, after getting enough sleep. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |a0febe909780189fa2441635484 | |cb592b9ab64b5 Status|UNCONFIRMED |RESOLVED --- Comment #11 from Hans Leidekker <hans(a)meelstraat.net> --- Fix committed as a0febe909780189fa2441635484cb592b9ab64b5. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53344 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.13. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla