Although SSLv3 has been considered obsolete and insecure for a long time, a large number of web servers still support its use. And even though the numbers are much lower, some servers on the web support SSLv2 to this day as well. And, as it turns out, this is true even when it comes to web servers hosting internet banking portals…

Tests of SSL/TLS configuration are usually conducted as a normal part of a vulnerability scan or penetration test of TLS-enabled servers. But even when done as a stand-alone activity, they can provide us with very interesting information, especially when the targets are highly-sensitive servers, such as the ones used to provide internet banking services. That is the reason why many people and organizations have published analyses and statistics of TLS configuration of banking sites over the years[1]. I’ve actually done so myself a couple of times[2]. Most, if not all of such analyses have however been limited in scope and covered only a specific country or region.

For a long time, I’ve wanted to try to do a similar analysis on a global scale and when a colleague of mine provided me with a list of nearly 1,500 unique internet banking sites from all around the world earlier this year, I couldn’t let the opportunity pass. Even though 1,459 unique internet banking domains might not sound like much, when one considers that there appear to be between 25,000 and 85,000 banks overall[3], and not all such institutions provide internet banking services, it is actually not a bad sample size.

Before we get to the analysis and its results, let’s take a short look at TLS.

At this point in time, SSL and TLS have been used to secure communication over untrusted networks for almost 25 years[4]. The protocols, as well as the cipher suits which they use, have evolved significantly over time in reaction to discovered vulnerabilities and weaknesses. This cycle has led us to the current state of affairs, when, according to the current best practices[5], it is advisable to use TLSv1.2 and TLSv1.3 only, unless there is a special reason to use/support an older version or the protocol. But even though TLSv1.0 and TLSv1.1 are now considered outdated and will probably stop being supported by browsers in the near future[6], these protocols still provide a significantly higher level of security then SSLv3 (which was itself a notable improvement over SSLv2).

A large number of tools can determine which protocols and cipher suites a server supports[7]. In this case, I’ve decided to use Nmap, since its scans are fairly quick and it has couple of scripts (ssl-enum-ciphers.nse and sslv2.nse), which can provide us with almost all the information we might want with regards to SSL/TLS. The only drawback is that SSL/TLS enumeration capabilities of Nmap currently lack support for TLSv1.3[8], which is the reason why you won’t find statistics for use of the latest version of TLS protocol mentioned bellow.

After deciding to use Nmap, I fed the list of internet banking domains to it and had it output the results to XML. The ssl-enum-ciphers script gives us – among other data – information about all the protocols and cipher suits used by a server and marks them on a scale A to F, based on the security they provide, using a slightly modified version of the SSL Server Rating Guide methodology[9,10]. Since this script can however only identify use of SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 and I wanted to identify SSLv2 support as well, I’ve used it in a tandem with the sslv2 script, which provides this functionality. Once the scan was done, I generated a CSV from the resulting XML using a quick-and-dirty Python tool I wrote for parsing outputs of both Nmap scripts and I delved into analyzing it.

Due to several servers being unreachable, broken DNS records and other error conditions, Nmap didn’t manage to get data for all domains from the original list, but for “only” 1375 domains from 143 TLDs. The information I was most interested in for each server was a list of supported protocols and a mark for the weakest cipher suite, along with data about vulnerabilities and weaknesses related to SSL/TLS which Nmap managed to identify (specifically SWEET32, POODLE and use of RC4).

Given how sensitive the communication sent to internet banking servers is, the results were quite surprising – one server was actually affected by POODLE, 4 servers managed to hit the worst mark (F) for the weakest supported cipher suite, more than 3% of the servers supported SSLv3 and almost 1% (11 servers) still even supported SSLv2. Since there hasn’t been a reason use SSLv3 for a long time (barring exceptional cases), one might not expect to find it – not to mention SSLv2 – supported on any web server that provides a service for which ensuring confidentiality of its network traffic is paramount…

As you may see, the results didn’t look especially good – they were notably worse than I would have expected for internet banking servers. I wasn’t sure, however, whether they were on average worse or better than results for any other high-profile sites. I therefore decided to look for a “baseline” I might be able to compare the results against. I ended up choosing the Top 1000 Sites from Alexa, as – although most of these are not as sensitive as the internet banking sites – they are high-profile enough so that we might expect that reasonable security standards are enforced on them.

Scan of the 1000 sites resulted in only 921 results from 78 TLDs. The reason was that some of the second-level domains which were present on the Alexa list didn’t have any DNS records set (i.e. cloudfront.net, twimg.com, etc.). As you may see bellow, in some areas the banking sites did better than our baseline, while in others they did worse. On average it seems that while the Alexa Top 1000 sites are all over the map when it comes to SSL/TLS configuration, it appears that while most banking sites are configured very well, a notable minority seems to be configured quite badly.

The following chart shows overall support for all protocols. It should be mentioned at this point, that although support for TLSv1.2 was generally quite high in both samples, only 23.7% of banking sites and 14.7% of Alexa sites supported only TLSv1.2 (and possibly TLSv1.3) and were therefore configured according to the current best practices.

When it comes to vulnerabilities, the internet banking servers seem to be better configured then the “Top 1000” sites (although even one vulnerable internet banking server would seem one too many). Almost half (49.19%) of the Alexa sites and almost one third (30.55%) of the internet banking servers were vulnerable to SWEET32, 7 banking sites (0.59%) were found to still support RC4 while there were 12 such sites (1.30%) on the Alexa list. On the same list were also 5 sites (0.54%) still affected by POODLE, while – as was mentioned above – there was “only” 1 such site (0.07%) among the internet banking servers.

While the most common SWEET32 vulnerability isn’t that bad, POODLE and the continued use of RC4 are definitely worrisome (for more information, see Bojan’s webcast at https://www.sans.org/webcasts/111400).

Although the above mentioned statistics definitely don’t give us the entirety of the situation and should not be taken out of context, they are quite unsettling. They seem to indicate that even when it comes to internet banking sites, security doesn’t always get the attention it should. This is especially well illustrated by the continued support of deprecated SSL protocols on several of the sites. Which – from a purely technical standpoint – is actually quite interesting, given that most browsers today have support for SSLv2 and SSLv3 turned off by default…

[1] https://www.scmagazineuk.com/uk-high-street-banks-accused-shockingly-bad-online-security/article/1477266
[2] https://www.systemonline.cz/clanky/ne-bezpecnost-internetoveho-bankovnictvi-v-cr.htm
[3] https://www.linkedin.com/pulse/how-many-banks-globally-david-gyori
[4] https://en.wikipedia.org/wiki/Secure_Sockets_Layer
[5] https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
[6] https://www.thesslstore.com/blog/apple-microsoft-google-disable-tls-1-0-tls-1-1/
[7] https://isc.sans.edu/forums/diary/Verifying+SSLTLS+configuration+part+1/25162
[8] https://github.com/nmap/nmap/issues/1348
[9] https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
[10] https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

-----------
Jan Kopriva
@jk0pr
Alef Nula