[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@winehq.org Reporter: cflwxa@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&softwar...) 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.
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #1 from iLOveBugs cflwxa@knowledgemd.com --- Created attachment 72728 --> https://bugs.winehq.org/attachment.cgi?id=72728 minimal patch proposal (requires GnuTLS 3.6.3)
https://bugs.winehq.org/show_bug.cgi?id=53344
iLOveBugs cflwxa@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)
https://bugs.winehq.org/show_bug.cgi?id=53344
iLOveBugs cflwxa@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) |
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #2 from iLOveBugs cflwxa@knowledgemd.com --- Created attachment 72729 --> https://bugs.winehq.org/attachment.cgi?id=72729 minimal patch proposal (requires GnuTLS 3.6.3), untested
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #3 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53344
iLOveBugs cflwxa@knowledgemd.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #72729|0 |1 is obsolete| |
--- Comment #4 from iLOveBugs cflwxa@knowledgemd.com --- Created attachment 72731 --> https://bugs.winehq.org/attachment.cgi?id=72731 minimal patch proposal (requires GnuTLS 3.6.3), untested
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #5 from iLOveBugs cflwxa@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".
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- (In reply to iLOveBugs from comment #5)
With patch:
- 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.
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #7 from iLOveBugs cflwxa@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.
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #8 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #9 from Hans Leidekker hans@meelstraat.net --- Created attachment 72736 --> https://bugs.winehq.org/attachment.cgi?id=72736 patch
Does this work for you?
https://bugs.winehq.org/show_bug.cgi?id=53344
--- Comment #10 from iLOveBugs cflwxa@knowledgemd.com --- Yes, that looks good, thank you very much. I also realized my last patch was nonsense, after getting enough sleep.
https://bugs.winehq.org/show_bug.cgi?id=53344
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |a0febe909780189fa2441635484 | |cb592b9ab64b5 Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Hans Leidekker hans@meelstraat.net --- Fix committed as a0febe909780189fa2441635484cb592b9ab64b5.
https://bugs.winehq.org/show_bug.cgi?id=53344
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.13.
-
WineHQ Bugzilla