Troy Hunt had a great writeup of the atrocious state of SSL in the Australian retail bank sector, and the poor standards that the banks hold themselves to. Troy used Qualys' useful SSL validation tool, the SSL Labs Server Test. Now, while it performs a wide breadth of testing of a given server's SSL implementation, the 'grade' given to a site can be a little misleading when it comes to comparing sites with middling grades, so looking at a few key attributes is necessary, along with considering just the raw score.
The last few years have seen SSL and TLS come under significant attack; the industry believes by and large that SSLv3 is too broken for the public internet, and both clients and servers should move to TLS. We have seen hilariously-named attacks like Poodle, Freak, Logjam and Heartbleed that require urgent attention from system administrators to keep systems secure. On the defence side, we have also seen features such as HTTP Strict Transport Security (HSTS) and HTTP Public Key Pinning (HPKP) added to HTTP to avoid clients relying on unencrypted connections or forged TLS certificates.
Fortunately, most of the technology industry has been highly reactive to OpenSSL (and other) vulnerabilities that have been published. Sadly, that does not seem to have carried through to the defensive, planned side of IT security. This seems to be even more true in the banking industry, perhaps due to the bureaucratic nature of many banks' IT deployment processes and the lack of any customer-visible improvement in security that these measures introduce.
Given the poor state of security across Australian banks, I thought it about time to have a look at the American retail bank industry, and see how they perform. All of these scans were performed on 2015-05-25 and 2015-05-26, and may not reflect (what I hope will be) future improvements made to these banks' online banking platforms.
| Bank | SSL Labs Grade | SSL3 Rejected | TLS 1.2 Supported | No SHA-1 in Cert Chain | RC4 Ciphers Disabled | Forward Security Enabled | Not vulnerable to POODLE | HSTS Implemented | HPKP Implemented |
|---|---|---|---|---|---|---|---|---|---|
|
Citibank online.citibank.com |
A-/C | Pass | Some Failed | Some Failed | Some Failed | Fail | Pass | Fail | Fail |
| Citibank would have done extremely well if if were not for two problems: the lack of forward secrecy ciphers enabled on the main online.citibank.com host, which received the A- grade, and the horrific configuration of the www.citibank.com redirector. The redirector received a 'C' grade from SSL Labs. The redirector host has a short and awful list of ciphers enabled (RSA-RC4, RSA-3DES), uses SHA-1 signatures on the certificate chain, and does not support TLS 1.1 or 1.2. | |||||||||
|
PNC Bank www.pnc.com, www.onlinebanking.pnc.com |
B | Pass | Pass | Pass | Fail | Pass | Pass | Fail | Fail |
| PNC is one of the few banks to have enabled ciphers that allow for forward secrecy, and to have enabled them correctly, at the start of the server cipher list. Save for keeping RC4 enabled, they're doing pretty well. | |||||||||
|
US Bank www.usbank.com, onlinebanking.usbank.com |
B | Pass | Pass | Pass | Fail | Fail | Pass | Some Failed | Fail |
| US Bank's use of HTTP Strict Transport Security on their homepage (www.usbank.com) but failure to enable the same for their onlinebanking.usbank.com strikes me as a little weird. Aside from that and permitting RC4, they're doing pretty well. | |||||||||
|
JPMorgan Chase chase.com, www.chase.com, chaseonline.chase.com, mfasa.chase.com |
B | Pass | Pass | Fail | Fail | Fail | Pass | Fail | Fail |
| The server-side cipher preferences seem to be in an odd order, preferring TLS_RSA_WITH_AES_* suites above TLS_ECDHE_RSA_WITH_AES suites, effectively negating newer browsers' support for forward secrecy. Chase also use SHA-1 signatures in their certificate chain. | |||||||||
|
BB&T Bank www.bbt.com, online.bbt.com |
B | Pass | Pass | Pass | Fail | Fail | Pass | Fail | Fail |
| BB&T does pretty well, aside from the inclusion of RC4 (albeit, at the end of the cipher list) and the lack of ciphers allowing for forward secrecy. The preferenced cipher (RSA-AES-GCM) is well-respected. | |||||||||
|
Capital One capitalone.com, www.capitalone.com, servicing.capitalone.com |
B | Pass | Pass | Fail | Fail | Fail | Pass | Fail | Fail |
| The main domain, capitalone.com, relies on a certificate chain with SHA-256 signatures, but the online banking host, servcing.capitalone.com, includes SHA-1 signatures in the certificate chain. | |||||||||
|
Bank of America bankofamerica.com, www.bankofamerica.com, secure.bankofamerica.com |
B/C | Pass | Pass | Some Failed | Fail | Fail | Pass | Fail | Fail |
| bankofamerica.com, which appears to be a simple redirector to www.bankofamerica.com, has a weaker certificate chain (SHA-1 signatures, vs. SHA-256), and causes newer browsers to still use RC4 by suggesting TLS_RSA_WITH_RC4_128_SHA as the first cipher. | |||||||||
|
Wells Fargo www.wellsfargo.com, connect.secure.wellsfargo.com |
C | Pass | Pass | Fail | Fail | Fail | Pass | Fail | Fail |
| Wells Fargo include TLS_RSA_WITH_RC4_128_SHA as their first cipher, effectively forcing all modern browsers to use RC4 rather than a more-modern AES with GCM. | |||||||||
|
TD Bank www.tdbank.com, onlinebanking.tdbank.com |
C | Pass | Pass | Fail | Fail | Fail | Pass | Fail | Fail |
| TD Bank repeats a common mistake, TLS_RSA_WITH_RC4_128_SHA as their first cipher, effectively forcing all modern browsers to use RC4. | |||||||||
|
HSBC USA www.us.hsbc.com, www.security.us.hsbc.com |
C | Fail | Pass | Fail | Fail | Fail | Timeout | Fail | Fail |
| Including support for SSL3 is a large problem, as the protocol is known to be flawed, as compared to TLS. HSBC also repeats a common mistake, TLS_RSA_WITH_RC4_128_SHA as their first cipher, effectively forcing all modern browsers to use RC4. Additionally, their main website reproducibly times out when testing for POODLE on TLS, leading to an inconclusive result. | |||||||||
|
Ally Bank www.ally.com, securebanking.ally.com |
C | Pass | Pass | Pass | Fail | Fail | Pass | Fail | Fail |
| Ally include two RC4-based ciphers as their first preference in the server cipher list, effectively forcing all browsers to use RC4. Interestingly, they do not support secure protocol renegotiation, unlike most other banks. | |||||||||
|
American Express www.americanexpress.com, online.americanexpress.com |
B/C | Pass | Some Failed | Pass | Fail | Fail | Pass | Fail | Fail |
| American Express's cipher selection leaves a lot to be desired; for their online banking portal, they offer RC4 as a first preference. For their main site, they offer multiple blasts from the past; 3DES, IDEA, RC4 and single DES. Yes, TLS_RSA_WITH_DES_CBC_SHA. Wow. Their online banking site only supports TLS 1.0, neglecting to include support for TLS 1.1 or 1.2. | |||||||||
|
New York Mellon www.bnymellon.com, connect.bnymellon.com |
Fail | ||||||||
|
SunTrust Bank www.suntrust.com, onlinebanking.suntrust.com |
Fail | ||||||||
| These two banks I consider to have completely failed. They have gone out of their way to contact Qualys and blacklist their hosts for SSL testing, making it harder for potential customers to assess their security. Good security is defensible when subjected to analysis. | |||||||||
A considerable number of American banks rely on certificates in their certificate chain that are signed with SHA-1. SHA-1 is in the same position MD5 was ten years ago; attacks on SHA-1 are getting cheaper, and it is not particularly defensible for new software or certificates to be using SHA-1, when improved signature algorithms like SHA-256 are widely available. Browser vendors will be progressively sunsetting support for SHA-1-signed intermediate and leaf certificates over 2015 and 2016, and all websites should ensure that they generate new certificates using SHA-256 if they have not done so already.
A number of banks seem to have placed their server cipher suites in a poorly-selected order; JPMorgan Chase for example places their TLS_RSA_WITH_AES_* cipher suites above TLS_ECDHE_RSA_WITH_AES_* suites, effectively negating any ability for mainstream browsers to negotiate a cipher that offers forward security. Thankfully, they do at least place their 3DES and RC4 cipher suites at the end, but placing ECDHE after plain RSA seems like a mistake during implementation that should have been caught.
Of course, cipher selection is an area where many people in the industry may have vociferous opinions, and I'd expect subtle differences from bank to bank. That said, there are many cases in the banks listed above where it is clear that the cipher ordering is wrong, and should be reviewed (e.g. placing RC4 ciphers as the first choice, or listing ECDHE ciphers towards the end of the list, or including single DES cipher suites).
Speaking of single DES cipher suites, a good number of banks include ciphers that are considered beyond their prime, or simply broken. After the BEAST attack was released, many administrators moved to promote RC4 in their cipher suite list in order to mitigate the attack, as RC4 is one of the few stream ciphers available in TLS. As time has moved on though, RC4 is now considered pretty broken by many, and really should be either be removed, or at least demoted in your servers' cipher suite lists.
One thing that stuck out to me is that, of all the US banks I looked at, only a single bank (US Bank) implemented strict transport security. As the name suggests, the use of the Strict-Transport-Security enforces a strict requirement for all traffic to that hostname to take place over a secured connection. Websites can set a maximum time for this transport security requirement, and it is recommended that this maximum time is specified as a period of months or more, to protect infrequent visitors to the site. Ideally, the time should be on the order of one year.
If you are certain that your site will remain accessible via HTTPS, browser vendors are offering the ability to pre-load your domain into the HSTS list rolled out with Chrome, Firefox and Safari.
A related technology is HTTP Public Key Pinning, which allows websites to specify two or more public keys that will only be trusted for the domain - that is, if a third party obtains a certificate for that domain, the additional certificate will not be accepted if a HPKP header has previously been sighted that does not include the third party's public key. This is a great way to avoid man-in-the-middle attacks, but it does require discipline in key management, and the acquisition of a second certificate ahead of time for recovery purposes.
Another common refrain sighted amongst banks was the abandoned redirector. For example, servers that live at bank-domain.com that live only to redirect to www.bank-domain.com, or another permutation thereof. These redirectors are often hosted on secondary machines and may not be updated along with the primary web hosts. It is still important for organisations to keep these hosts up to date with SSL cipher changes and other vulnerabilities, as any customer attempting to access the bare domain will make use of those poorly-protected connections, and may be vulnerable to man-in-the-middle attacks.
An additional consideration is to enable HTTP Strict Transport Security on your redirectors and submit them for pre-loaded inclusion, in order to protect your users' first requests to your domain from being attacked.
All of the banks listed above, with the sole exception of US Bank's main website (but not their online banking) do not negotiate cipher suites with modern browsers that allow for forward secrecy. Forward secrecy is a property of a ciphersystem that, when correctly implemented, allows an attacker with posession of the keys to review the data transmission after the fact, and still be unable to read the plaintext. TLS achieves this by introducing the ephemeral Eliiptic Curve Diffie-Hellman cipher suites, where both parties will generate a random public key for the Diffie-Hellman phase, and not record the generated keys.
Where supported by the servers and load balancers in question, ECDHE cipher suites should be enabled and preferenced over non-forward-secrecy providing ciphersuites.