Cryptographic setups of e-banking websites in Austria

E-banking users rely fundamentally on the security level established by HTTPS connections between their browser and the web server. The actual level of security depends on the proper setup of multiple cryptographic components. In this little survey, we have a look on the different settings of e-banking websites of various banks in Austria.

An introduction to TLS

A HTTPS connection between a browser and a server is basically an ordinary HTTP connection on top of a TLS connection. The TLS protocol is responsible for providing a secure connection between browser and server. It provides the following two essential features:

  • Confidentially. A symmetric encryption algorithm is used to encrypt the traffic between browser and server. The key that is used for the symmetric encryption is exchanged through a cryptographic key exchange algorithm.

  • Integrity. For every piece of data (message) that is sent in either direction, a so-called message digest is computed using a message authentication algorithm. Any modification in the data made by an attacker is noticed by a non-matching digest.

For each of the three “black-box algorithms” mentioned above different concrete algorithms exist. A cipher suite is a set of algorithms — one specific algorithm is selected for each of the three black boxes. For instance, the cipher suite ECDHE-RSA-AES256-GCM-SHA384 uses ephemeral elliptic curve Diffie-Hellman as key exchange algorithm using RSA to authenticate the key agreement, AES in GCM mode with 128-bit keys for encryption, and SHA384 for message authentication.

Typically, the sever can deal with a set of cipher suites and has a preference list and the browser knows a set of cipher suites as well. A negotiation process within TLS between server and browser decides which cipher suite to use. Different versions of the TLS protocol support different cipher suites and in general more recent servers and browsers support more recent and better cipher suites.

At the bottom line, not every HTTPS connection is equally secure; in fact, quite the opposite is true.

Current deployment status

In the following table, we summarize the protocol version of TLS, the key exchange algorithm, the symmetric encryption algorithm, and the message authentication algorithm for the e-banking websites of different financial institutes. The underlying color roughly indicates the level of security, where a saturated green means very good and red means very bad.

Hostname TLS Key exch. Encryption Msg. auth.
netbanking.sparkasse.at 1.2 ECDHE_RSA AES_128_GCM SHA384
ebanking.bawagpsk.com 1.2 DHE_RSA AES_128_GCM SHA384
ebanking.easybank.at 1.2 DHE_RSA AES_128_GCM SHA384
www.kreditkarte.at (PayLife) 1.0 DHE_RSA AES_256_CBC SHA1
online.bankaustria.at 1.2 RSA AES_256_CBC SHA1
www.paypal.com 1.2 RSA AES_256_CBC SHA1
www.sparanlage.at (new) 1.2 RSA AES_256_CBC SHA1
banking.hypo.at 1.1 RSA AES_256_CBC SHA1
banking.raiffeisen.at 1.1 RSA AES_256_CBC SHA1
www.banking.co.at (Volksbank) 1.0 RSA AES_256_CBC SHA1
www.oberbank-banking.at 1.0 RSA AES_256_CBC SHA1
www.sparanlage.at (old) 1.0 RSA RC4_128 MD5

Some remarks:

  • The above table lists the cipher suites used when connecting with the browser chromium-32.0 or openssl-1.0.1f. Using openssl, one can obtain the above values by calling

    % openssl s_client -connect www.sthu.org:https 2> /dev/null | \\
