TLS 1.3: Impact for the Financial Industry [PART 1]
Last March the IETF finalized and approved version 1.3 of TLS and last month "formal" publication as RFC 8446  followed, but what do you know about it? What will it mean for you? Well get ahead of the game in UL’s latest insight on this new update to the TLS protocol. Version 1.3 is the first major upgrade in 10 years to the "Transport Layer Security" (TLS) protocol that is one of the most widely used to protect communications on the Internet and beyond.
As version 1.3 presents a substantial update, it will take quite some time for the industry to fully roll out the new standard. Contrary to the previous version 1.2, uptake of the new 1.3 version is to be expected sooner. Various browsers, components (such as libraries) and other applications already have (experimental) support for the new standard.
What is new?
TLS version 1.3 has improvements in general, that make it faster, more secure and with a cleaner design. The speed improvement should be most noticeable on high-latency connections, as less roundtrips are required.
With version 1.3 of TLS come a few changes. Not all of them are listed here, but we highlight the ones that are most relevant to the financial industry:
- Updates to cryptographic algorithms, only supporting strong cryptography and support for a few new algorithms. Most noteworthy are the addition of the ChaCha cipher as fallback algorithm for AES and inclusion of Elliptic Curve Cryptography (ECC) ciphers in the base specification.
- Removal of static key exchange/establishment algorithms, effectively requiring "forward secrecy".
- The initial handshake was revised, allowing for faster (re)establishment of connections as well as removal of the previously plagued "renegotiation".
- Other improvements to the protocol, providing more flexibility due to the structural usage of extensions, enhancing the security and cleaning up in general.
TLS 1.3 Benefits
Version 1.3 has several benefits for the financial industry. As stronger cryptography and "forward secrecy" are now required, this mitigates risk while at the same time increasing user privacy. In particular for internet and mobile banking applications the latter is very relevant and strengthening security is beneficial for the whole industry to pre-emptively protect against future forms of attack.
At the same time TLS 1.3 is designed to be faster, this will primarily reduce network roundtrips, lowering latency and thereby improving user experience. An even faster "zero roundtrip" (0-RTT) mode is available, but this does come at a security cost so caution should be applied before using 0-RTT in transactional systems. Finally, as the protocol design has been cleaned up, maintenance and changes should be easier and reducing long-term cost.
Implications of TLS 1.3
As with anything else that is new or changing, this will have impact. For the financial industry there are a few items to specifically consider.
As "forward secrecy" becomes necessary, solutions where an Intrusion Detection System (IDS) monitors all network traffic by applying TLS decryption (using the private key) is no longer possible. If one applies an IDS in this fashion, changes in the architecture become a necessity. Another effect can be that debugging or troubleshooting in production environments can become more complicated. As captured data can no longer be decrypted, this cannot be used as a last resort or blunt solution any longer.
Due to the use of stronger cryptography, hardware- and software requirements may need to be revised. This is in particular relevant with embedded systems such as point-of-sale (POS) terminals and large scale systems already close to their limits, from a system performance and load perspective. Processing power, internal memory or secure key storage that suffice for today's cryptographic requirements, may become too limited to accommodate and support future updates.
For solutions relying on the TLS capabilities of their platform, library or appliance in use, TLS 1.3 updates to the platform may have interesting effects. As such, one may experience slightly different behavior. It is common practice to test such an update before rolling it out into production, but in particular with mobile apps on a customer device, the moment this update is performed may be out of your control and also out of control of the customer. On the other hand, this will only be an issue if your backend is not forward-compatible, which is under your control and you can take action in advance to have it tested.
As TLS is a protocol for securing communication, each connection has two participants. Both can have their own support, update-lifecycle and change management. All versions of TLS have explicit precautions for backward and forward compatibility. Due to specifics or even flaws in certain implementations of the protocol, one may still experience interoperability issues despite the compatibility built into the protocol.
A last implication worth mentioning is the removal of renegotiation. This is typically used in rather advanced use cases if explicitly applied, such as for additional privacy protection or postponed client authentication. Almost any of these use cases are still possible under TLS 1.3, but using the new revised session resumption mechanism.
Technology is evolving and progressing and TLS 1.3 has been finalized and is now entering the market. Currently there are no known vulnerabilities in TLS 1.2, therefore you can consider this an evolutionary update. In the next part of this article we will look further into relevance for the financial industry and actions you should take.