Cisco Blogs
Share

Securing the Cloud: Assessing the Security of TLS


August 22, 2018 - 0 Comments

As more and more organizations move from self-hosted infrastructure to cloud-based environments, so too increases the demand to ensure that they are resilient and secure. As part of Cisco’s efforts to support our customers in making this change in a smooth and seamless fashion, we have been hard at work developing our cloud security offerings, with new solutions to give our customers the visibility they desire.

Of course, security doesn’t end with the product. As our 2018 Annual Cybersecurity Report indicates, it takes the correct alignment of people, policies and products to adequately defend and respond to the changing threat landscape. With this in mind, the Cisco Security Advisory Services team also have our part to play: our experts develop guidance around strategy, risk and compliance in the cloud, and we are constantly developing and evaluating new ways to assess customer’s security posture where traditional techniques are either inappropriate or ineffective.

Recommendations for Securing SSL

In the process of working with clients and honing our capabilities to deal with securing the cloud, we’re often asked about architecture particularly where clients are leveraging multi-cloud strategies to avoid being reliant on a single vendor. One aspect of such architectures that caught our eye is how one does encrypt traffic using SSL (or rather TLS) in such environments. It seemed that leveraging yet another cloud-hosted service – namely CDNs –was something that featured quite heavily in our customers’ plans.

This got us thinking: was there anything specific we needed to consider if we were to give our customers appropriate guidance on leveraging the obvious benefits that CDNs can bring? We want to encourage organizations to take up the benefits of TLS as offered by the CDN operators but we want to ensure that they don’t introduce regressions in the process.

One thing we spotted quite quickly was that a number of CDNs were very quick to support TLS version 1.3 and to proclaim the security benefits of it (of which there are many). TLS 1.3 has introduced a new feature to improve the performance for new connections. The name of this feature is 0-RTT (Zero Round Trip Time Resumption) and it allows a fast session resumption that can push data to the server without needing to wait for a server confirmation. Whilst this is obviously desirable from a performance perspective (especially when the server isn’t down the corridor), we wondered if it presented any undesirable security properties that our customers ought to know about.

Cisco security consultants Alfonso Garcia Alguacil and Alejo Murillo Moya decided to spend some time looking at the known security implications of using 0-RTT and whether this was effectively mitigated by customers who’d taken the CDN route to resilience. As a result, they developed Proof of Concepts (PoCs) of some attacks in real world environments which they demonstrated as part of their presentation “Playback: A TLS 1.3 story” at Black Hat USA 2018 and DEF CON 26 earlier in the month. Attendees learnt about TLS 1.3 0-RTT, saw some examples about how an attacker could take advantage of that new feature and finally got understanding of the security implications of enabling the feature and how they can safely minimize the potential security impacts when leveraging CDNs as part of their digitization strategy.

You can find their slides and code here.


 

About Cisco’s Cloud Security offerings

Cloud-based environments can help you gain a competitive edge with an array of services and capabilities. But these often come with new, unique risks and exposures. You need to understand these security risks to manage those services effectively. If you feel your team could use some expert help, reach out to our Cisco Security Services team:  we’re available to add experience and expertise to your team, whether you are looking for strategic guidance or technical recommendations.

 



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.