grep -E "(Cipher|Protocol).*:"
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384

    If one is interested in the list of all cipher suites supported by a particular web server, one can use sslscan.

  • Currently, TLS is available in version 1.0, 1.1 and 1.2. Version 1.0 has been introduced in 1999, version 1.1 in 2006 and 1.2 in 2008. With TLS 1.1 some protections against CBC-based attacks were added. With TLS 1.2 the MD5/SHA1 based pseudo-random number generator was replaced with one based on SHA256. Also the GCM mode for AES encryption was added, where the AES encryption becomes authenticated.

  • The key exchange algorithms based on ephemeral Diffie-Hellman (DHE_RSA and ECDHE_RSA) provide forward secrecy. Without forward secrecy the encrypted communication of today can be compromised in the future if the traffic is taped and the (long-term) key is compromised at any point in the future.

  • The encryption algorithms based on AES can be considered secure. However, the CBC mode of operation has a history of attack techniques, such as BEAST. TLS 1.1 contains a fix for those attacks. With TLS 1.0, it still depends on the browser vendor to mitigate this attack. The RC4 algorithm has a long history of attacks starting in the 90s and is considered broken.

  • SHA384 is part of the SHA-2 family and considered secure. For SHA1 theoretical attacks were published, but in practice SHA1 has not yet been defeated. The MD5 algorithm, on the other hand, is considered broken. In particular, RFC 5246 already remarked in 2008:

    Due to significant progress in cryptanalysis, at the time of publication of this document, MD5 no longer can be considered a ‘secure’ hashing function.

  • After notifying the contact person of www.sparanlage.at about their weak cipher suites, they upgraded their setup accordingly. In order to paint a picture prior my mail, I also added the old setup. In fact, I was motivated to investigate the TLS setups of different e-banking websites after reading in the FAQ of www.sparanlage.at that they would use the best-possible encryption techniques, while still sticking with RC4 and MD5:

    Die sparanlage.at Seite ist mit den bestmöglichen Verschlüsselungstechniken gesichert. Dabei verwenden wir die höchstmögliche Verschlüsselungsform: eine 128bit - Verschlüsselung.

    It turns out that the web server behind www.sparanlage.at is also vulnerable to client-initiated renegotation. That means, it is possible for the browser to renegotiate the cipher suite during an ongoing communication session.

    Using the command ‘R’ of openssl, one can initiate a renegotiation request. Typically, the connection is terminated as a consequence:

    % openssl s_client -connect www.sthu.org:https
[...]
GET /index.html HTTP/1.1
R
RENEGOTIATING
139893172836008:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:596:

    In case of www.sparanlage.at, however, this is not the case:

    % openssl s_client -connect www.sthu.org:https
[...]
GET /index.html HTTP/1.1
R
RENEGOTIATING
[...]
Host: www.sparanlage.at

HTTP/1.1 302 Found
Date: Mon, 17 Feb 2014 15:11:23 GMT
Server: Apache
Location: https://www.sparanlage.at
Content-Length: 209
Connection: close
Content-Type: text/html; charset=iso-8859-1
[...]

    The website ssllabs provides a web service to test web servers for such weaknesses.

I also found it interesting how widely HSTS (HTTP Strict Transport Security) is in use. When this feature is turned on at the web server, a browser is directed to access this website using HTTPS only, even if a user navigates to a HTTP URL. The table below shows which sites provide HSTS at the moment. In addition, I recorded the certificate authorities and the web server software in use. Some servers, however, did not report their name in the respective HTTP header. Using HTTP fingerprinting tools may reveal more information. For instance, the web server behind online.bankaustria.at sends the HTTP header IBM-Web2-Location.

Hostname HSTS CA Web server
netbanking.sparkasse.at yes VeriSign Class 3 Ext. Val. SSL CA Apache
ebanking.bawagpsk.com no VeriSign Class 3 Int'l Server CA - G3 Apache
ebanking.easybank.at no VeriSign Class 3 Int'l Server CA - G3 Apache
www.kreditkarte.at (PayLife) no VeriSign Class 3 Ext. Val. SSL CA Apache
online.bankaustria.at no VeriSign Class 3 Ext. Val. SSL SGC CA ?
www.paypal.com no VeriSign Class 3 Ext. Val. SSL CA Apache-Coyote/1.1
banking.hypo.at yes VeriSign Class 3 Int'l Server CA - G3 ?
banking.raiffeisen.at yes VeriSign Class 3 Int'l Server CA - G3 ?
www.banking.co.at (Volksbank) yes VeriSign Class 3 Int'l Server CA - G3 IBM_HTTP_Server
www.oberbank-banking.at no VeriSign Class 3 Int'l Server CA - G3 Apache-Coyote/1.1
www.sparanlage.at no Thawte SSL CA Apache

Conclusion

It is not justified to assume that websites in a security-sensitive domain like banking would employ state of the art security technology. Despite the fact that TLS 1.0 is 15 years old and the successor is available for 8 years, still 4 out of 11 websites used TLS 1.0. Even though CBC mode in conjunction with TLS 1.0 comes with a risk of broken encryption at the client side, 3 out of 11 websites use this mode. Even worse, www.sparanlage.at used to employ RC4_128 and MD5, which are both considered broken for several years. On the upside, they switched to a more secure cipher suite in less than two working days after writing a mail that elaborated the issue. Finally, a wide-spread issue is absent forward secrecy in 7 out of 11 cases.

Acknowledgments. Thanks go to Peter Palfrader for various hints and suggestions for improvements in the presentation.