Netskope named a Leader in the 2024 Gartner® Magic Quadrant™ for Security Service Edge. Get the report

  • Why Netskope chevron

    Changing the way networking and security work together.

  • Our Customers chevron

    Netskope serves more than 3,000 customers worldwide including more than 25 of the Fortune 100

  • Our Partners chevron

    We partner with security leaders to help you secure your journey to the cloud.

Still Highest in Execution.
Still Furthest in Vision.

Learn why 2024 Gartner® Magic Quadrant™ named Netskope a Leader for Security Service Edge the third consecutive year.

Get the report
Netskope Named a Leader in the 2024 Gartner® Magic Quadrant™ for Security Service Edge graphic for menu
We help our customers to be Ready for Anything

See our customers
Woman smiling with glasses looking out window
Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.

Learn about Netskope Partners
Group of diverse young professionals smiling
Your Network of Tomorrow

Plan your path toward a faster, more secure, and more resilient network designed for the applications and users that you support.

Get the white paper
Your Network of Tomorrow
Introducing the Netskope One Platform

Netskope One is a cloud-native platform that offers converged security and networking services to enable your SASE and zero trust transformation.

Learn about Netskope One
Abstract with blue lighting
Embrace a Secure Access Service Edge (SASE) architecture

Netskope NewEdge is the world’s largest, highest-performing security private cloud and provides customers with unparalleled service coverage, performance and resilience.

Learn about NewEdge
Netskope Cloud Exchange

The Netskope Cloud Exchange (CE) provides customers with powerful integration tools to leverage investments across their security posture.

Learn about Cloud Exchange
Netskope video
The platform of the future is Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG), and Private Access for ZTNA built natively into a single solution to help every business on its journey to Secure Access Service Edge (SASE) architecture.

Go to Products Overview
Netskope video
Next Gen SASE Branch is hybrid — connected, secured, and automated

Netskope Next Gen SASE Branch converges Context-Aware SASE Fabric, Zero-Trust Hybrid Security, and SkopeAI-powered Cloud Orchestrator into a unified cloud offering, ushering in a fully modernized branch experience for the borderless enterprise.

Learn about Next Gen SASE Branch
People at the open space office
Designing a SASE Architecture For Dummies

Get your complimentary copy of the only guide to SASE design you’ll ever need.

Get the eBook
Make the move to market-leading cloud security services with minimal latency and high reliability.

Learn about NewEdge
Lighted highway through mountainside switchbacks
Safely enable the use of generative AI applications with application access control, real-time user coaching, and best-in-class data protection.

Learn how we secure generative AI use
Safely Enable ChatGPT and Generative AI
Zero trust solutions for SSE and SASE deployments

Learn about Zero Trust
Boat driving through open sea
Netskope achieves FedRAMP High Authorization

Choose Netskope GovCloud to accelerate your agency’s transformation.

Learn about Netskope GovCloud
Netskope GovCloud
  • Resources chevron

    Learn more about how Netskope can help you secure your journey to the cloud.

  • Blog chevron

    Learn how Netskope enables security and networking transformation through security service edge (SSE)

  • Events and Workshops chevron

    Stay ahead of the latest security trends and connect with your peers.

  • Security Defined chevron

    Everything you need to know in our cybersecurity encyclopedia.

Security Visionaries Podcast

On Patents, Trolls, and Innovation
In this episode host Emily Wearmouth chats with Suzanne Oliver, an intellectual property expert, and Krishna Narayanaswamy, co-founder and CTO of Netskope, about the world of patents.

Play the podcast
On Patents, Trolls, and Innovation
Latest Blogs

Read how Netskope can enable the Zero Trust and SASE journey through security service edge (SSE) capabilities.

Read the blog
Sunrise and cloudy sky
SASE Week 2023: Your SASE journey starts now!

Replay sessions from the fourth annual SASE Week.

Explore sessions
SASE Week 2023
What is Security Service Edge?

Explore the security side of SASE, the future of network and protection in the cloud.

Learn about Security Service Edge
Four-way roundabout
  • Company chevron

    We help you stay ahead of cloud, data, and network security challenges.

  • Leadership chevron

    Our leadership team is fiercely committed to doing everything it takes to make our customers successful.

  • Customer Solutions chevron

    We are here for you and with you every step of the way, ensuring your success with Netskope.

  • Training and Certification chevron

    Netskope training will help you become a cloud security expert.

