TLS 1.3: Ask the Hard Questions Now

You ever have that “I wish someone would have told me” moment?

I’ll give you an example of what I mean: this winter my snow-blower was out of commission for most of the season (a bummer since I live in NH). It wouldn’t start because, as I learned later, I forgot to clear out the fuel line. Now, I’m rigorous about maintenance: I change the oil and spark plugs, I use fuel stabilizer, I start it once a month, etc. If it says in the manual to do something, I do it. Except, in this case, clear the fuel line. I know now the criticality of doing this, and I won’t make that mistake again, but I wish someone would have told me the consequences ahead of time so that I could have taken a different path: it would have saved both money and time.

In the security world, there’s one of these moments brewing right now. A situation that, though hugely impactful, many CIOs (and, by extension the security pros that support their efforts) aren’t even aware of: the new version of the TLS standard. TLS—the successor to SSL, and the protocol that underpins secure data exchange for the web in use in everything from e-commerce to secure remote access to RESTful API—is about to undergo a change. That change is one that has the potential to impact directly how organizations perform monitoring. For those it does impact, it will be a “game changer.” From a CIO’s vantage point, it matters now because it can impact the operations side of their security capabilities; meaning, they should assign resources to address it now so that they can have confidence that their organization will be prepared. Let’s explore why this is happening, what’s at stake, and what CIOs need to know now to get ready and plan.

TLS 1.3

TLS 1.3, a replacement for TLS 1.2 (i.e., the current version of the protocol defined by RFC 5246 in 2008), has been in draft since 2014. It introduces a major change in that it now specifically requires “forward secrecy.” What is forward secrecy? It’s just a fancy way of saying that, were I to compromise a key in use today, I can’t go back and use that key to unlock sessions I recorded in the past.

In general, this is a boost in the overall security properties of TLS and on the whole, should be “good news” for CIOs. In legacy versions of the protocol, many of the allowable ciphersuites (i.e., the defined combinations of cryptographic protocols negotiated between client and server for a given session) employed a “master key” as a vehicle to exchange session keys. This means that, were that master key to be compromised, doing so would allow any session employing that key to be unlocked. For example, when a key used to encrypt the data stream between the participants is negotiated based on data encrypted under the public key of the server – that’s fine, until the private key of the server is lost or stolen. Should that happen, any historical session negotiated using that method could be unwound and examined.

Now, it should be stated that TLS 1.2 does include ciphersuites that allow forward secrecy, but this was “opt in” in 1.2—meaning, the client of a TLS session and the remote server would need to negotiate a ciphersuite that allowed it. In TLS 1.3, it’s required. There are a few reasons why this is beneficial. First and foremost, it means that if a key is compromised, the damage that compromise causes is more limited than would otherwise be the case. By limiting the damage that can be done should a compromise occur, secure communications overall are more resilient.

Why CIOs need to plan for this

Despite the fact that this may be a positive trend for organizational technology use as a whole, it’s important that CIOs evaluate it—and getting up to speed sooner is better. The reason why is that there are a number of existing security tools on the market today that leverage the “master key” issue to accomplish certain goals. For example, there are monitoring tools that unwind encrypted sessions so they can inspect the traffic, HTTPS interception tools that proxy TLS sessions to record them, etc. Meaning, there are security tools out there that specifically and purposefully break the TLS session so that they can operate. This method, at least the most commonly implemented way it is accomplished, will cease functioning in 1.3. CIOs that employ tools that work this way as critical elements of their technology monitoring and oversight need to think through the “fallback position” now so that they’re not surprised when a portion of their monitoring capability suddenly vanishes or when capabilities they rely on suddenly stop working.

If that sounds like a faraway problem that “bears thinking about at some future time but not today,” keep in mind that the rollout of a new version of a communication standard is almost never a “line in the sand” situation. Meaning, it’s not the case that everyone wakes up one day and spontaneously decides to adopt the new standard. Instead, it gets rolled out gradually across a number of different technologies that organizations use in parallel. First only a subset of products will support it (some in the cloud and via new versions of on-premise applications), then it slowly and gradually becomes the default across more and more products, then (finally) it becomes the norm to the point that any apps not using it seem out of place.

The point? It’s gradual—it happens slowly and over time. And, in fact, it’s already started. There are products supporting TLS 1.3 already—like, right now. Of course, as is almost always the case, there will be a transition period where both 1.2 and 1.3 will be accepted in parallel, but the astute CIO won’t wait for it to become a problem before they act. Instead, they will take stock of security measures they have in place right now to determine where/if/how they leverage this functionality. They will have the tough discussions with their vendors (and the security leaders and managers that support them) about what the future will bring and what the path forward is, and they will create a plan for replacing those that can’t move forward. Likewise, they will have this in the back of their mind as they evaluate vendors and make purchasing decisions.

The salient point is, CIOs should be asking the “hard questions” right now to make sure that they are prepared for the changes ahead. Active planning is required to make sure the organization is prepared, and that full value from existing tools is realized (not to mention to offset the possibility of “doubling down” on a capability that is going away.) Ideally, security managers, directors, or other security-focused resources that support the CIO are already actively working on this; but ensuring that is the case is both prudent and useful. Taking steps now—even though there may be some time between now and when TLS 1.3 is commonplace—is time well spent.

The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of The Tambellini Group. To express your views in this forum, please contact Katelyn Ilkani, Vice President, Client Services and Cybersecurity Research, The Tambellini Group.