Ist in der Version die ich benutze nicht änderbar. Ich habe aber auch keinerlei Veränderungen der Konfiguartion vorgenommen. Hat denn jemand ein Feedback der Postbank eingeholt?

Hallo,

wer den Thread von Anfang an bis hierher verfolgt, der erfährt, dass es bei der Postbank auch schon bisher mit einem von zwei Servern Verbindungsprobleme gab. Es sieht so aus, als ob seit ein paar Tagen nun beide Postbank Server die gleichen Probleme machen. Alle bisherigen Work-Arounds sind deshalb leider nutzlos.

Bei näherer Untersuchung des Problems habe ich (mal wieder) herausgefunden, dass die Ursache das SSL-Handshake ist. Windows Mobile bekommt zum HBCI-Server der Postbank (hbci.postbank.de) einfach keine SSL-Verbindung hin.

Um den Abend zu retten habe ich folgenden Work-Around für Euch. MIt einem Registry Editor müssen folgende Einträge geändert werden:

[HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL\Ciphers\AES 128/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL\Ciphers\AES 256/256]
"Enabled"=dword:00000000

Dann klappt das mit dem SSL-Handshake. Allerdings wird dann generell keine AES-Verschlüsselung mehr verwendet, sondern nur noch RC-Verschlüsselung. Das ist aber genau so sicher.

Wer das jetzt nicht verstanden hat, der sollte besser die Finger von den Änderungen lassen.

In jedem Fall solltet Ihr Euch beim Kundensupport der Postbank melden. Vielleicht wird so erreicht, dass die Postbank das so ändert, dass es auch mit Windows Mobile geht.

Abgesehen davon werde ich versuchen noch eine bessere Lösung zu finden.

Danke für Deinen fabelhaften Support! Das klappt!

Super, die Lösung funktioniert!

Ich werde mich leider erst morgen mit der Postbank in Verbindung setzen können, erwarte aber auch nicht wirklich ein verständnisvolles Problembewußtsein... Ich habe nun mal wieder den DNS Namen eingetragen, wer weiß ob die Postbank mal die IP Adressen ändert.

Ist die Nutzung der RC Verschlüsselung wirklich genauso sicher wie AES???

Gruß Hase

Guten Morgen,

bei der RC4 Verschlüsselung wird ein 128 Bit langer Schlüssel verwendet. Bei AES könnte es ein 256 Bit langer Schlüssel sein. Theoretisch ist das schon sicherer, praktisch ist das aber nicht relevant. 128 Bit ist in jedem Fall mehr als genug. HBCI selbst verwendet für die Verschlüsselung nur das 2-Key-3-DES Verfahren mit einer Schlüssellänge von 112 Bit. So gesehen ist SSL mit RC4 sogar besser als die hauseigene HBCI Verschlüsselung.

Achtung: Bitte diese Schlüssellängen nicht mit RSA Schlüssellängen vergleichen, bei RSA ist das ganze noch mal alles ganz anders. RSA wird nur zum Schlüsselaustausch und zur Signatur verwendet.

Hallo allerseits,

ich habe nun einen Work-Around im Programm implementiert. Ich bin mir nicht sicher ob es auf allen Geräten mit allen Windows Mobile Versionen funktioniert und biete es deshalb erst mal nur als Beta-Download an. Mit dem neuen Work-Around kann und sollte in den Einstellungen für den Bankkontakt wieder die Internetadresse https://hbci.postbank.de/banking/hbci.do eingetragen werden. Die Einstellung für "Kommunikationsdienst" muss auf "Automatisch" (empfohlen) oder "HTTP über WinINet" stehen.

Nun zum Download:

Setup: http://subsembly.com/beta/SubBankingSetup.exe

CAB: http://subsembly.com/beta/SubBanking.CAB

Hallo Andreas,

Ich dachte, das Problem wäre gelöst, und war überrascht, dass dem nicht so ist.

Seit Oktober 2009 ist das Problem bei mir nicht mehr aufgetreten.
Habe folgende Einstellungen (Postbank Dortmund) Handy: HTC HD2
https://195.50.155.64/banking/hbci.do
Kommunikationsdienst: Automatisch, aber auch keine Probleme mit WinINet gehabt, welches ich damals einstellte und erst vor ein paar Tagen änderte, da ich ja Probleme mit dem Netbankzugang hatte.
Den Registry-Hack hatte ich damals auch ausprobiert und brachte ebenfalls den Erfolg.

Mit den obigen Einstellungen habe ich auch heute keine Zugangsprobleme.
Der Reg-Hack ist bei mir nicht nötig.

Ach ja, meine momentane .NETCF ist 3.5.9198.0