Supporting sustainability through data security

Netskope is proud to participate in Vision 2045: an initiative aimed to raise awareness on private industry’s role in sustainability.

Find out more
Supporting Sustainability Through Data Security
Thinkers, builders, dreamers, innovators. Together, we deliver cutting-edge cloud security solutions to help our customers protect their data and people.

Meet our team
Group of hikers scaling a snowy mountain
Netskope’s talented and experienced Professional Services team provides a prescriptive approach to your successful implementation.

Learn about Professional Services
Netskope Professional Services
Secure your digital transformation journey and make the most of your cloud, web, and private applications with Netskope training.

Learn about Training and Certifications
Group of young professionals working

SASE and TLS 1.3, Part 1: What does it mean to “support” TLS 1.3?

Sep 23 2020

TLS is the most important protocol for secure communication with web sites and cloud services. Any vendor with ambitions in the SASE (Secure Access Service Edge) market has to be able to proxy TLS at scale. That requires considerable sophistication in terms of designing the computing and networking infrastructure for a SASE “security cloud,” but it also requires attention to the details of TLS itself.

TLS 1.3 is the current state-of-the-art version of TLS, and was finalized more than two years ago. Since TLS 1.3 has some important merits, and has been stable for a while, it’s not surprising that a number of security vendors support it. What’s a little more surprising is how squishy the concept of “support” turns out to be. So this article is a short guide about the places TLS 1.3 might show up in a SASE or would-be SASE system, the ways it might be “supported,” and why these details are important for enterprise security.

Does TLS 1.3 matter?

Let’s acknowledge immediately that most people don’t spend a lot of time thinking about TLS 1.3, and likely don’t have strong feelings on the subject. So a fair question is, “does the protocol really matter?” TLS 1.3 makes a meaningful difference to security, and it’s in use at a meaningful fraction of web sites, so there’s a solid argument that it really does matter. 

Although the changes from TLS 1.2 are relatively small, those changes are important to eliminate or reduce a number of recent high-profile attacks. A number of other blogs have summarized the security and performance changes in TLS 1.3. Eliminating even one serious attack is an important gain, and TLS 1.3 does far more than that.

When you look at the statistics collected by SSL Labs, it turns out that TLS 1.3 is already the best available SSL/TLS version on 25% of the Alexa 150K (the most popular web sites in the world). So we can comfortably say that it’s widely used.

So TLS 1.3 does really matter. Where should we be looking for it in a SASE system?

Where does TLS 1.3 show up?

In SASE or aspiring-SASE products, there are basically three places where it’s sensible to be paying attention to TLS 1.3 support: proxy, tunnel, and management. 

The first, and by far the most important location, is in the TLS proxy functionality. A trusted security proxy effectively splices itself into the TLS conversation between client and server, so it can inspect traffic that is otherwise encrypted. TLS 1.3 support in a trusted security proxy is crucial because otherwise the use of the proxy itself actually degrades security: a client/server conversation that could have taken place over TLS 1.3 is instead forced to use the known-vulnerable TLS 1.2.

The second location where TLS 1.3 matters is in tunnels, for example in a Zero Trust Network Access (ZTNA) product or feature. It’s good to have TLS 1.3 as a tunnel transport, but it’s less important than for a proxy—simply because the security vendor controls the implementation of both the communicating tunnel endpoints. For a tunnel, the security vendor can reduce vulnerability in a way that is impossible for a proxy. Even though TLS 1.2 is a less secure protocol than TLS 1.3, there are steps that can be taken to “harden” a particular instance of TLS 1.2 by removing vulnerable ciphers and similar local changes. In contrast, a proxy has no way of knowing just how vulnerable the communicating endpoint systems might be. 

For a SASE or SASE-aspiring system, the third location where TLS 1.3 functionality matters is for communicating with the management console. Authorized users use the management console to set policies and analyze incidents, so the data at risk can be quite sensitive, but the volume of data is quite low compared to the volume of data being proxied or tunneled by a security cloud. When considering management communication, the communicating endpoints are both controlled by the organization’s security team. So once again, there are opportunities to “harden” TLS 1.2 in ways that are not possible for a large population of users communicating with a large population of cloud services. 

My vendor supports TLS 1.3… what does that mean?

