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.
Vendor | Approach | Connects to strict TLS 1.3? | Security with TLS 1.3? |
---|---|---|---|
Netskope | True TLS 1.3 | Yes | Yes |
Zscaler | Down-negotiate or bypass | Bypass | No |
Symantec WSS | Down-negotiate | No | No |
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 usi