Wenn oder was ich noch testen soll, must Du mir sagen.
Bin so zufrieden mit Deiner Soft, dass ich mir nun auch die USB-Version zulegte.

Hallo,

das am Anfang des Threads beschriebene Problem war in der letzten Version auch nicht wirklich gelöst. Ich hatte intern nur https://hbci.postbank.de/banking/hbci.do fest auf https://195.50.155.64/banking/hbci.do umgebogen, so dass der nicht funktionierende Server einfach umgangen wurde. Doch nunmehr wurde von der Postbank auch der bisher funktionierende Server umgestellt, so dass es gar nicht mehr geht.

Möglicherweise ist in .NETCF 3.5.9198 und/oder im Windows CE des HTC HD2 der SSL-Fehler behoben. Ich habe hier leider nur Windows Mobile 6.1 und .NETCF 3.5.7283 zum Testen. Das neuere .NETCF 3.5.9198 gibt es nicht als Update zum Download (und einen HD2 kann ich mir nicht leisten )

Die Einstellung Kommunikationsdienst = Automatisch bedeutet bei der Postbank dass "HTTP über WinINet" genommen wird. Deshalb würde es mich interessieren, ob bei Dir mit dem neueren .NETCF die Postbank auch mit der Einstellung "HTTP über .NETCF" funktioniert.

Wenn es bei Dir auch ohne meine neue Beta-Version mit den genannten Einstellungen funktioniert, dann hat Microsoft den SSL-Fehler wohl in der neueren Windows Mobile Version des HD2 behoben. Mein WinMo 6.1 Testgerät hat Windows CE 5.2.19216 als Version. Welche hat das HD2?

Hallo Andreas,

ich habe ein HTC HD2 mit dem aktuellen ROM1.66 (kein Branding), davor hatte ich eines mit der 1.48 ROM (o2-branding)Version. Auf dem HTC mit dem 1.48 ROM hatte ich keine Probleme die Daten von der Postbank Stuttgart abzuholen. Doch bei dem neuen HTC mit dem ROM 1.66, war es nicht mehr möglich eine Verbindung zur Bank herzustellen. Lag eindeutig nicht am Post-Server, da ich das Banking-Modul an meinem IPAQ 6915 ausführen konnte.
Mit deinem Workaround funktioniert es jetzt auch auf dem HTC HD2 mit dem 1.66 ROM.
Übrigens ich habe CF 3.5 nicht installiert.

Gruß

Werner

Hallo Andreas,

wie Laxxan schon schrieb, liegt es nicht an der Postbank und auch nicht am
jeweiligen Handy.

Es muss an der .NETCF liegen.
Ich habe eine ältere Romversion mit folgenden Einstellungen und .NETCF getestet:

.NETCF -- (A)utom, (N)ETCF,(W)inINET -- Erfolg

orginal 2.0.7045.00 -- egal -- keine Verbindung

3.5.7283 -- egal -- keine Verbindung

nachfolgende .NETCF nur in TestROMs vorhanden.
3.5.9198 -- A -- problemlos
3.5.9198 -- N -- problemlos
3.5.9198 -- W -- keine Verbindung
höher das gleiche Ergebnis wie 3.5.9

interessant dabei ist, das (W)inINET gar nicht funktioniert...
Registry wurde dabei noch nicht verändert.

@Laxxan Das neuerliche Postbankproblem gibt es erst seit ca. 8. Februar. Vor diesem Tag war es egal welche Windows Mobile/.NETCF Version man hatte.

Das .NETCF 3.5 sollte beim HD2 immer schon im ROM vorhanden sein. In Subsembly Banking wird unter "Copyright" die Windows CE und die .NETCF Version angezeigt.

Hallo,

habe mir heute Subsembly zugelegt und hatte ebenfalls das Problem mit der Postbank.

Nach Installation der o.g. Beta-Version/gepatchten Version scheint es aber derzeit ohne Probleme zu funktionieren (WM 6.5 HTC HD2 1.48 ROM ohne Branding)

Mfg

BraveSurfer

Erst mal vielen Dank für Eure tatkräftige Unterstützung. Ich versuche mal ausführlich alles zusammenzufassen und zu erklären.

Bei der Einstellung "HTTP über WinINet" wird von mir das .NETCF bei der Verbindung und Übertragung praktisch umgangen. Ich mache in diesem Fall direkte Systemaufrufe zur so genannten WinINet.dll. Die WinINet.dll hat eine ganz eigene SSL-Implementierung unabhängig vom .NETCF. Bei dieser Einstellung sollte deshalb die .NETCF Version keine Rolle spielen. Nur die Windows CE Version spielt hier eine Rolle, da die WinINet.dll Teil des Windows CE Basisbetriebssystems (ja, ich meine wirklich Windows CE und nicht Windows Mobile) ist.

