SASE and TLS 1.3, Part 2: Naming Names

Recall from Part One that we identified three different places in a SASE product where TLS 1.3 support is relevant. In descending order of importance, those places are: proxy, tunnel, and management interface. We also identified three different ways that vendors “support” TLS 1.3: in descending order of quality, they were “true,” “down-negotiate,” or “bypass.” 

Surprisingly, despite the merits of TLS 1.3, and more than two years after it was finalized, some security vendors still don’t have true TLS 1.3 support in their proxy. Even more alarming, you can find people who say publicly (but incorrectly) that those vendors support TLS 1.3, which is only true in a weak, spinning-a-story, marketing-and-sales kind of way.

Now let’s talk about some well-known vendors and what they do.

As we’ve already noted, Netskope has a true TLS 1.3 implementation for our proxy. We’ve counted at least six other security vendors who have chosen to do likewise, which is not very surprising. After all, this is the choice you would expect security vendors to make. What’s more surprising are the vendors who haven’t done a true TLS 1.3 implementation (at least, not yet). 

For example, Zscaler uses the combined “down-negotiate or bypass” strategy. That means Zscaler won’t necessarily break a would-be TLS 1.3 connection by making it impossible for client and server to communicate. But since Zscaler can’t actually deliver their security processing over a TLS 1.3 connection, their cloud has to decide on every new connection whether to give up on TLS 1.3 or give up on security processing. 

Every time a TLS 1.3 user tries to connect via Zscaler to a service that supports TLS 1.2, Zscaler will downgrade that connection. But every time such a user tries to connect to a service that requires TLS 1.3, Zscaler will completely bypass the connection and perform no security inspection on it. (Well, there’s an alternative: in this situation, Zscaler can also block the connection as undecryptable traffic. That choice still does no security processing, but might be preferable in some cases. Any way we look at it, it’s clearly not great that the only available choices here are “turn off security” or “disallow service.”)  

Symantec WSS appears to use only the down-negotiate strategy. Most servers support TLS 1.2 for compatibility, and so in the common case, Symantec WSS will behave similarly to Zscaler. It will lower the security and performance of the connection compared to what the client could have achieved on its own, but the client will still connect to the server and Symantec WSS will still perform its security processing. However, if the server refuses to negotiate TLS 1.2, Symantec WSS will actually prevent a TLS 1.3 client from connecting to a TLS 1.3 server. In that situation, Symantec WSS may actually impair enterprise productivity instead of enhancing enterprise security. 

Let’s also note that these vendors will almost certainly fix these problems eventually. Indeed, they might even have fixed them by the time you read this article. Will that make all of this discussion irrelevant? Not completely, because it’s still striking how long it’s taken them. We first discovered the weakness of some competitive implementations in early December 2019, when Netskope already supported TLS 1.3. It seemed all but certain that those other vendors would soon catch up… but it’s now October 2020. It started to look as though actually implementing TLS 1.3 wasn’t very important to some vendors. Instead, they could just “support” it in the ways described in Part One. 

Sources of information

How can you determine a vendor’s support for TLS 1.3? As this article (and Part One) have shown, it’s not as simple as just asking!

The best approach is to actually experiment with the product of interest. One easy test is to visit facebook.com via a proxy of interest using Firefox. You can then go to Tools>Page Info>Security to see the details of the browser’s connection on that page: 

• What you want to see is a TLS 1.3 connection, secured by the proxy vendor’s certificate. That result means that the proxy is in the path and using TLS 1.3. 
• If you see TLS 1.2, then the proxy has negotiated down. 
• If you see a TLS 1.3 connection that is secured by Facebook’s certificate, then the proxy has bypassed.

The next-best alternative seems to be the vendor’s support sites, but some detective work may be involved. Both Zscaler and Symantec acknowledge the limitations of their TLS support, although only implicitly. Zscaler’s support site currently lists out supported protocols but omits TLS 1.3, while the Broadcom support site for Symantec WSS responds to a TLS 1.3 problem by explaining how to disable TLS 1.3 in the browser. 

How about a vendor’s corporate blog or a third-party site? At least for what we’ve seen, the information there seems noticeably lower in quality. For example, Zscaler’s corporate blog has a lengthy article about TLS 1.3 that never actually claims that Zscaler supports it, but certainly seems to imply it. When read carefully, there’s nothing actually incorrect about the article, but it also isn’t a model of straightforward communication.

Likewise, there’s a fascinating blog post by Brian Deitch from 2018 that claims Zscaler has this all taken care of, which is incorrect. The post mostly complains about legacy box vendors and makes some good points. But since it’s now 2020 and Zscaler still doesn’t support TLS 1.3, clearly there was a bug somewhere in the author’s assessment. 

Symantec’s corporate blog similarly has a post on DoH that mentions using a TLS 1.3 proxy for additional control without clearly stating that Symantec WSS doesn’t operate as such a proxy. Again, if you read the article very carefully, it’s not actually untruthful… it just doesn’t help the reader understand the actual state of the world. 

Bottom line 

Part One was an introduction to the surprising complexities lurking in TLS 1.3 support, and we laid out a framework to understand what’s happening there with any SASE or would-be SASE vendor. As a reminder, part of what we tackled there was the “so what?” question about why TLS 1.3 support matters. In this article, we looked at some specific vendors. If you want to apply this same approach to other vendors, keep in mind:

• TLS 1.3 matters for both security and performance. If you don’t know the details of what your vendor does when proxying TLS traffic, you may be opening yourself to unexpected vulnerabilities as well as sacrificing performance. 
• TLS 1.3 “support” might not mean what you think; be aware of the alternative ways that a vendor may “support” the protocol.
• Experimenting with the product, or carefully reading the vendor’s support site are two likely ways to clarify the situation.
• Corporate blogs and third-party sites seem to be less reliable sources of information.