Endpoint

5/10/2018
10:30 AM
Mark Urban
Mark Urban
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Ready or Not: Transport Layer Security 1.3 Is Coming

Better encryption could mean weaker security if you're not careful.

Transport Layer Security (TLS) protocols enable secure network communications and support everything from e-commerce to email. TLS 1.3 — the latest update to the ubiquitous SSL/TLS encryption protocol — is in the final stages of ratification and will become official soon. This new encryption standard will offer substantial security and performance benefits. The question for security teams is — are you ready?

Rest assured, the day TLS 1.3 is official won't be a "Y2K bug" moment for encrypted traffic — and for everyday Web users, the update will likely go unnoticed. However, for security teams, the time to prepare for the new standard is now.

The Internet Engineering Task Force (IETF), which governs the standard, recently announced approval of the 28thdraft of TLS 1.3, and many in the Internet ecosystem will likely be aggressive in rolling it out. However, adoption will vary by geography, industry, and business model. For example, industries that rely on high Web traffic, such as online retailers and news sites, may be slower to adopt the new standard because they don't want to turn away site visitors using unsupported browsers. Other companies, especially those in highly regulated industries, may insist on a higher level of security protection when employees interact with external sites, send email, or transfer files.

The high-security encryption gained from TLS 1.3 comes at a critical time because the challenges of cyber defense have never been greater. Malicious actors continually look for new ways to carry out attacks, and they're well aware that encryption affords an easy path to avoid protective measures. Consequently, Gartner predicts that in 2019 "more than 50% of new malware campaigns will use various forms of encryption to conceal delivery and ongoing communications, including data exfiltration." 

Determining TLS 1.3 Readiness
Organizations should always aspire to achieve the best possible security posture, as long as no other risks are introduced. And although TLS 1.3 will offer substantial security benefits, there are factors to consider before adopting the standard. In fact, many organizations have existing network security architectures in place that are fine-tuned to deal with the world as it is, and changing the strength of encryption can create challenges.

Having highly secure sessions without compromising the protection offered by existing network security tools is tricky because encryption hides the traffic it is designed to inspect; encrypted traffic, whether it is private data or malware, is all hidden from most standard security systems. A straightforward and effective way to avoid being blinded to malicious traffic is with an encrypted traffic management application that physically (or virtually) resides within the network and facilitates a view of decrypted traffic to a wide variety of security tools. However, what many have found is that the security solutions that allow SSL visibility and enable security inspection vary greatly in their ability to provide visibility while simultaneously maintaining the privacy and security integrity of the session.

When a client-server session is established with an encrypted traffic management application residing in the middle, all parties must work in harmony for seamless connectivity. When a tool in the middle cannot support the high-level encryption preferences of the client and server, one of three choices must be made:

1. Block the traffic, which leads to a poor user experience;

2. Allow the encrypted traffic without inspection, which results in a decreased security posture (cipher)

3. Degrade the session to a lower security connection that is supported by both client and server. For example, changing the session to an earlier version (TLS 1.2 or TLS 1.1) or dropping from a strong cipher suite (such as one that provides perfect forward secrecy) to a weaker one.

For practical reasons, degrading session security is the choice most enterprises make, affording a positive user experience with some inspection capability. However, it is still a compromise because it means sacrificing encryption strength in exchange for increased visibility for inspection tools. Ideally, choices like this should not have to be made.

Taking the Right Steps
To best prepare for TLS 1.3, security teams must inspect their current approach and determine how change will affect it. Here are some questions to consider:

  • Is decrypted traffic currently being inspected?
  • Will changes in the new standard affect the performance of that inspection or add pressure to the network?
  • Will we need to re-architect to accommodate the new standard?

Companies with network security tools in place (intrusion-prevention systems, next-gen firewall, sandboxes, forensics, etc.) that are not inspecting traffic should conduct a risk assessment and develop a plan to create secure and compliant inspection of potential hidden threats. It's also important to engage cross-functional partners early (including network, security, and compliance teams) to be sure that the plan addresses any encryption blind spots. 

Those with inspection capability in place should determine if the current solution meets requirements for secure decryption for earlier SSL/TLS protocols. Organizations will need to inspect less-secure traffic (e.g., TLS 1.2), and it's important they do so without introducing new security risks. A thorough assessment should help them determine if their inspection solution has strong ciphers and mirror client ciphers, validates certificates, and demonstrates protection against known vulnerabilities.

Finally, organizations should determine if it's possible to enable inspection while preserving the strong security benefits of TLS 1.3. An inspection solution will need to support a new handshake mechanism and must support the limited number of cipher suites required for TLS 1.3. These ciphers are much stronger and offer greater protection against replay attacks. To fully enjoy these benefits, a full handshake must be enabled.

By taking these steps, your organization can help get ready for when TLS 1.3 arrives and avoid having to make trade-offs involving user experience, encryption strength, and inspection capabilities.

Related Content:

In his role as vice president of product strategy and operations, Mark helps major enterprises navigate the evolving technology landscape to address key business and security issues. Mark joined Symantec via the Blue Coat acquisition, where he led product strategy & ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Symantec Intros USB Scanning Tool for ICS Operators
Jai Vijayan, Freelance writer,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10008
PUBLISHED: 2018-12-10
A code execution vulnerability exists in the Stapler web framework used by Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in stapler/core/src/main/java/org/kohsuke/stapler/MetaClass.java that allows attackers to invoke some methods on Java objects by accessing crafted URLs that were not intended...
CVE-2018-10008
PUBLISHED: 2018-12-10
An information exposure vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in DirectoryBrowserSupport.java that allows attackers with the ability to control build output to browse the file system on agents running builds beyond the duration of the build using the workspace br...
CVE-2018-10008
PUBLISHED: 2018-12-10
A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jen...
CVE-2018-10008
PUBLISHED: 2018-12-10
A denial of service vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in CronTab.java that allows attackers with Overall/Read permission to have a request handling thread enter an infinite loop.
CVE-2018-10008
PUBLISHED: 2018-12-10
A sandbox bypass vulnerability exists in Script Security Plugin 1.47 and earlier in groovy-sandbox/src/main/java/org/kohsuke/groovy/sandbox/SandboxTransformer.java that allows attackers with Job/Configure permission to execute arbitrary code on the Jenkins master JVM, if plugins using the Groovy san...