Skip to main content

TLS 1.3: Relevance for the Financial Industry and Actions to Take [PART 2]

IETF has published RFC 8446 [1], specifying TLS version 1.3. In our previous article we discussed what is new in this latest update to the Transport Layer Security protocol. Read on for more details on why this is relevant to the financial industry and what actions you should take.

Relevance to the financial industry

Why would the financial industry care for a new version of TLS? In the first place, TLS is used in many places to secure connections. In finance, TLS is also widely applied to secure communication, for instance between point-of-sale (POS) terminals and an acquirer's backend systems, for VPN and inter-bank connections, from mobile apps and the user's browser to the bank's servers, up to the internal WiFi network and probably dozens of other lines of communication per organization. As such, TLS is one of the fundamental technical building blocks used in the financial industry to protect against security risks and to keep the trust of the customer to safe-guard their money.

Since it is so widespread, the PCI-DSS regulations applicable to many in the industry even have some explicit requirements for TLS. In 2014/2015 newly discovered attacks, targeting vulnerabilities in older SSL/TLS versions and implementations, being abused in the field led to the introduction of requirements to update to newer versions (1.1 and 1.2) of TLS [2]. As many in the industry were not ready and could not meet the initial deadline, this requirement was postponed [3] for two years and only recently came fully into effect.

Recap of changes

In our previous article we described some of the impact of version 1.3 for the financial industry. Below a brief recap:

  • “Forward secrecy” may complicate the way an IDS can be applied.
  • Hard- and software requirements may change.
  • TLS upgrades may come from your platforms TLS support.
  • Back- and forward compatibility is incorporated, but some implementations apply this incorrect.
  • Renegotiation has been removed, though in a different manner can still be accomplished.

What should you do?

Not unlike other changes to fundamental parts of a solution, one should first revise the applicable architecture and policies for potential impact. Applying TLS in an architecture should not conceptually change it, but TLS 1.3 may raise the easily overlooked IDS issue, due to forward secrecy as mentioned previously. Neither troubleshooting nor the IDS effect is new though, as ciphersuites incorporating forward secrecy are already applicable in older TLS versions. If you explicitly disabled those (DHE or ECDHE based) ciphersuites  for these reasons, you may want to revise your strategy for dealing with them. 

Another item on your checklist should be testing your existing implementation. Chances are high that your production system is already being tested, as (experimental) TLS 1.3 support is already available in some of the major browsers and actual usage is in the field  for quite some time. Your current implementation is supposed to be backward compatible, but does it really work as intended? Or do you end up with inexplicable connection failures?

When designing or updating a POS terminal, it is recommended to take upgrading TLS into account. That means that hardware should have sufficient capabilities to accommodate future, more demanding algorithms or algorithms based on different mathematical principles. Through software updates – an essential requirement by itself – security improvements and support for new protocol versions can then be rolled out, resulting in cryptographic agility.

For acquirers, merchants and others that want to order new POS terminals, make sure you get a model that has sufficient capabilities for future updates and that it will receive those updates from its vendor. Even if not for the update to TLS 1.3, this would be a wise idea anyway.

For any other project, update or new development, TLS 1.3 is an item to take into account. As you are building or modifying your system anyway, incorporate support for the new protocol version while you're at it. Treat it as you would treat any other technology refreshment update for your components. For most solutions it will not justify a project all by itself. Well, unless selling TLS products is your business.

Finally, if you do want to add TLS 1.3 support to your product or service, just get started. Add it as an item in your requirements, development, integration, test and deployment processes. As compatibility with previous versions is covered, it should not be disruptive to your solution. Just make it explicit so you and the rest of your organization are aware your product or service supports it, so you are ready whenever urgent reasons to migrate arise. And you may benefit from the improvements in TLS 1.3.

Conclusion

Technology is evolving and progressing and TLS 1.3 has been finalized and is now entering the market as an evolutionary update. Only in specific situations are the benefits of TLS 1.3 worth immediately upgrading for. So in short, just take TLS 1.3 into account in your next update, and be prepared before a reason to do so forces you at an inconvenient moment in the future.

[1] https://tools.ietf.org/html/rfc8446

[2] https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf

[3] https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls