Secure SSL / TLS Russian Internet Banking

Today, many people and organizations use the services of Internet banking. Banks periodically conduct security audits of their systems, issue instructions and recommendations for safe operation of the Internet Bank, but users do not always know whether the connection to the Internet Bank they are used to using is well protected.



In this article, we will assess the security of connections to the online services of the TOP 50 Russian banks (by assets) .



The security of user connections to Internet banks is ensured by the use of SSL / TLS protocols. Currently known are “loud” SSL / TLS vulnerabilities, which even were given names and / or logos (Beast, Poodle, Heartbleed, Freak, Logjam). The well-known SSL / TLS vulnerabilities also allow decrypting sessions, intercepting and replacing data transmitted between the user and the server, which for obvious reasons is overlooked by most users.

')

Often the problem lies in the use of outdated and weak cryptoalgorithms with the current level of computing power, and somewhere by the presence of unresolved vulnerabilities of the software used. All this jeopardizes the security of payments made by users in Internet banks.

SSL / TLS security level of Russian banks

To assess the security level of the SSL / TLS configuration on the servers, you can use the free tool “SSL Server Test” from Qualys SSL Labs. Using this tool, independent researcher Troy Hunt made a summary of the appropriate level of security for Australian banks .



In the comments to the article of Troy, you can see links to similar tables for different countries: Lithuania , Denmark , Holland , Holland-2 , Czech Republic , United Kingdom .



I have prepared a similar table (dated 05.22.15) for TOP-50 Russian banks.

In general, the situation is far from ideal. Among the top ten banks, there are four F ratings and this is a bad indicator compared to other countries.



Except for Logjam, quite a lot of time has passed since the discovery of these vulnerabilities and problems of protocols / cryptoalgorithms, which at least indicates the lack of periodic monitoring by many banks of the security of their web resources or of corresponding compensating measures.



Each web resource is assigned a score of "SSL Server Test" with a scale from A to F. A plus and a green color means that there is no corresponding vulnerability / problem. Minus and red color indicate otherwise. Some web resources could not be verified for the reasons given in the table.







The full table (TOP-50) is available at the link: drive.google.com/file/d/0B6tNPM-Uwa5ZNWJkcFRuWjlkYk0/view

Main conclusions

• Some banks still use insecure Diffie-Hellman key exchange options with a key length of 512 and 768 bits, which automatically lowered their overall score to “F” (this is also the case in the top ten). Vulnerable resources are marked by minuses in the "DH" column.
• Some banks are vulnerable to FREAK attacks , which reduced their overall rating to “F”. Using this vulnerability, attackers can force the use of weak cryptography from the export RSA cipher by the client browser. Vulnerable to attack resources are marked by minuses in the "Freak" column.
• A large part of the web resources has a vulnerability POODLE , which reduced their overall assessment to "F". Using this vulnerability, attackers can gain access to encrypted information transmitted between the client and the server. Basically, these are insecure SSL3 vulnerabilities and can be resolved by disabling SSL3 on web servers. In two cases, TLS is vulnerable to the POODLE protocol and a patch is required to fix the vulnerability. Vulnerable to attack resources are marked by minuses in the "POODLE" column.
• Several banks still use the insecure SSL2 protocol, which reduced their overall rating to “F”. The SSL2 protocol uses an insecure MD5 hash function and weak ciphers. MITM attacks are possible due to lack of SSL confirmation. In addition, SSL2 also uses the TCP FIN flag to close a session that can be spoofed, due to which the user will not know whether the data transfer has been completed. Resources with support for SSL2 protocol are marked by minuses in the column "SSL2".
• Much of the web resource has a recent vulnerability Logjam . The presence of a vulnerability reduced the overall rating to “B”. Like the FREAK vulnerability, Logjam allows an attacker to force the use of weak DH cryptography with 512-bit keys by the client browser. Vulnerable to attack resources are marked by minuses in the “Logjam” column.
• A significant proportion of banks still use the outdated and insecure SSL3 protocol, which reduced their overall rating to “B”. Resources with support for the SSL3 protocol are marked with minuses in the “SSL3” column.
• Some web resources do not support the latest and most secure version of the TLS 1.2 protocol, which reduced their overall rating to “B”. Resources that do not support the TLS 1.2 protocol are marked by minus in the "TLS1.2" column.
• Most banks still use RC4 ciphers, which reduced their overall rating to “B”. RC4’s vulnerability is due to the lack of randomness of the bit stream with which the message is scrambled, which allows decrypting the intercepted data. Resources with support for the RC4 cipher are marked by minuses in the "RC4" column.
• The vast majority of banks still use the SHA-1 hash algorithm, which is considered weak and unsafe. Already, web browsers assign different statuses to connections with SHA-1 (“safe, but with errors”, “insecure”, “untrusted”). Ignoring the current rejection of SHA-1, banks accustom their users to ignore such statuses and browser messages. The use of SHA-1 had almost no effect on the overall assessment and was marked by minuses in the “SHA-1” column.
• In the overwhelming majority of banks, Forward Secrecy is not implemented or partially implemented the security of the key agreement protocols. When using Forward Secrecy, session keys will not be compromised when the private key is compromised. Resources that do not use Forward Secrecy for most modern browsers are marked by minuses in the “FS” column.
• It is worth noting that the Heartbleed vulnerability is fortunately not detected on any of the tested web resources.

These estimates lose their relevance over time, which may require rechecking using the SSL Server Test. For example, at the time of writing, the assessment of the Telebank web server VTB24 changed from “F” to “A-”, and the vulnerability of Poodle was eliminated on the website of the Rosbank Internet Bank.

Recommendations

The results of the SSL Server Test checks provide recommendations for resolving the identified problems, which can be summarized into the requirements for configuring SSL / TLS on web servers:

• Disable support for insecure protocols SSL2, SSL3.
• Enable support for the most advanced TLS 1.2 protocol.
• Stop using SHA-1 certificates.
• Stop using RC4 cipher.
• Configure Forward Secrecy and ensure that the feature works for most modern browsers.
• Eliminate the Poodle vulnerability by disabling the SSL3 protocol, or by installing a patch for the TLS protocol vulnerability.
• Eliminate the Freak vulnerability by disabling the support for exporting cipher suites.
• Eliminate the Logjam vulnerability by disabling the support for exporting cipher suites and generating a unique 2048-bit Diffie-Hellman group.

Users are also advised to carefully disable SSL 2.0 and SSL 3.0 in the browser settings and enable TLS 1.0, TLS 1.1 and TLS 1.2 support (cautiously, because there were banks supporting only SSL 3.0 from the server). And, of course, when connecting, users should take a closer look at the server certificate and its status in the browser.