In late March 2018, after many years and 28 drafts, the Internet Engineering Task Force (IETF) passed the TLS 1.3 updated encryption protocol, which improves both connection security and speed. Understanding how TLS 1.3 protocols will affect mobile development and security practices is critical for any appdev or appsec team.
Let’s quickly review what TLS is and why the TLS 1.3 update matters. TLS stands for Transport Layer Security and its purpose is to protect application communication over the internet from eavesdropping, tampering or message forgery by ensuring a secure channel between two communicating peers. It does so by requiring server-side authentication (client-side is optional) and, after establishment, ensuring data confidentiality and integrity is maintained by having data visible only to endpoints and by ensuring data cannot be intercepted and/or modified by attackers.
Below, NowSecure Mobile Application Security Analyst, Tony Ramirez, shares 4 key takeaways from the 156 page protocol that mobile security and development teams should be aware of and consider as TLS 1.3 becomes more widely adopted.
1) Improved, Faster TLS Handshake
The most exciting development of TLS 1.3 is the faster, simplified handshake process. TLS uses symmetric cryptography to encrypt data, the keys of which are uniquely generated via a secret negotiation at the start of a session, or also known as the TLS handshake. TLS 1.3’s handshake shortens process time and reduces session latency given it only requires one round trip versus the three round trips previously required. The seconds gained by this efficiency may not seem like much, but adds up when considered in volume. The SSL Store does a good job covering TLS 1.3’s streamlined handshake process step-by-step, compared to TLS 1.2. Since speed is critical for mobile app experience and user satisfaction, mobile appdev teams will want to take advantage of this.
2) Consider Turning Off 0-RTT
Zero round trip (0-RTT) data allows sessions that are already set up to be cached and re-started at a later time to better manage bandwidth usage. While TLS does not include inherent protections for 0-RTT, the document offers some recommendations on how to best implement. Depending on how 0-RTT is implemented, it can make users vulnerable to replay attacks. If a hacker gains physical access to the mobile device, or obtains the 0-RTT data through other means, this data could lead to some lucrative attacks. If an attacker is able to replay this network data, they may be able to trick a server into giving a legitimate response. For example, if that data belongs to your mobile banking app, the attacker may be able to replay your login request using the 0-RTT data.
If you are a mobile security analyst, please note that this data might make compliance testing more complex. When testing mobile apps, be aware that caching 0-RTT data might be the equivalent to storing a username and password on a device, which is not recommended. If this data gets stored on a device, the value of forensics data increases dramatically, though it usually will require a physical attack to obtain.
It’s too soon to say how organizations will implement this for backend servers. The IETF TLS 1.3 doc offers some anti-replay defense recommendations, including expiring the data after a single use and aggressive logging. Just be aware of 0-RTT, as you may not want to implement it by mistake and open potential vulnerabilities.
If you need help locating what data is being stored on mobile devices or network sessions your mobile application creates, NowSecure can help with our automated testing tools and expert services team.
3) Regulated Industries Will Take Longer to Adopt the Protocol
When it comes to adopting TLS 1.3 protocols, it will take time to implement for highly regulated industries, like finance or healthcare. These industries are required to ensure no data leaving the network is sensitive or out of compliance with regulations. They often use proxies via their security vendors or firewall vendors to help monitor users and inspect SSL/TLS traffic for malicious attacks or compliance violations. In turn, this adds a dependency that not only the regulated organizations must comply with TLS 1.3, but also their 3rd party vendors.
As the IETF moved closer to finalization of TLS 1.3, financial institutions in particular were concerned with the IETF’s decision to move forward with deprecation of the RSA key exchange because many institutions have already significantly invested in out-of-band TLS encryption and will need to work through alternative options before TLS 1.3 can be implemented. One hundred of the top 150 U.S. financial services companies banded together to lobby the IETF for a backdoor option that might have sped up the compliance process; however, a backdoor was not included in the final protocol given IETF felt it presented unnecessary barriers to TLS 1.3’s goal of enforcing modernized, better security standards.
Adding additional pressure to finance organizations to upgrade TLS versions, the Payment Card Industry (PCI) is dropping TLS 1.0 protocol June 30th, 2018. Given the complexities and 3rd party interdependencies, we recommend regulated industries start planning a measured, methodical approach to implementing TLS 1.3.
4) Static RSA is Still an Issue
Although RSA encryption isn’t included in TLS 1.3, those still using static RSA on previous versions of TLS could be susceptible to Bleichenbacher ROBOT attacks, or attackers impersonating a server. Apple offers client side protection for this issue via App Transport Security (ATS) and doesn’t allow connections via RSA encryption based ciphers. ATS already enforces TLS 1.3 in addition to TLS 1.2, as of iOS 11.
Overall, it is recommended that static RSA support be disabled across all versions of TLS to mitigate the potential vulnerability.
Final Thoughts
Fully and correctly implementing TLS 1.3 is an important step all mobile appdev teams should embark on. With a measured approach, organizations can step up their game in protecting data in transit with TLS 1.3. TLS 1.3 is not a silver bullet and we expect most security testing findings aren’t going to be in the protocol itself, but rather the chosen implementation approach of the protocol. NowSecure fully tests all data in motion as part of our core mobile application security suite and we frequently find SSL/TLS implementation gaps as a root cause for problematic findings. For this reason, it’s important to continue to follow development and testing best practices, including systematic mobile appsec testing with full dynamic and behavioral tests to protect against MITM attacks.
