Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

groups.google.com

Post reply on HN
Print view View original

151–160 of 329 posts

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#151

Post by iancarroll »

DaiPlusPlus wrote: post #142
iancarroll wrote: post #102

Earlier quoted context omitted.

Symantec took one of their widely trusted root certificates and declared that it was now "off the reservation", meaning they may choose to not comply with the BRs for its leaf certificates. I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.

But how or why was this done as a favour for their banking customers?

Banks and companies like First Data were the (sole?) source of exception requests for SHA-1 issuance past the date it was prohibited.

Given the G1 root they pulled has an intermediary called "Symantec Trust Services Private SHA1 Root CA", I can make some guesses...

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#152

Post by teraflop »

londons_explore wrote: post #148
tptacek wrote: post #129

Earlier quoted context omitted.

This is a good summary, but I'd clarify it by saying that Google isn't being subjective about Symantec's process failures. The CA industry self-regulates. Its regulatory organization is the CA/B Forum, and their principal regulation is the Baseline Requirements (the BRs). Google claims Symantec violated multiple BRs. If you want to dig a little deeper, here's the last version of the BRs: https://cabforum.org/wp-conte…

Have they published anywhere the violations? Normally browser makers publish openly evidence of mis-issued certificates, together with having the discussion with the vendor in the public. It's sad that this announcement from Google seems to basically be saying "we had a closed door dispute with Symantec, and now don't trust them".

The issue has gotten plenty of public discussion (from Google, Mozilla, and others) on Mozilla's dev-security-policy mailing list: https://groups.google.com/forum/?fromgroups=#!forum/mozilla....

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#153

Post by ajnin »

jlgaddis wrote: post #39
DaiPlusPlus wrote: post #30

Earlier quoted context omitted.

They're also planning on stripping EV status from their Certs too... that's going to be fun for a lot of banks.

"effective immediately"

They mention the issue is treated as a "medium priority" security issue, which means it should land in the next stable version according to their guidelines (https://www.chromium.org/developers/severity-guidelines)

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#154

Post by agwa »

pilom wrote: post #112
agwa wrote: post #99

Earlier quoted context omitted.

https://www.mail-archive.com/dev-security-policy@lists.mozil...

TL;DR: in 2016 Symantec issued unauthorized certs for example.com (owned by ICANN) and a multi-domain cert with SANs for test1.com, test2.com, test3.com... even though those domains are each owned by very different organizations and did not all agree to have a common cert.

It's more than that. The ensuing thread uncovered that Symantec had exercised very lacking oversight over their partners (called Registration Authorities, or RAs) who were allowed to perform certificate validation on Symantec's behalf.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#155

Post by jacquesm »

pauldino wrote: post #135
DaiPlusPlus wrote: post #88

Earlier quoted context omitted.

It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA'…

So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing! https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#156

Post by ygjb »

pauldino wrote: post #135
DaiPlusPlus wrote: post #88

Earlier quoted context omitted.

It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA'…

So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing! https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea.

It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular.

Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel.

Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests.

Jeez. Remembering why I used to drink more when I worked in fintech :)

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#158

Post by tscs37 »

inglor wrote: post #133
jf wrote: post #121

Earlier quoted context omitted.

> which means we need an initial set of trusted CAs. How would you validate that the initial set of trusted CA roots is actually from those CAs?

It ships with your operating system, which you physically obtain from another computer (with hardware like a USB drive or via internal network).

But how to trust that this other computer has a good set of CAs?

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#159

Post by uzoodoo »

Animats wrote: post #145
dmix wrote: post #41

Earlier quoted context omitted.

Banks can just switch to better SSL services...

Somebody needs to tell Bank of America. They're still presenting a Symantec EV cert.

So is Chase, Citi, PNC, Schwab, TD, ...

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#160

Post by jsfitzsimmons »

tajen wrote: post #123
NateyJay wrote: post #2

This is huge, Symantec owns about 15% of the SSL certificate market[1], and as stated in the article, has issued 30% of in-use certificates. No certificate authority of this size has ever been raked over the coals like this. [1] https://w3techs.com/technologies/history_overview/ssl_certif...

Am I the only one worried about LetsEncrypt becoming a monopoly? This move from Google is, indirectly, a huge service for them.

The implementation is open source. You can launch your own ACME server (valuable for testing), and use that. CAs implementing this technology obviously need to go through the same hoop-jumping in order to become trusted, but that's true of any strategy of starting a CA.

The technology is available for any CA, existing or new, to copycat.

And if they don't want to use the open source reference implementation, they can cleanroom an ACME server that works with all the existing clients that work with letsencrypt.

Post reply on HN