They say that the key to good security is constant vigilance. As a practical matter, this means that it’s important for security and network pros to pay attention to two things: changes in the threat landscape, so they can be on the alert for how their systems might be attacked; and changes and developments in the technologies they employ.
It’s in light of the second part — paying attention to changes in the underlying technology — that I want to call attention to a potential change that’s under discussion right now. It’s a change that may not seem overly significant on the surface, but that has potential long-term consequences lurking below the surface.
These consequences matter quite a bit. If they’re not planned for, these changes can lead to dozens of wasted hours spent looking for difficult-to-debug application failures, potential service interruptions, or other impacts that may not be apparent when viewed cursorily. I’m referring here to proposed changes under discussion related to the lifetime of X.509 certificates used for TLS/SSL sessions.
So what’s going on with certificates? The backstory is that Google made a proposal at the June CA/B Forum to shorten the lifespan of X.509 certificates used in TLS once again, to just over one year (397 days).
The CA/Browser Forum (CA/B Forum) is a consortium of PKI industry stakeholders: certificate authorities (the organizations that actually issue certificates), and relying parties (software manufacturers, such as browser vendors, that rely on the certificates being issued). Its mandate is to establish security practices and standards around the public PKI ecosystem.
The current two-year standard (825 days) for maximum certificate lifetime, set in March 2018, was shortened from a prior three-year (39 months) lifetime. This time, the forum is revisiting the one-year proposal. As was the case last time, there has been some natural pushback from certificate authorities in the business of actually issuing the certificates involved.
Who Cares How Long the Lifetime Is Anyway?
The fact of the matter is that there are some good arguments to be made on both sides of the certificate lifespan fence, both supportive and critical of shortening the maximum certificate lifespan.
First, there is the issue of certificate revocation. Specifically, it is the responsibility of those relying on certificate validity (for most use cases, this means browsers like Chrome, Edge and Firefox) to ensure that revocation status for certificates is checked appropriately. This is the kind of thing that sounds easy to do until you think through the full scope of what it entails.
For example, it’s not just browsers that have to implement validity checking. So do software libraries (e.g. OpenSSL, wolfSSL), operating system implementations (e.g. CAPI/CNG), implementations like CASB products or other monitoring products that seek to perform HTTPS Interception, and a bunch of others.
As one might suspect, given the complexity, not every implementation does this well or as thoroughly as is desirable (as noted in US-CERT’s technical bulletin on the topic of HTTPS Interception). Having a shorter lifespan means that there is a reduced ceiling of how long a revoked certificate can remain in use even if an implementation doesn’t check revocation status.
On the other hand, keep in mind that most new applications rely heavily on Web services as a key method of operation. It’s not just browsers and associated products that rely on certificates, but increasingly it’s also applications themselves.
This in turn means that when certificates expire, it not only can have a negative impact on the user interface experience for those seeking to access websites, but also can cause applications to fail when critical Web services, such as those on the server end of RESTful APIs (where business logic actually is implemented.) They can’t establish a secure channel and thereby fail. In this case, certificate expiration can cause the application to fail unexpectedly — “it worked yesterday but doesn’t work now” — in a difficult-to-debug kind of way.
There’s a tradeoff, no matter how you slice it, from an end-user practitioner viewpoint. A shorter lifespan potentially can help alleviate problems resulting from failure to properly implement revocation checking, but at the same time can lead to application complexity in situations where certificate expiration status is not tracked rigorously. Note that this is in addition to the arguments made for and against by CA, browser developers, and other stakeholders in the CA/B Forum.
What Security Practitioners Can Do
Regardless of where you fall on the spectrum of for/against this particular change, there are a few things that practitioners can and should do to ensure that their houses stay in order. First of all, there arguably would be less need to look for alternative strategies to limit exposure from revoked certificates if everybody did a better job of validating revocation status in the first place.
If you’re using a product like a CASB (or other interception-based monitoring tool), if you’re developing applications that employ TLS-enabled RESTful APIs, using reverse proxies, or otherwise handling the client side of TLS sessions, it’s a must-do to ensure that revocation status checking is performed and performed accurately.
This is a good idea regardless, but the fact that those in the know are pushing this change suggests that the problem may be worse than you might think.
Second, keep track of the expiration of certificates in your environment. Ideally, keep a record of who issued them, when they expire, along with a contact point for each one (someone to hassle in the event that it expires).
If you can, routinely canvass the environment for new TLS-enabled listeners that you don’t expect. If you have budget to invest, there are commercial products that do this. If not, you can get information about certificate expiration from vulnerability scan results.
Worst case, a script to systematically trawl an IP address range looking for TLS servers (and recording the certificate details including expiration) isn’t that hard to write using a tool like OpenSSL’s “s_client” interface or the “ssl-cert” option in nmap. Again, this is useful to do anyway, but if the lifespan gets shorter going forward, it will provide more value.
By taking some time and doing a bit of planning now, you can make sure your environment stays optimally positioned, regardless of which way the powers that be ultimately decide to go. Since these measures are prudent anyway, even if the outcome is no shortening of the expiration lifespan, you still derive value from having implemented them.
Loading ...
