banking4w unter ubuntu

Ist ja spannend hier


An diesem Punkt ist mein Verständnis ein anderes: libgnutls-openssl ist ein Wrapper, um Programme, die die openssl-API benötigen, an GnuTLS zu bringen. Der Wrapper ist aber eher traurig / unvollständig und daher nicht wirklich zu gebrauchen.

Zum Hintergrund: openssl war historisch lange vor GnuTLS und die machen final beide das gleiche. GnuTLS ist ein MeToo-Produkt und entstand u.a. aus lizenztechnischen Gründen (für einige Radikale ist die openssl-Lizenz Apache 2.0 vs. GPL 3/LGPL 2.1 böse). Einige radikale Distris wie Debian brauchen daher diesen libgnutls-openssl workaround, da wine teilweise eben auch auf openssl basiert und dort kein openssl vorhanden ist. In openSUSE z.B. ist der üble Workaround nicht nötig, weil openssl als Standard vorhanden ist.

Dass man bereits durch eine nicht vorhandene Datei einen anderen default priority string erzwingen können soll, ist schon schräg. Habe mich schon gewundert, was in der Datei stehen soll - die gibt es auf openSUSE (Leap 16 z.B.) schlicht nicht. Ob diese Hacks auf openSUSE überhaupt nötig sind konnte ich nicht testen, da ich keine TLS 1.3 Ziele habe.
Ich habe es mal mit atruvia getestet mit der Umgebungsvariable
GNUTLS_SYSTEM_PRIORITY_FILE=/etc/gnutls/gnutls.conf
und konnte nachvollziehen, dass sie greift - danach ging gar nichts mehr in Sachen SSL - selbst TLS 1.2 ging nicht mehr:
GnuTLS error: Die Anfrage ist ungültig.
Dabei ist völlig irrelevant, ob die Datei vorhanden ist oder nicht und ob sie einen sinnvollen Inhalt hat (wie weiter oben vorgeschlagen) oder nicht.

Naja, ich nutze kein Banking4 - von daher ist mir das egal. Ich bevorzuge native Programme. Aber interessiert hat mich es trotzdem .

@hbciuser
Vielen Dank für die Rückmeldung. Die Auswirkungen in openSUSE sind schon seltsam, zumal Wine diesen "Hack" ja selber benutzt, um veraltete Algorithmen freizuschalten, damit Programme auf alten Servern laufen können. Das wird in der bcrypt.dll gesteuert in den Zeilen 375-385:

https://github.com/wine-mirror…t/gnutls.c

Der Befehl lautet dort:

setenv("GNUTLS_SYSTEM_PRIORITY_FILE", "/dev/null", 0)

"/dev/null": Setzt den Pfad auf das „Nulldevice“. Da diese Datei leer ist, findet GnuTLS keine restriktiven Systemregeln vor. Nun sind alle Protokolle freigeschaltet, aber seltsamerweise nicht TLS 1.3.
Dieser „Hack“ wird also häufig in Software wie OpenConnect oder Wine verwendet, um Verbindungsprobleme mit alten Servern zu lösen.

Deswegen ist es wichtig, den Vorschlag von @Stefan193 und @vnt in der config Datei umzusetzen. Das funktioniert auch ganz gut. Das kann man mit folgenden Befehl von @Stefan193 testen (je nachdem wo die config Datei steht, muss man den Pfad anpassen):

GNUTLS_DEBUG_LEVEL=2 GNUTLS_SYSTEM_PRIORITY_FILE=/etc/gnutls/config gnutls-cli --priority "NORMAL" --list

Bei mir auf CachyOS war die config Datei schon vorhanden, aber ohne disabled-Befehle, bei manchen Distributionen muss man sie erst erstellen. Bei meinem aktuellen Skript geschieht das alles automatisch einschließlich der disabled-Befehle.

Wenn ich den Befehl mit der Umgebungsvariable (export GNUTLS_SYSTEM_PRIORITY_FILE=~/Pfad zur/config) wieder entferne, wird wie zuvor wieder TLS 1.2 benutzt. Es gibt keinerlei Störungen.

@vnt
Vielen Dank für deinen Beitrag. Die Idee, die Schrift Segoe UI zu benutzen, hatte ich wieder verworfen, weil ich nicht sicher bin, wie das lizenrechtlich aussieht. Wenn man eine Windows Lizenz hat, dürfte das kein Problem sein. Toll ist natürlich, dass dann auch alle Symbole angezeigt werden.

