close
close
Your Network of Tomorrow
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.
          Experience Netskope
          Get Hands-on With the Netskope Platform
          Here's your chance to experience the Netskope One single-cloud platform first-hand. Sign up for self-paced, hands-on labs, join us for monthly live product demos, take a free test drive of Netskope Private Access, or join us for a live, instructor-led workshops.
            A Leader in SSE. Now a Leader in Single-Vendor SASE.
            A Leader in SSE. Now a Leader in Single-Vendor SASE.
            Netskope debuts as a Leader in the Gartner® Magic Quadrant™ for Single-Vendor SASE
              Securing Generative AI for Dummies
              Securing Generative AI for Dummies
              Learn how your organization can balance the innovative potential of generative AI with robust data security practices.
                Modern data loss prevention (DLP) for Dummies eBook
                Modern Data Loss Prevention (DLP) for Dummies
                Get tips and tricks for transitioning to a cloud-delivered DLP.
                  Modern SD-WAN for SASE Dummies Book
                  Modern SD-WAN for SASE Dummies
                  Stop playing catch up with your networking architecture
                    Understanding where the risk lies
                    Advanced Analytics transforms the way security operations teams apply data-driven insights to implement better policies. With Advanced Analytics, you can identify trends, zero in on areas of concern and use the data to take action.
                        The 6 Most Compelling Use Cases for Complete Legacy VPN Replacement
                        The 6 Most Compelling Use Cases for Complete Legacy VPN Replacement
                        Netskope One Private Access is the only solution that allows you to retire your VPN for good.
                          Colgate-Palmolive Safeguards its "Intellectual Property” with Smart and Adaptable Data Protection
                          Colgate-Palmolive Safeguards its "Intellectual Property” with Smart and Adaptable Data Protection
                            Netskope GovCloud
                            Netskope achieves FedRAMP High Authorization
                            Choose Netskope GovCloud to accelerate your agency’s transformation.
                              Let's Do Great Things Together
                              Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.
                                Netskope solutions
                                Netskope Cloud Exchange
                                Netskope Cloud Exchange (CE) provides customers with powerful integration tools to leverage investments across their security posture.
                                  Netskope Technical Support
                                  Netskope Technical Support
                                  Our qualified support engineers are located worldwide and have diverse backgrounds in cloud security, networking, virtualization, content delivery, and software development, ensuring timely and quality technical assistance
                                    Netskope video
                                    Netskope Training
                                    Netskope training will help you become a cloud security expert. We are here to help you secure your digital transformation journey and make the most of your cloud, web, and private applications.

                                      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.
                                      Mark Day brings a diverse background to his role at Netskope, where he combines his interests in competitive analysis and technology strategy.

                                      Stay informed!

                                      Subscribe for the latest from the Netskope Blog