Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

7/30/2020
06:30 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Browsers to Enforce Shorter Certificate Life Spans: What Businesses Should Know

Apple, Google, and Mozilla will shorten the life span for TLS certificates in a move poised to aid security but cause operational troubles.

On Sept. 1, browsers and devices from Apple, Google, and Mozilla will show errors for new TLS certificates with a life span longer than 398 days. The move, while beneficial for security, pushes back against certificate authorities (CAs) and may prove an operational headache for businesses. 

The life span of SSL/TLS certificates has dramatically shrunk in the past 10 years. Just over a decade ago, domain registrars sold TLS certificates valid for eight to 10 years. The Certification Authority Browser Forum (CA/Browser Forum), a group of CAs, imposed a five-year limit in 2011. This was cut to three years in 2015 and to two years in 2018.

Historically, these changes were made in collaboration between browser makers and CAs, with the two parties debating rules and changes before voting on and implementing them – until a ballot proposing one-year validity was voted down by CAs at a CA/Browser Forum meeting. Following this, Apple broke standard processes and individually chose to enforce 398-day limits in Safari. 

Apple made its decision public in February and confirmed this change will only affect TLS server certificates issued from Root CAs on or after Sept. 1. Certificates issued before then won't be affected; neither will those from user-added or administrator-added Root CAs. Mozilla and Google have voiced plans to implement a similar rule in their browsers starting on Sept. 1.

The change will have consequences: Apple says connections to TLS servers violating its new requirements will fail, which may cause network and applications to fail and prevent websites from loading. Google warns certificates older than 398 days will be rejected with an error and treated as misissued. Apple recommends new certificates be issued with a 397-day validity.

Browser makers have long argued that shorter TLS life spans are better for browser security because they reduce the time frame in which attackers could compromise or duplicate a certificate, which is critical to protecting traffic to and from websites. A successful attack would give someone "the keys to the kingdom," says Lamont Orange, CISO at Netskope. As attackers look to move higher up the food chain, he says, this is precisely what they want. 

"This is better than username and password in a lot of ways," says Orange, of this level of compromise. Credentials may grant access to a system that could enable lateral movement across the environment. Access to a certificate could let an attacker do far more nefarious activities: control Web properties, access desktops and laptops, or encrypt communications.

"As a bad actor, I open up avenues that I can use for monetary gain, or to disrupt the system and be a nuisance, or just cause general frustration within different companies around the security of their infrastructure and Web properties," he explains.

Shortening the life span of TLS certificates will require businesses to frequently rotate them so by the time an attacker figures out how to copy one, it's no longer valid. The change will shrink the attack surface and cut down on dwell time, protecting organizations from compromise. 

In theory, it sounds like a benefit. In practice, it's likely companies will struggle to keep up with the challenges of renewing certificates and changing private keys used to authenticate them. 

Rotating TLS Certificates: Easier Said Than Done
The move to shorter life spans will come at an operational cost

"In general, shortening lifetimes is actually good for the ecosystem – it's not really something customers think about," says Dean Coclin, senior director of business development at DigiCert and former chair of the CA/Browser Forum. Now, he says, they'll have to worry about it more often.

These renewals can be done with automated tools; however, many businesses continue to do this manually, and larger firms may be responsible for renewing thousands of certificates. For administrators, it's an operational headache. If they fail to keep up, visitors to their website on certain browsers will see a warning the site isn't secure, which to many is a big red flag.

"When you look at the operational aspects of it, it can get pretty hairy," says Orange. "As a practitioner that has to deal with this ... there has to be a lot of planning that goes into how you migrate these certificates on an annual basis, roughly, and then understanding the applications taxonomy, or the website's taxonomy, to understand what potentially could break."

There wasn't much of a guideline on how to use certificates when they became popular, he adds, so many organizations and practitioners used a "wildcard certificate," or a public key certificate at the root of the certificate hierarchy that can be used with multiple subdomains. This made it easier to secure more assets but increased the risk if one was compromised.

Now it comes back to principles of architecture: Businesses must decide whether they need to rearchitect their use of certificates so it's not as challenging. Service providers want to make sure they're simplifying where possible, so they don't inadvertently cause system unavailability. 

The concerns extend beyond websites to Web applications, which may need to be refactored following this change, Orange continues. As TLS versions change, some applications may not be able to communicate on newer versions. Companies that rely on Web-based applications may notice a lack of functionality or run into more errors if their certificates aren't updated in time. 

"Some website owners find the process of securing their site to be difficult," says Robin Wilton, director of Internet Trust for the Internet Society. "Certificate installation is still not easy, and it's hard to carry out a complex process that only needs to be done every two to three years."

Next page: How your organization can prepare

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dwrightetc
50%
50%
dwrightetc,
User Rank: Guru
7/31/2020 | 8:59:44 AM
Big Tech using their power to dictate to the world
Yes, I would agree shorter SSL certificate life spans are more secure, mostly due to the fact that the more times you use and encryption key to encrypt data the more vulnerable the key becomes.  There are several tactics that cause this to be a "minor" issue.  I say minor issue because the amount of work that it takes to brute force a TLS certificate is well beyond most criminals purvue.  Most are generally going to attack the server and access the private key directly before the reuse issue will be an issue.  That said, a much greater threat to all of us is the continued software vulnerabilites that routinely show up in Big Tech software.  If they really cared about security they would focus on secure software development, securing our data on their servers, and back away from the massive invasions of inviduals privacy that they all engage in.  So it is for those reasons, I believe Big Tech is trying to distract us into believing they actually care about security and in this unilateral move are using their immense power to dictate behavior to the world.  We should all worry about the motives behind every move these companies make especially, when they bypass the normal standards processes that have been developed.  
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24213
PUBLISHED: 2020-09-23
An integer overflow was discovered in YGOPro ygocore v13.51. Attackers can use it to leak the game server thread's memory.
CVE-2020-2279
PUBLISHED: 2020-09-23
A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.74 and earlier allows attackers with permission to define sandboxed scripts to provide crafted return values or script binding content that can result in arbitrary code execution on the Jenkins controller JVM.
CVE-2020-2280
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Warnings Plugin 5.0.1 and earlier allows attackers to execute arbitrary code.
CVE-2020-2281
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Lockable Resources Plugin 2.8 and earlier allows attackers to reserve, unreserve, unlock, and reset resources.
CVE-2020-2282
PUBLISHED: 2020-09-23
Jenkins Implied Labels Plugin 0.6 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to configure the plugin.