Hallo zusammen,
mein bescheidener Senf zu den obigen Erkenntnissen:

Bei meinem frischen Banking-Debian 13 hat(te) die Installation des Pakets libgnutls30t64 offenbar keine Konfig-Datei erzeugt. Wenn die Datei gar nicht oder leer vorhanden ist, nutzt gnutls auf der Linux-Seite nach meinem Verständnis rein wegen der Angabe der vorrangigen Umgebungsvariable für diese Shell das was entweder in der config steht und wenn die es nicht gibt oder dort nix steht dann eben den Priority String "NORMAL" - egal was aus wine rauskommt. Der hat bei meinem Debian 13 aber TLS1.0 und 1.1 im Angebot. Wie das wäre, wenn ich bspw so rumhantieren würde
hab ich nicht probiert, weil da meine Birne schon zu weich war

Nach meinem Verständnis müsste mit dem folgenden Abschnitt der priority String @SYSTEM in der config erzeugt werden und gleichzeitig die alten TLS-Versionen etwas rasiert werden können (vorher nachschauen ob nicht noch ältere an Bord sind, die abzuklemmen wären):


Da ist dann nur bei PS "@System" diese TLS-Einstellung wirksam. Dass Suse das so nutzt wusste ich nicht.

Radikales Ab- und explizites Freigeben einzeln Protokollversionen ginge demnach so:


Ich hab die (bei mir vorhandenen) ollen Protokolle deshalb abgeklemmt, weil ich einen theoretisch Downgrade-Angriff minimieren wollte und damit mein Client gar nicht erst die alten Protokolle anbietet. Das kann man weglassen, man sieht dann im Netzwerkverkehr wie erst der Client die alten anbietet und der Server was anderes verhandelt und man sich auf TLS1.3 einigt.

Banking4 ruft erst mal bei Subsembly an weil es nach Updates sucht, so hab ich das interpretiert. Wer das nicht mag, der muss das Häkchen halt in b4 rausnehmen und manuell überwachen.

Ich hab den Verdacht, dass in wine aktuell TLS1.3 absichtlich (noch) abgeklemmt ist. Zu TLS1.2 unterscheidet es sich doch mehr als 1.2 zu 1.1 und so lange nicht alle gegenüber 1.2 geänderten Features von 1.3 in wine komplett umgesetzt sind, kann das Programme ins Wanken bringen, die bspw. längere Zeiträume eine TLS-gesicherte Verbindung aufrechthalten. M.E. vor allem durch alle möglichen Windows-Anwendungen über wine-schannel verlangten TLS1.3 Feature (bspw. andere Verschlüsselung des Handshakes, Post-Handshake-Verhalten, Stichworte Cipher Suite Negotiation und Ticket Handling) . Da B4 "nur" den kurzen Abrufzeitraum hat, kommen manche der potenziellen Stolperstellen m.E. gar nicht erst in Frage und daher klappt's auch mit TLS1.3 und B4.


Beste Grüße
Stefan

Ja, der Austausch ist sehr informativ

Probiere doch mal wie es sich verhält wenn Du mit dem Befehl nicht "NORMAL" abfragst sondern "@SYSTEM", also "GNUTLS_SYSTEM_PRIORITY_FILE=gnutls.cfg gnutls-cli --priority @SYSTEM --list". Ich denk nicht, dass mit der Einstellung oben "NORMAL" modifiziert wird.
Ich konnte "NORMAL nicht modifizieren, außer mit dem oben genannten "disabled-version" gezielt einzelne Protokolle abklemmen.

Hallo @hbciuser,
wow - mit -allowlist hab ich mich noch nie eingehend beschäftigt. Dazu steht eine ganze Menge in der gnutls-Doku. Das beeinflusst auch, wie manche Parameter wirken. Da wird tatsächlich ne Menge konfigurierbar, vieles dazu noch Versionsabhängig,, aber dazu hab ich nicht die Kenntnisse. Deswegen haben die vermutlich auch mal "priority strings" gemacht -> um einen bestimmten Einstellungssatz zusammenzufassen, den man sich dann mit dem default-Parameter konfigurieren kann. Da kommts dann auf priorities (nicht die Einstellungen sondern echte) an und welche Chiphers mit welchen Protokollen und welche Schlüssellängen etc. Puh. Das mach ich nicht, da fehlen mir die Kenntnisse. Und bevor ich mir da irgendein Loch reinkonfiguriere ... nene.

