E-Banking in Österreich: Status quo zu TLS & DNSSEC
Nach etwas mehr als einem Jahr werfen wir erneut einen Blick auf die Sicherheit von E-Banking Internetseiten österreichischer Kreditinstitute in Bezug auf das SSL-Setup und dem Einsatz von DNSSEC.
Für eine oberflächige Einführung in SSL/TLS und DNSSEC und die Testresultate vom letzten Jahr sei auf die entsprechenden Artikel verwiesen:
Die untenstehende Tabelle stellt eine Übersicht über die aktuellen Testresultate dar.
| Hostname | TLS | Sign. Alg. | Cipher suite | HSTS | DNS- SEC | |||
|---|---|---|---|---|---|---|---|---|
| Key exch. | Encryption | MAC | ||||||
| netbanking.sparkasse.at | A+ | TLS 1.0-1.2 | SHA256 | ECDHE_RSA | AES_128_GCM | SHA256 | Y | N |
| ebanking.bawagpsk.com | A | TLS 1.0-1.2 | SHA256 | ECDHE_RSA | AES_128_GCM | SHA256 | Y | N |
| ebanking.easybank.at | A | TLS 1.0-1.2 | SHA1 | ECDHE_RSA | AES_128_GCM | SHA256 | Y | N |
| my.paylife.at | A | TLS 1.0-1.2 | SHA256 | DHE_RSA | AES_128_GCM | SHA256 | N | N |
| ECDHE_RSA | AES_256_CBC | SHA | ||||||
| banking.raiffeisen.at | A- | TLS 1.0-1.2 | SHA1 | DHE_RSA | AES_256_CBC | SHA | Y | N |
| www.banking.co.at (Volksbank) | A- | TLS 1.0-1.2 | SHA1 | ECDHE_RSA | AES_128_CBC | SHA | Y | N |
| 3DES_EDE_CBC | ||||||||
| online.bankaustria.at | A- | TLS 1.0-1.2 | SHA256 | RSA | AES_256_CBC | SHA | Y | N |
| www.paypal.com | B | TLS 1.0-1.2 | SHA256 | RSA | AES_256_CBC | SHA | Y | Y/N |
| ebanking.denizbank.at | B | TLS 1.0 | SHA256 | RSA | AES_128_CBC | SHA | N | N |
| www.sparanlage.at | B | SSL3, TLS 1.0, TLS 1.2 | SHA256 | RSA | RC4_128 | MD5 | N | N |
| www.oberbank-banking.at | C | SSL3 – TLS 1.2 | SHA256 | RSA | AES_256_CBC | SHA | N | N |
Alle getesteten Seiten verwenden 2048 Bit RSA Zertifikate, weshalb diese Spalte nicht explizit angeführt ist. Die gelistete Cipher Suite ist jene, die laut SSL Labs mit Google Chrome 40 (OS X), Firefox 31 (Win 7) und Firefox 35 (OS X) als Browser ausgewählt wird.1
Die einzelnen Spalten der Tabelle haben folgende Bedeutung:
- Der Host, welcher mit SSL Labs’ testssl (SSL) und dig (DNSSEC) getestet wurde.
- Die Note, die durch SSL Labs vergeben wurde.
-
Die SSL/TLS Versionen, die unterstützt werden.
SSL3 gilt seit vielen Jahr als unsicher und spätestens seit Bekanntwerden der POODLE-Attacke sollte die Verwendung von SSL3 endgültig eingestellt werden. Der Nachfolger TLS-1.0 ist seit 1999 verfügbar und seit 2008 gibt es die aktuelle Version 1.2 des TLS Protokolls.
Angesichts der medialen Präsenz der POODLE-Attacke verwundert es, dass Oberbank selbst 5 Monate nach Bekanntwerden dieser schwerwiegenden Sicherheitslücke noch immer nicht reagiert hat, wo andernorts bereits nach wenigen Stunden auf eine derartige Lücke reagiert wird.
Die Sparanlage verwendet ebenfalls noch SSL3. Durch den Einsatz von RC4 sind sie zwar nicht unmittelbar von POODLE betroffen, allerdings ist RC4 selbst völlig veraltet und unsicher, siehe weiter unten.
Die Denizbank unterstützt nur das 16 Jahre alte TLS-1.0. Weiters unterstützen sie kein Secure Renegotiation, was gewisse Man-In-The-Middle Attacken ermöglicht.
-
Der Algorithmus für die Signatur der SSL Zertifikate.
Der Algorithmus SHA1 für die Signatur der SSL-Zertifikate gilt noch als sicher, sollte aber in naher Zukunft durch SHA256 ersetzt werden. Der Browser Google Chrome warnt in einer aktuellen Version bei einer SHA1 Signatur.
-
Der Algorithmus für den Schlüsselaustausch der verschlüsselten Verbindung.
Fünf von elf Seiten setzen veraltete Verfahren zum Schlüsselaustausch ein, die kein Forward Secrecy unterstützen. Ohne Forward Secrecy ist es möglich durch das Stehlen der geheimen Schlüssel am Server sämtliche in der Vergangenheit aufgezeichnete Kommunikation rückwirkend zu entschlüsseln. Im April 2014 wurde durch die medienwirksame Heartbleed-Attacke eine schwerwiegende Sicherheitslücke bekannt, durch welche die geheimen Schlüssel gestohlen werden konnten.
Forward Secrecy wird ausschließlich durch die ephemerel-Varianten der Diffie-Hellman Algorithmen (ECDHE und DHE) geboten.
-
Der Algorithmus für die Verschlüsselung.
Der AES Algorithmus gilt als sicher. Der GCM-Modus von AES bietet authentifizierte Verschlüsselung und ist seit TLS-1.2 verfügbar. Andere Verschlüsselungsalgorithmen brauchen zusätzlich einen MAC (Message Authentication Code) Algorithmus um die Authentizität des verschlüsselten Textes zu prüfen.
AES im CBC Modus hat eine notorische Anfälligkeit für Padding Attacken, siehe etwa BEAST, Lucky Thirteen, oder POODLE. Mit TLS-1.1 gibt es eine Lösung für diese Art von Angriffen, bei TLS-1.0 hängt die Anfälligkeit vom Browser ab.
3DES gilt als schwacher Verschlüsselungsalgorithmus.
RC4 hat eine lange Liste von bekannten Angriffen seit den 1990er Jahren und gilt heute als gänzlich unsicher.
-
Der Algorithmus zur Prüfung der Authentizität der verschlüsselten Daten.
Der SHA256 Algorithmus gehört zur SHA-2 Familie und gilt derzeit als Gold-Standard.
Der SHA(1) Algorithmus sollte in den nächsten Jahren durch modernere Varianten der SHA-2 Familie ersetzt werden, gilt aber trotz theoretischer Fortschritte in der Kryptoanalyse noch als sicher.
MD5 gilt als unsicher und sollte auch laut RFC 5246 nicht mehr verwendet werden.
-
Die serverseitige Unterstützung von HSTS.
HSTS (HTTP Strict Transport Security) ist eine Maßnahme, die es Angreifern erschwert Man-In-The-Middle Attacken durchzuführen, indem der Browser angewiesen wird stets via HTTPS mit dem Server zu kommunizieren, selbst wenn der Browser zu einer HTTP-URL geführt wird. HSTS am Sever zu unterstützen ist eigentlich eine Trivialität und deshalb ist es unverständlich, warum 4 von 11 Banken dieses einfache Sicherheitsfeature nicht unterstützen.
-
Der Einsatz von DNSSEC für die betroffene Domain.
Keiner der getesteten Domains verwendet DNSSEC, obwohl zumindest manche Betreiber auf eine Anfrage im Jahr 2013 bekannt gaben, dass sie um die Bedeutung von DNSSEC Bescheid wissen: Ohne DNSSEC ist es technisch nicht möglich festzustellen, ob die Übersetzung des Hostname zur IP-Adresse von einem Angreifer verändert wurde, und der Browser einen falschen Server kontaktiert.
Zu Paypal ist anzumerken, dass zwar paypal.com durch DNSSEC abgesichert ist, aber www.paypal.com ein CNAME für e6166.a.akamaiedge.net ist, und hierfür gibt es keine Umsetzung von DNSSEC, wodurch erst keine Absicherung durch DNSSEC erfolgen kann.
dig +dnssec www.paypal.com [...] www.paypal.com. 185 IN CNAME www.paypal.com.akadns.net. www.paypal.com. 185 IN RRSIG CNAME 5 3 300 20150426212009 20150327203758 11811 paypal.com. S++C5SdePv056suQMJ2Zd8xwvlP8qmZjktuM7EEdj/jgjTVaio+h7h0K hyetSzinrHL3TStloZcMXBH+yVKUyClBr1Lqoc9LIqB81fkn9uiPiVdM ewDmaOQibi9YNAWWzTfLYFoUPrxaL3kXky90/hJzwKP2Iq1+xKZ1L3Ym 3gM= www.paypal.com.akadns.net. 17 IN CNAME ppdirect.paypal.com.akadns.net. ppdirect.paypal.com.akadns.net. 186 IN CNAME wlb.paypal.com.akadns.net. wlb.paypal.com.akadns.net. 17 IN CNAME www.paypal.com.edgekey.net. www.paypal.com.edgekey.net. 486 IN CNAME e6166.a.akamaiedge.net. whois akadns.net | grep -i DNSSEC DNSSEC: Unsigned
-
Bei Paylife bezieht sich die zweite Zeile auf die beiden Firefox Varianten. Bei Volksbank bezieht sich die zweite Zeile auf Firefox 31. ↩