Bei der Einstellung ".NET über NETCF" wird von mir die Verbindung und Übertragung aus dem .NETCF verwendet, so wie es eigentlich immer sein sollte. Auch das .NETCF hat eine eigene SSL-Implementierung. Keine Ahnung wieso Microsoft meint auf einem System zwei unterschiedliche SSL-Implementierungen haben zu müssen, aber egal. Bei dieser Einstellung hängt das Funktionieren zu 100% von der .NETCF Version ab. Die Windows CE Version spielt hier wiederrum keine Rolle.

Leider hat es Microsoft geschafft in bestimmten Versionen in beide voneinander unabhängigen SSL-Implementierungen Fehler einzubauen die sich im Zusammenspiel mit dem Postbank-Server fatal auswirken.

Bei der Einstellung "Automatisch" wird eine interne Tabelle verwendet welche anhand der Zieladresse entscheidet ob nun WinINet oder NETCF verwendet wird. Wären beide SSL-Implementierungen von Microsoft fehlerfrei wäre das alles nicht nötig. So aber habe ich intern eine auf Erfahrung basierende Tabelle aus der hervorgeht mit welcher Zieladresse ich welche Implementierung nehmen muss damit das SSL klappt. Ist als Zielserver "https://hbci.postbank.de/banking/hbci.do" angegeben wird laut meiner Tabelle WinINet verwendet. Die Einstellung "Automatisch" entspricht somit der Einstellung "HTTP über WinINet".

Dank der Tests von bluescreen bin ich mir nun ganz sicher, dass zumindest der .NETCF SSL-Bug im .NETCF 3.5.9198 behoben wurde. Wäre toll, wenn Microsoft diese Version jedermann zum Download bereit stellen würde. Leider ist der offizielle Download noch immer die Version 3.5.7283.

Der WinINet SSL-Bug scheint hingegen auch im aktuellsten Windows CE das im HD2 läuft noch vorhanden zu sein. Mein neuer Work-Around scheint aber in diesem Fall zu greifen und das Problem zu lösen.

Nun zu meinem neuen WinINet-Workaround. Nach längerem suchen habe ich eine interne undokumentierte Funktion gefunden, mit der ich beeinflussen kann welche SSL Protokollversionen beim Verbindungsaufbau ausgehandelt werden können. Normalerweise wird zwischen Server und Client aus den Versionen SSL 2.0, SSL 3.0 und TLS 1.0 ausgehandelt. Genau der Teil des Verbindungsaufbaus geht aber schief und so kann keine Verbindung hergestellt werden. Ich setze nun intern über besagtes Hintertürchen zur WinINet SSL-Implementierung einen Parameter der dafür sorgt, dass ausschließlich SSL 3.0 versucht wird und keine komplizierte Versionsverhandlung stattfindet. Unter dieser Einstellung klappt dann auch die Verbindung zur Postbank. Diese Einstellung ist nicht in der Registry und betrifft nur das gerade laufende Programm, so dass andere Programme dadurch nicht beeinflusst werden sollten. Einziger Nachteil: Es ist ein undokumentiertes Hintertürchen das ich da verwende und es kann gut sein, dass es mit anderen Geräten oder Windows CE Versionen in die Hose geht. Aber allemal besser als gar keine Problemlösung.

Auf Windows und mit MS Tools zu entwickeln scheint lustig zu sein....
Kriegst du für die ganzen Stolpersteine die da im Weg liegen wenigstens Rabatt auf die Kosten der Software-Entwicklungsumgebung?

@Caption FRAG:

Beim iPhone sagen Sie "There is an App for that"

Beim Windows Mobile sagt man "There is a Hack for that"

)

Guten Abend,
hatte das selbige Problem mit dem Postbankzugang. Auch bie mir hat der Work-Around geholfen. Zugriff nun wieder problemnlos möglich.
Möchte mich für die schnelle Unterstützung bedanken!

Gruß Bernd

Hallo,
hatte seit einigen Monaten sporadisch Probleme mit Postbank Dortmund u. Karlsruhe. Manchmal war tagelang kein Kotakt möglich. Seit dem 9.2. gind nichts mehr. Benutze Vario V mit Wind. Mob. 6.1.
Ich habe gerade subsembly.com/beta/SubBankingSetup.exe installiert und bin sehr dankbar, daß nun wieder die Bankkontakte funktionieren.
Herzlichen Dank!
Gruß
Hermann

Ich komme mit der Postbank nicht weiter, habe die Beta installiert, kommt Bank antwortet nicht...

doppelt sorry

@Garfield: Heißt das, das Problem besteht auch mit der oben verlinkten Beta-Version noch?