Suse hat da mit 105 lines wohl die ganz große Nummer gezogen und alles extrem explizit auf die Distro zugeschnitten konfiguriert. So wie es vom Projekt in der Doku beschrieben wird.
Du kannst ja "spaßhalber" mal in der config nach "TLS" suchen, welchen starken Zauber die Suse's da abgeliefert haben

Zum "Heimtelefonieren": Ich hab lange mir mir gerungen, welche Software ich nach moneyplex nutzen soll. OpenSource war die ja auch nicht. Dann hab ich mich halt für banking4 entschieden, weil ich mit hibiscus doch nicht warm wurde. Von gnucash oder kmymoney hab ich gleich die Finger gelassen, weil mir an der Stelle der Einarbeitungsaufwand zu groß war und ich rein fürs banking nicht noch ne doppelte Buchführung für unsere paar Kröten machen wollte und dennoch keine Banking-App nutzen wollte und will (von wegen heimtelefonieren ..). An allen Fronten bis ins Detail zu agieren, dazu fehlt mir letztlich die Zeit.

Anonyme Nutzungsstatistiken sind für Entwickler wichtig für die Weiterentwicklung und Fehlersuche. Es profitiert also nicht nur der Entwickler davon, sondern alle Benutzer.
Darüber hinaus ist zu berücksichtigen, dass es sich bei den erhobenen Daten um anonyme Nutzungsstatistiken handelt, die keinerlei Rückschluss auf einzelne Personen zulassen. Es geht also nicht um Überwachung oder Profilbildung, sondern ausschließlich um technische Optimierung und Stabilität der Software.
Ein Opt-In-Verfahren mag auf den ersten Blick datenschutzfreundlicher erscheinen, führt in der Praxis jedoch häufig zu stark verzerrten oder unvollständigen Datensätzen. Gerade bei spezialisierten Anwendungen mit einer vergleichsweise kleinen Nutzerbasis, wie dies eine FinTS-Software nunmal ist, würde dies bedeuten, dass wichtige Fehlerbilder oder Nutzungsmuster gar nicht erst erkannt werden - man könnte mit dieses Daten effektiv kaum noch etwas sinnvolles anfangen. Die Konsequenz wäre letztlich eine schlechtere Softwarequalität für alle.
Hinzu kommt, dass Transparenz und Kontrolle bereits gegeben sind: Nutzer werden informiert und haben jederzeit die Möglichkeit, die Erhebung zu deaktivieren. Damit bleibt die Entscheidungsfreiheit gewahrt, ohne die Funktionsfähigkeit und Weiterentwicklung der Software unnötig zu beeinträchtigen.
In der Abwägung zwischen minimal-invasiver Datenerhebung und dem konkreten Nutzen für die gesamte Nutzergemeinschaft erscheint mir ein standardmäßig aktiviertes, aber abschaltbares System daher als sinnvoller und verhältnismäßiger Ansatz. Jeder, der sich daran stört, kann die Nutzungsstatistiken abschalten oder die Software garnicht erst benutzen.

Deine Argumentation ist schräg.

Ich habe es selbstverständlich ausgeschaltet, bevor Daten geflossen sind. Die Allgemeinheit hat damit allerdings kein Problem und lässt es deswegen aktiviert, was uns allen zu Gute kommt.
Dass es dich nicht stört habe ich verstanden, sonst hättest du ja keine Lizenz gekauft.

Zitat von hbciuser:
die Daten gehören mir und ich habe das Programm bezahlt.

Achso, jetzt wird aus einer ganz normalen Diskussionsbemerkung also ein Fall für die große Empathie-Schule. Dann lass es mich für die Galerie noch einmal auf Deutsch sagen: Du kannst das Thema natürlich aus Deiner technischen Perspektive betrachten, dies ändert jedoch nichts daran, dass mein Punkt ein anderer war. Dass du das nicht voneinander trennen willst, ist eher dein Problem als meins. Man kann andere Einschätzungen auch einfach mal stehen lassen und für sich reflektierend prüfen, ohne sie gleich einordnen, widerlegen oder eine ideologische Diskussion starten zu müssen.
Wäre also gut, wenn du nun wieder back to topic übergehst - bis dahin bleibe ich bei meiner Einschätzung.