Had a bad weekend? Probably, if you're a Sectigo customer, after root cert expires and online chaos ensues
- Reference: 1591077728
- News link: https://www.theregister.co.uk/2020/06/02/sectigo_root_cert_expires/
- Source link:
"Generally speaking, this is affecting older, non-browser clients (notably OpenSSL 1.0.x) which talk to TLS servers which serve a Sectigo certificate chain ending in the expired certificate," wrote Andrew Ayer, founder of SSLMate, in a [1]blog post .
When connecting to a TLS server, the server sends a certificate to the client to establish its identity, and an intermediate certificate that links the server cert to a trusted root certificate. This forms a chain of trust. When that chain breaks – because a certificate is invalid or missing – errors occur.
After the [2]AddTrust External CA Root and the [3]USERTrust RSA CA intermediate certificate expired, applications like [4]Red Hat Enterprise Linux 7 , [5]Roku's streaming media service , and [6]Algolia , started having problems.
Users of the RoboForm password manager found they could not connect to the RoboForm server.
Hello [7]@roboform , what's cooking? [8]pic.twitter.com/mxQKztHfTB — Peter Pushoofd (@pushoofd) [9]May 30, 2020
Some apps, like website monitoring app Oh Dear, [10]warned users ahead of time so they could remove the expiring certificate before things broke.
GCC 10 gets security bug trap. And look what just fell into it: OpenSSL and a prod-of-death flaw in servers and apps [11]READ MORE
Ayer's SSLMate also managed just fine. "I saw this coming over a year ago, and configured SSLMate to start providing a chain without AddTrust External CA Root," he wrote, in what we imagine was a slightly smug tone.
Ayer has been compiling [12]a list of affected applications and services on Twitter.
The damage as measured in time seems to be not more than a few hours. Heroku was down for about 70 minutes fixing things up. Turnitin [13]reported downtime of about 2.5 hours.
Modern browsers should not be affected because they're designed to use the SHA-2 root (COMODO or USERTrust) as an alternative trust chain. But applications that rely on older versions of OpenSSL and GnuTLS weren't designed to deal with bad certs.
"Lots of embedded software doesn’t handle this," said Ryan Sleevi, a Google software engineer, [14]via Twitter . "OpenSSL was, and is, fundamentally shit at verifying 'real' certificates. It has a long history of not coping with the Internet, and only really handling toy/enterprise-specific CAs that are linear. But even then, not very well."
El Reg readers report that UK-based cert biz Trustico and US-based SSLS.com have been issuing certificates that are suddenly failing because they were issued without checking that all the certs in the chain of trust are valid.
The Register asked SSLS.com for comment, and we've not heard back.
University of California, Berkeley has posted [15]a notification to systems administrators outlining potentially affected systems, such as Linux or macOS OpenLDAP clients.
Of particular concern, the university said, are systems and devices that haven't seen security updates since 2015, such as Apple Mac OS X 10.11 (El Capitan) or earlier, Apple iOS 9 or earlier, Google Android 5.0 or earlier, Microsoft Windows Vista & 7 (if the Update Root Certificates Feature has been disabled since before June 2010), Microsoft Windows XP (if an Automatic Root Update has not been received since before June 2010), Mozilla Firefox 35 or earlier, Oracle Java 8u50 or earlier, and embedded devices (e.g. copy machines) that have not installed a firmware update since before mid 2015.
"In a perfect world, all of your libraries would be up-to-date and you wouldn't be using clownish TLS implementations like GnuTLS," wrote Ayer. "But the world isn't perfect." ®
[1] https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration
[2] https://crt.sh/?id=1
[3] https://crt.sh/?id=4860286
[4] https://access.redhat.com/articles/5117881
[5] https://support.roku.com/article/360049417393
[6] https://status.algolia.com/
[7] https://twitter.com/roboform?ref_src=twsrc%5Etfw
[8] https://t.co/mxQKztHfTB
[9] https://twitter.com/pushoofd/status/1266696684823891968?ref_src=twsrc%5Etfw
[10] https://ohdear.app/blog/resolving-the-addtrust-external-ca-root-certificate-expiration
[11] https://www.theregister.com/2020/04/23/gcc_openssl_vulnerability/
[12] https://twitter.com/__agwa/timelines/1266777818811322368
[13] https://turnitin.statuspage.io/
[14] https://twitter.com/sleevi_/status/1266649215834390528?s=20
[15] https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
Re: the whole ecosystem is clownish becuase of Certification Authority (CA)
tied to DNS so that you know what law applies
The law of the jungle?
"Of particular concern, the university said, are systems and devices that haven't seen security updates since 2015, such as Apple Mac OS X 10.11 (El Capitan) or earlier, Apple iOS 9 or earlier, Google Android 5.0 or earlier, Microsoft Windows Vista & 7 (if the Update Root Certificates Feature has been disabled since before June 2010), Microsoft Windows XP (if an Automatic Root Update has not been received since before June 2010), Mozilla Firefox 35 or earlier, Oracle Java 8u50 or earlier, and embedded devices (e.g. copy machines) that have not installed a firmware update since before mid 2015."
"In a perfect world, all of your libraries would be up-to-date and you wouldn't be using clownish TLS implementations like GnuTLS," wrote Ayer.
The only clowns here are those still using obsolete crap...
It is not only old stuff
Also haproxy on weekly updated CentOS servers suffer from it. This SSL with its centralistic setup is just there to squeeze money out of people in collusion with the browser manufacturers. Why can organizations not easily integrate the CA functionality into their external DNS server, fill everything with self generated certificates instead of having to pay the SSL racketeering mob $ 100,- every year for each certificate ?.
Because Sectigo bought Comodo, certificates get invalidated.. thx a lot guys.
Re: It is not only old stuff
... fill everything with self generated certificates instead of having to pay the SSL racketeering mob $ 100,- every year for each certificate ...
Issuance of SSL/TLS certificates is not necessarily expensive -- the likes of Let's Encrypt provide free TLS certificates, after all. Some commercial certificates do look expensive by comparison, but some carry insurance against any fraud that may take place despite the security afforded by TLS. In those cases a large part of the payment is a premium paid to an insurance company.
Without that insurance the certificate has no material value, so it's not all racketeering.
TLS cert in DNS -> DANE
"integrate the CA functionality into their external DNS server"
you can do that now with DANE for example backward compatible for browsers :
[1]https://blog.apnic.net/2017/01/06/lets-encrypt-dane/
[1] https://blog.apnic.net/2017/01/06/lets-encrypt-dane/
They're not alone
Yesterday (1st July), I found that Startpage's TLS certificate had expired, stopping access cold. I got a response today from the helpdesk stating they're installing the new certificate "tomorrow sometime" (3rd July), so that's about three days of outage.
Failure to renew certificates on time is increasingly common, although the current record goes of course to Equifax, whose traffic monitor certificate was left expired for 19 months.
Re: Yesterday (1st July), (3rd July)
I see you have invented the 'Time Machine'.
Can't you use it to get into the Root Cert store and fix it?
However, as you say...
Failure to renew certificates on time is increasingly common
It will only get worse and we will see more 'Bork Bork' postings. Someone somewhere thought that Secure Certificates that expire was a good idea. Shame they didn't think it through properly esp wrt renewals. The annual costs for this must run into the billions or even the same as the GDP of a few countries.
Re: Yesterday (1st July), (3rd July)
Someone somewhere thought that Secure Certificates that expire was a good idea.
Expiry of key certificates is a crude way to ensure that old, obsolete, certificates get retired -- it was introduced before key revocation lists became commonplace . The idea is that if we believe that there won't be a practical attack on a given cryptographic key (for a given algorithm and key length) for N years, we can issue a certificate that's valid for no more than N years and can be reasonably confident that the key will be safe to use until after its certificate expires..
Of course, those who issue certificates commercially do so as a business. They make a profit each time they re-issue a certificate, so they have no incentive to sell very long-lived certificates.
Commercial certificates that offer financial guarantees against fraud are backed by insurance, and insurance companies are understandably reluctant to sell long-term policies, especially when the degree of risk increases unpredictably over time as attacks on the algorithm involved become more sophisticated. They want to asses the risk and set a premium for a relatively short term so that they can to set a higher premium or insist on a more secure algorithm on renewal if the degree risk has increased.
I'd suggest, in fact, that certificates should routinely be issued with a predictable short term -- say: one year -- so that updating them became a routine, well-understood, and unsurprising process.
"OpenSSL was, and is, fundamentally shit at verifying 'real' certificates"
Wow. Looks like there aren't many SSL-capable programmers that want to tackle the problem.
A shame for an open spec.
Optional
"In a perfect world, all of your libraries would be up-to-date and you wouldn't be using clownish TLS implementations like GnuTLS," wrote Ayer. "
In a perfect world twats like Ayer with product to sell and an axe to grind would be ignored by El Reg rather than quoted.
the whole ecosystem is clownish becuase of Certification Authority (CA)
honestly depending on where your certification authority (CA) is located is where the law applies and what help legally they can be compelled to provide...
personally I would prefer a system that is tied to DNS so that you know what law applies...