TLS-Gate – Online-Banking-Check

Schlechte Nachrichten für Eure Online-Banking Sicherheit:

18 von 20 getesten Online-Banking-Webseiten erlauben gebrochene Krypto!

In einem kleinen Test mit zufällig ausgewählten Online-Banking Webseiten, haben nur zwei Vertreter schon mal etwas von Security gehört. Die in der Liste grün hervorgehobenen Banken hatten nur TLS 1.2+ im Einsatz, wohin gegen die Anderen TLS 1.0 und TLS 1.1 neben TLS 1.2 erlaubt haben.

Damit sind Szenarien möglich, bei der es Angreifer schaffen, das SSL-Protokoll auf TLS 1.1 zu drücken, oder das gleich uralte Browser und Betriebssysteme zum Einsatz kommen, die von selbst mit gebrochener Krypto Verbindung zur Bank aufnehmen.

So oder so, ein Fest für Abhörer und Kriminelle.

Alle Banken hatten keine Probleme mit TLS 1.2, so daß ein aktueller Browser sich mit einer sicheren Verbindung zur Bank verbunden hat. Eure Sicherheit ist also nur dann gefährdet, wenn Euch jemand angreift und das ist genau das, was man mit guter Security verhindert. Wenn der Bankwebserver kein TLS 1.0 anbietet, würde so ein Angriffsszenario, bei dem die Verbindung derart gestört wird, daß TLS 1.2 nicht zu stande kommt, gar nicht erst funktionieren können.

Dummerweise gabs es in der Vergangenheit genug Beispiele, wie man solche Angriffe auf SSL-Verbindungen durchführt. Es ist also nicht ausgeschlossen, daß es jemand auch bei Euch schafft.

Domainname[:443]TLS 1.0TLS 1.1CA
www.commerzbank.de++Digicert
www.nordlb.de++Digicert
www.ksk-stade.de++Digicert
meine.postbank.de++Digicert
meine.deutsche-bank.de++Digicert
www.berliner-sparkasse.de++Digicert
www.bv-activebanking.deDigicert
meine.norisbank.de++Digicert
www.dkb.de++Digicert
www.sparda-b.de++QuoVadis
www.vrbankmecklenburg.de++QuoVadis
www.volksbank-demmin.de++QuoVadis
calenberger.de (Calenberger Kreditverein)++Lets Encrypt!
www.ksk-walsrode.de++Digicert
www.diebank.de++QuoVadis
www.sparkasse-celle.de++Digicert
banking.seeligerbank.deDigicert
www.sparkasse-nordhorn.de++Digicert
hbciweb.olb.de++D-Trust GmbH
www.apobank.de++QuoVadis

Wie kommt das zu Stand?

Wie man das erwarten würde, gibt es Gruppen von „Banken“ die eigentlich nur Filialen eines Konzerns sind. Mag sein, daß der eine oder andere örtliche Bankvorstand das anders sieht, aber spästens wenn jemand mal Geld nachschiessen muß, sieht man, wer mit wem verbandelt ist.

Die Sparkassen haben daraus gleich eine Tugend gemacht und einen eigenen Sparkassen Webframework gebaut. Im Prinzip ist die Online-Bankingseite für alle Sparkassen gleich, lediglich das Logo und Name & Anschrift der Bank in Texten sind angepaßt. Da Banken und Sparkassen nicht in jedem x-beliebigen Rechenzentrum hosten dürfen, gibt es nur wenige Anbieter auf die sich die Dienste verteilen.

Folge, so wie jetzt, fällt eine Webseite negativ auf, sind alle Seiten des Konglomerats betroffen.

Es ist an Euch das zu ändern in dem Ihr selbst zu Eurer Bank geht und das moniert.

Wie beweist Ihr das?

Man verbindet sich mit der Bankseite und sagt openssl nur TLS 1.0 anzubieten :

openssl s_client -connect www.apobank.de:443 -tls1

New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 9F46E16A883DB49FA5A516BCDB23B67F24ED12E5EA6F9F83C504A6CF4CA96A24
Session-ID-ctx:
Master-Key: 4166D9B1C922F2410E6C0BF98BBE1D4B9BA03F238A6112F7FFA6B624F0BDFD8F7F759D97BDCB108CC3E4E635EBA17E24

Kommt eine Session und Key zustande, hatte man mit seiner Bank leider Pech 🙂

So sieht das aus, wenn man mit der Bank Glück hatte :

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1563537522
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Keine Session. Kein Key. Kein Problem!