Recherche zu dem Befehl "GNUTLS_SYSTEM_PRIORITY_FILE"
Zunächst einmal vielen Dank an @Stefan193 und @hbciuser für den intensiven Austausch zu diesem Thema. Ich muss zugeben, dass ich manchmal nur Bahnhof verstanden habe, weil ich nicht vom Fach bin.
Bei meiner Rechereche bin ich darauf gestoßen, wie dieser Befehl "GNUTLS_SYSTEM_PRIORITY_FILE" es zum Einzug in Wine geschafft hat.
Um 2020 haben manche Linux-Distributionen begonnen, alte und unsichere Algorithmen zu deaktivieren. Zum Beispiel können die systemweiten Krypto-Richtlinien von Fedora TLS 1.0 und 1.1 deaktivieren und die Kompatibilität mit älteren Anwendungen beeinträchtigen. Das rief nun einige Gamer, die Wine nutzen, auf den Plan, denn mit diesen Einschränkungen funktionierten manche Spiele nicht mehr, vor allem, wenn sie auf alten Servern laufen, die nur die alten Protokolle unterstützen. So kam man auf die Idee, für Wine einen Patch zu machen, um die strengen Sicherheitsmaßnahmen von manchen Linuxdistributionen zu umgehen:
https://www.winehq.org/piperma…76824.html
Hier wird auch ganz deutlich das Ziel dieses Patches genannt:
"Fedora 33 disabled protocols below TLS 1.2 through crypto policy [1].
https://fedoraproject.org/wiki…s:_phase_2
Signed-off-by: Paul Gofman <pgofman at codeweavers.com>
---
I suppose other distros are also likely to move this way. So we need to overrides that to
keep earlier protocols working which still work on Windows.
Gnutls finds and loads the system priority file during library initialization, so the override
has effect only for the first dlopen( SONAME_LIBGNUTLS ) in the process and needs to be done
in each place where Wine loads gnutls library."
Und es wurde damals genau die "Lösung" vorgeschlagen, über die wir gerade reden:
setenv("GNUTLS_SYSTEM_PRIORITY_FILE", "/dev/null", 0)
Dieser Befehl öffnet alle Türen und Tore für alte SSL und TLS Protokolle. Die Gamer waren glücklich, denn für sie sind die Sicherheitsmaßnahmen nicht so wichtig, Hauptsache die Spiele laufen.
Nachdem die Clienten von Wine fast ausschließlich Gamer sind, hat man diese Einstellung in der bcrypt.dll bereitwillig übernommen. Wahrscheinlich haben die Entwickler von Wine nicht damit gerechnet, dass es auch "Linux-Freaks" geben könnte, die Wine für ihre Banking-Apps benutzen möchten.
Der aktuelle Eintrag in Wine findet sich in der bcrypt.dll:
https://gitlab.winehq.org/wine…t/gnutls.c
Thema: GNUTLS_SYSTEM_PRIORITY_FILE Zeile 375-382:
if ((env_str = getenv("GNUTLS_SYSTEM_PRIORITY_FILE")))
{
WARN("GNUTLS_SYSTEM_PRIORITY_FILE is %s.\n", debugstr_a(env_str));
}
else
{
WARN("Setting GNUTLS_SYSTEM_PRIORITY_FILE to \"/dev/null\".\n");
setenv("GNUTLS_SYSTEM_PRIORITY_FILE", "/dev/null", 0);
}
if (!(libgnutls_handle = dlopen( SONAME_LIBGNUTLS, RTLD_NOW )))
{
ERR_(winediag)( "failed to load libgnutls, no support for encryption\n" );
return STATUS_DLL_NOT_FOUND;
}
Ich bin erst durch @Stefan193 auf dieses Sicherheitsproblem unter Wine aufmerksam geworden. Die "Banker" können aber glücklicherweise dieselbe Methode benutzen, um die unsicheren Protokolle wieder zu deaktivieren.
Banking4 benutzt Schannel wie andere Windows-Programme, die auf .Net Framework 4.8 basieren, um den Online Traffic zu regeln.
Geregelt wird das in der secur32.dll im Verzeichnis "schannel.c":
https://gitlab.winehq.org/wine…type=heads
Zeile 197-203:
{ L"SSL 2.0", SP_PROT_SSL2_CLIENT, SP_PROT_SSL2_SERVER, FALSE, TRUE }, /* NOTE: TRUE, TRUE on Windows */
{ L"SSL 3.0", SP_PROT_SSL3_CLIENT, SP_PROT_SSL3_SERVER, TRUE, FALSE },
{ L"TLS 1.0", SP_PROT_TLS1_0_CLIENT, SP_PROT_TLS1_0_SERVER, TRUE, FALSE },
{ L"TLS 1.1", SP_PROT_TLS1_1_CLIENT, SP_PROT_TLS1_1_SERVER, TRUE, FALSE /* NOTE: not enabled by default on Windows */ },
{ L"TLS 1.2", SP_PROT_TLS1_2_CLIENT, SP_PROT_TLS1_2_SERVER, TRUE, FALSE /* NOTE: not enabled by default on Windows */ },
{ L"DTLS 1.0", SP_PROT_DTLS1_0_CLIENT, SP_PROT_DTLS1_0_SERVER, TRUE, TRUE },
{ L"DTLS 1.2", SP_PROT_DTLS1_2_CLIENT, SP_PROT_DTLS1_2_SERVER, TRUE, TRUE },
Hier sieht man schön, dass dort TLS 1.3 nicht unterstützt wird, aber leider dafür veraltete Protokolle, die nicht mehr als sicher gelten!
Es gibt zwar in Wine ein Test Verzeichnis, dort wird TLS 1.3 unterstütz, aber man muss sich als Entwickler oder sowas dort anmelden, damit man darauf Zugriff hat:
Aktuelle secur32.dll Test schannel.c
https://gitlab.winehq.org/wine…type=heads
Zeile 198-206:
#define X(flag, name) do { if(protocols.grbitProtocol & flag) { trace(name "\n"); protocols.grbitProtocol &= ~flag; } }while(0)
X(SP_PROT_SSL2_CLIENT, "SSL 2 client");
X(SP_PROT_SSL3_CLIENT, "SSL 3 client");
X(SP_PROT_TLS1_0_CLIENT, "TLS 1.0 client");
X(SP_PROT_TLS1_1_CLIENT, "TLS 1.1 client");
X(SP_PROT_TLS1_2_CLIENT, "TLS 1.2 client");
X(SP_PROT_TLS1_3_CLIENT, "TLS 1.3 client");
X(SP_PROT_DTLS1_0_CLIENT, "DTLS 1.0 client");
X(SP_PROT_DTLS1_2_CLIENT, "DTLS 1.2 client");
Was macht "Schannel"?
"Schannel.c" steuert die ganzen Prozesse zur Herstellung der Onlin-Traffic, aber ausgeführt werden die Prozesse erst unter "schannle_gnutls.c:
Aktuelle secur32.dll schannel_gnutls.c
https://gitlab.winehq.org/wine…type=heads
Zeile 361-380:
static const struct protocol_priority_flag client_protocol_priority_flags[] = {
{SP_PROT_DTLS1_2_CLIENT, "VERS-DTLS1.2"},
{SP_PROT_DTLS1_0_CLIENT, "VERS-DTLS1.0"},
{SP_PROT_TLS1_3_CLIENT, "VERS-TLS1.3"},
{SP_PROT_TLS1_2_CLIENT, "VERS-TLS1.2"},
{SP_PROT_TLS1_1_CLIENT, "VERS-TLS1.1"},
{SP_PROT_TLS1_0_CLIENT, "VERS-TLS1.0"},
{SP_PROT_SSL3_CLIENT, "VERS-SSL3.0"}
/* {SP_PROT_SSL2_CLIENT} is not supported by GnuTLS */
};
static const struct protocol_priority_flag server_protocol_priority_flags[] = {
{SP_PROT_DTLS1_2_SERVER, "VERS-DTLS1.2"},
{SP_PROT_DTLS1_0_SERVER, "VERS-DTLS1.0"},
{SP_PROT_TLS1_3_SERVER, "VERS-TLS1.3"},
{SP_PROT_TLS1_2_SERVER, "VERS-TLS1.2"},
{SP_PROT_TLS1_1_SERVER, "VERS-TLS1.1"},
{SP_PROT_TLS1_0_SERVER, "VERS-TLS1.0"},
{SP_PROT_SSL3_SERVER, "VERS-SSL3.0"}
/* {SP_PROT_SSL2_SERVER} is not supported by GnuTLS */
Hier wird zwar TLS 1.3 unterstützt, aber das nützt nichts, weil in "schannel.c", wo die Prozesse gesteuert werden, TLS 1.3 eben nicht unterstütz wird.
Was bewirkt nun der Befehl "setenv("GNUTLS_SYSTEM_PRIORITY_FILE", "/dev/null", 0)" in Wine?
"/dev/null": Setzt den Pfad auf das „Nulldevice“. Da diese Datei leer ist, ignoriert gnutls nun alle Systemregeln, die das jeweilige Betriebssystem für gnutls festgelegt hat, z. Bsp. wird in Fedora die Deaktivierung von TLS 1.0 und TLS 1.1 damit aufgehoben. Dieser Befehl funktioniert auch, wen man anstatt "dev/null" eine Datei angibt, die es gar nicht gibt.
Wie oben aber in der Anleitung steht, muss dieser Befehl gesetzt werden,
bevor die Bibliotheken des Betriebssystems geladen werden, die die Deaktivierung unliebsamer Algorithmen enthalten:
"Gnutls finds and loads the system priority file during library initialization, so the override
has effect only for the first dlopen( SONAME_LIBGNUTLS ) in the process and needs to be done
in each place where Wine loads gnutls library."
Dies wird in Wine mit folgendem Befehl erreicht (s.o.):
if (!(libgnutls_handle = dlopen( SONAME_LIBGNUTLS, RTLD_NOW )))
Jetzt wissen wir, dass in Wine alle möglichen Algorithmen aktiviert werden, außer TLS 1.3.
Was passiert nun, wenn man "GNUTLS_SYSTEM_PRIORITY_FILE" als Umgebungsvariable vor dem Starten der Banking4-APP setzt?
Wenn man den Befehl "GNUTLS_SYSTEM_PRIORITY_FILE" als Umgebungsvariable vor dem Starten der Banking4-APP setzt, werden nicht nur die Systemregeln des Betriebssystems bezüglich gnutls ignoriert, sondern auch die in Wine, die gnutls betreffen. Also wird nun auch "schannel.c" in der secur32.dll ignoriert. Das merkt man deutlich daran, dass es nun völlig egal ist, ob man in Wine Windows11 oder Windows7 einstellt. Jedesmal wird TLS 1.3 unterstützt!
Mit diesem Befehl kann man zwei Fliegen mit einer Klappe schlagen, denn es wird nicht nur TLS 1.3 freigeschaltet, sondern man kann mit einer entsprechenden config-Datei nun auch unliebsame Algorithmen wieder deaktivieren.
Wie gesagt, ich bin nicht vom Fach. Das ist nur das Ergebnis meiner Recherche. Vielleicht kann jemand hier, der vom Fach ist, diese Ergebnisse verifizieren. Vielen Dank!
Meine aktuelle Anleitung für Banking4 unter Linux befindet sich hier:
forum/topic.php?p=185677#real185677
