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
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.  
Cloud Security Threats for 2021
Or Azarzar, CTO & Co-Founder of Lightspin,  12/3/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Assessing Cybersecurity Risk in Todays Enterprises
Assessing Cybersecurity Risk in Todays Enterprises
COVID-19 has created a new IT paradigm in the enterprise and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27772
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in coders/bmp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned int`. This would most likely lead to an impact to application availability, but could po...
CVE-2020-27773
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/gem-private.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned char` or division by zero. This would most likely lead to an impact to appli...
CVE-2020-28950
PUBLISHED: 2020-12-04
The installer of Kaspersky Anti-Ransomware Tool (KART) prior to KART 4.0 Patch C was vulnerable to a DLL hijacking attack that allowed an attacker to elevate privileges during installation process.
CVE-2020-27774
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/statistic.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of a too large shift for 64-bit type `ssize_t`. This would most likely lead to an impact to application availability, but co...
CVE-2020-27775
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/quantum.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned char. This would most likely lead to an impact to application availability, but c...