The place that everyone starts from—and that everyone agrees on—is that a product that “supports” TLS 1.3 can’t break when you send it TLS 1.3 traffic. But that’s a pretty weak constraint, especially if there are different ideas of what it means to “break.” It turns out that there are (at least) three different definitions for what it means to “support” TLS 1.3 in a proxy, and only one of those definitions actually requires implementing the protocol! We can call these three choices “true,” “down-negotiation,” and “bypass.” 

True TLS 1.3 support

Let’s take up “true” support first, since it’s what most people would expect when a proxy claims to support TLS 1.3—plus, it’s what Netskope implements as a proxy. In this definition, a proxy that “has true TLS 1.3 support” performs its full security functionality even when the client and server require TLS 1.3 only. Keep in mind that TLS 1.3 has better ciphers and better initial handshakes than TLS 1.2, making it both more secure and faster to set up, so there are some solid reasons for clients and servers to prefer the newer protocol. 

If the client and server insist on using TLS 1.3 to communicate, and the product is going to deliver its full security functionality, then the product has to actually implement TLS 1.3. So that’s pretty straightforward. 

“Support” via down-negotiation

Now let’s instead assume that the client and server are a little more agreeable, as most TLS clients and servers are. A proxy “supports TLS 1.3 via down-negotiation” if it performs its full security functionality when the client and server accept TLS 1.2. Basically, the “trick” here is that the proxy receives a TLS 1.3 connection request from the client, but negotiates it down to TLS 1.2… and then opens a TLS 1.2 connection to the server. Effectively, the “support” added in the proxy is only enough to recognize a TLS 1.3 request and respond, “no, thanks!” to the client. It’s otherwise entirely a TLS 1.2 world. 

This down-negotiation approach is obviously not as good as the stricter true TLS 1.3 support. Still, let’s take a moment to consider what’s good and bad about it. On the negative side, the proxy is silently downgrading the security of the connection. What would have been a TLS 1.3 connection between client and server is now all handled by TLS 1.2 instead. On the positive side, the proxy is still performing its security functions on this slightly-less-secure traffic.

“Support” via bypass

How about the third definition? A proxy “supports TLS 1.3 via bypass” if it doesn’t attempt to process TLS 1.3 traffic. It performs no security functionality at all when a client or server requires TLS 1.3. In this strange version of “support,” the proxy merely knows enough about TLS 1.3 to get the heck out of the way. 

Again, this bypass approach is obviously not as good as the stricter true TLS 1.3 support. And again, we can examine what’s good and bad about it. On the positive side, this approach doesn’t silently downgrade the security posture of the client and server like the previous approach; the client and server will still be communicating via their preferred TLS 1.3. On the negative side, this approach silently removes the proxy’s security functions from the picture, which might well be worse than downgrading to TLS 1.2.

Down-negotiation and bypass can even be combined. When the client contacts the proxy using TLS 1.3, the proxy can check whether it can open a TLS 1.2 connection to the server. If so, it down-negotiates the connection. If not, the proxy bypasses it.

Summarizing the choices

This table summarizes the proxy implementation choices, and the corresponding effects when the server accepts TLS 1.2 or requires TLS 1.3. In all of these cases, the client is initiating a TLS 1.3 connection.

Proxy implementationWhen server accepts TLS 1.2...When server requires TLS 1.3...
True TLS 1.3WorksWorks
Down-negotiate TLS 1.2Works using TLS 1.2Can't connect
Bypass TLS 1.3Connects, but no security processingConnects, but no security processing
Down-negotiate or bypassWorks using TLS 1.2Connects, but no security processing

Only the top row for “True TLS 1.3” works correctly, with full functionality, for both kinds of servers. All the other entries involve a weakening of the protocol, a bypassing of security functionality, or the complete failure of the client/server connection. It’s perhaps a little hard to believe that anyone would really describe the last three rows as “supporting” TLS 1.3, but that kind of exaggeration is common when marketers get carried away. In Part Two, we’ll get specific about Netskope and some competitors, identifying how each company’s proxy implements (or fails to implement) true TLS 1.3.

author image
Mark Day
Mark Day brings a diverse background to his role at Netskope, where he combines his interests in competitive analysis and technology strategy. He is author of the book Bits to Bitcoin: How Our Digital Stuff Works. He has more than thirty patented inventions, and has taught at both MIT and Harvard.

Stay informed!

Subscribe for the latest from the Netskope Blog