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

311–320 of 329 posts

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

#311

Post by kartickv »

snowwrestler wrote: post #309
kartickv wrote: post #274

Earlier quoted context omitted.

Pissing off Symantec customers is a necessary evil in this case. It's a sign that the strategy is working.

Some Symantec customers are in a position to file a complaint with Google well over the heads of the Chrome cert team. Some have many $millions of transactions dependent on Symantec certs, and aggressive legal staff. Imagine if Chrome started reporting all Apple and Microsoft domains as insecure, with no warning. That's straying into very deep waters. To be clear: I support Google's action against Symantec, and it is…

You can't compare Symantec with Apple and MS, since Apple and MS are competent.

If you think someone might sue Google, on what basis? And Google is more than capable of defending itself.

I agree about the time needed to make an orderly change, which is why I didn't propose that connections fail yet, only that they not be presented as secure in the UI.

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

#312

Post by victorhooi »

wiml wrote: post #279
DaiPlusPlus wrote: post #33

Earlier quoted context omitted.

Installing apps from other stores on Android is literally a checkbox away - but installing new root certs on computers is considerably harder, or impossible if your computer is locked-down (group policy, etc).

Installing new roots on Macs, iOS, and Android devices is really easy. It's mildly inconvenient on Linux desktops.

It's actually no longer possible on Android, without jumping through significant hoops:

https://android-developers.googleblog.com/2016/07/changes-to... https://news.ycombinator.com/item?id=12061320 https://github.com/mitmproxy/mitmproxy/issues/2054

And it's really not the sort of thing your average non-technical user is likely to do - and trust me, having supported these users before, it's likely to go horribly wrong if you try providing steps for them.

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

#313

Post by voidlogic »

TOMDM wrote: post #229
voidlogic wrote: post #196

Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?

Let's be honest, switching your cert is a far cheaper option than the lost business of telling 50% of your users that they need to switch browsers. Whith ecommerce sites being so hyper focused on abandoned cart stats, this is the easiest change they'll make all year.

For ecommerce yes, but the people most impact here are prob. banks... and if somones back tells them they have to install and use FF or use Edge over Chrome, they will probably do it.

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

#314

Post by FireBeyond »

snowwrestler wrote: post #309
kartickv wrote: post #274

Earlier quoted context omitted.

Pissing off Symantec customers is a necessary evil in this case. It's a sign that the strategy is working.

Some Symantec customers are in a position to file a complaint with Google well over the heads of the Chrome cert team. Some have many $millions of transactions dependent on Symantec certs, and aggressive legal staff. Imagine if Chrome started reporting all Apple and Microsoft domains as insecure, with no warning. That's straying into very deep waters. To be clear: I support Google's action against Symantec, and it is…

That would be a significant barrier to overcome.

It's not tortious interference with Symantec's business (who are still "free" to issue whatever they like).

Google is under no obligation and cannot or should not be coerced into saying "You have to accept Vendor A's CA so that they can continue to represent Vendor B's SSL certificate as 'secure'."

That's also very deep water that might result in some 'diplomacy' but with little actual legal position.

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

#315

Post by snowwrestler »

kartickv wrote: post #311
snowwrestler wrote: post #309

Earlier quoted context omitted.

Some Symantec customers are in a position to file a complaint with Google well over the heads of the Chrome cert team. Some have many $millions of transactions dependent on Symantec certs, and aggressive legal staff. Imagine if Chrome started reporting all Apple and Microsoft domains as insecure, with no warning. That's straying into very deep waters. To be clear: I support Google's action against Symantec, and it is…

You can't compare Symantec with Apple and MS, since Apple and MS are competent. If you think someone might sue Google, on what basis? And Google is more than capable of defending itself. I agree about the time needed to make an orderly change, which is why I didn't propose that connections fail yet, only that they not be presented as secure in the UI.

Apple and Microsoft buy their TLS certs from Symantec. All their sites would be affected if Chrome abruptly stopped trusting Symantec certs overnight.

Imagine if everyone going to Apple.com in Chrome suddenly saw "site insecure" when they were trying to buy an iPhone--an area where Google is a direct competitor.

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

#316

Post by tialaramex »

ivanr wrote: post #206
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…

Small correction: the CA industry doesn't self-regulate. Both browsers and CAs participate in the CA/Browser Forum and my (admittedly outsider) impression is that browsers almost always have the upper hand.

CA/B is neither a regulator nor, formally, a Standards Development Organisation although if you can squint it can look a little like either. CA/B produces the Baseline Requirements and also a set of EV Guidelines, for how a CA should behave.

The browser vendors (actually mostly OS vendors in their guise as browser vendors, Mozilla effectively stands in for all the Free Unix type operating systems) operate trust roots, and each of them decides their own criteria for things to appear in those roots.

BUT there was concern as the root store programmes began to tighten up their criteria that they might step on each others' toes, CA/B is a forum to share common principles. For example, rather than Mozilla tell CAs to stop issuing certificates that last more than 2 years plus a few days, and Google tell them not to issue ones that last more than 25 months, and then Microsoft say they want a rule forbidding new certificates that last more than 750 days, everybody got together at CA/B and passed a Baseline Requirements change setting the limit at 825 days from next year.

CA/B looks a lot like a cartel (all the companies in an industry meeting up to agree things) so it has a bunch of things it mustn't do to ensure it doesn't break anti-cartel legislation and get anybody sent to jail [The world's most famous cartel, OPEC, doesn't fear the law because OPEC is run by governments and governments have sovereign immunity]. For example it can't talk about prices, or future products.

Another result of not being a cartel is that CA/B doesn't bind either CAs or Browsers. The CAs can break CA/B rules without being kicked out of CA/B and the Browsers can and do require things beyond the Baseline Requirements, for example Microsoft requires every CA in its programme to revoke any certificate it tells them to, on demand.

Initially CA/B was all about smoke-filled rooms (maybe not literally) but Mozilla and Google have pressured them to gradually act more in the open, so you can actually follow along most of their decision making in real time via their mailing lists.

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

#317

Post by tialaramex »

agwa wrote: post #228
gsnedders wrote: post #220

Earlier quoted context omitted.

Things that go to vote in the CAB Forum are often split pretty exactly down CA v. browser lines, and the CA outnumber the browsers and hence typically win. That said, the power of the browser vendors as those who maintain the trust stores is obviously there.

This is not accurate. To pass, a ballot must receive a 2/3 majority from CAs AND a 1/2 majority from browsers. While there have been some contentious votes along CA-browser lines, you can see from the ballot history that most ballots have passed and thus had support from both browsers and CAs: https://cabforum.org/ballots/

If they can't get their way, the browser vendors can just shrug and make their own rules, that's what happened for Ballot 169 for example.

Ballot 169 says to validate DNS names in a certificate you can't just make up any old "validation method" and say you think it's adequate, you must use at least one of these specific enumerated methods.

The Ballot passed, but then a bunch of CAs declared that they had patented some of the methods on the list. So effectively even though it passed Ballot 169 was unwound while they negotiated patent licensing agreements.

But Mozilla meanwhile went "everybody must obey Ballot 169 or get kicked out of Mozilla's trust store", so that raised the bar anyway.

The happy news is that a mix of Mozilla saying "comply or feel free to go out of business, we don't care" and people like me pointing at the crappy patents and laughing at their weak excuse for "innovation" appears to have had the desired effect, and a new Ballot will reinstate the stuff from Ballot 169 later this year.

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

#318

Post by tialaramex »

kawsper wrote: post #290
caf wrote: post #242

Earlier quoted context omitted.

The main thread is https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... , and it contains some nuggets like this: So after reading this, the following auditors aren't trusted by Symantec anymore: - E&Y Korea - E&Y Brazil The following isn't trusted by Mozilla anymore: - E&Y Hong Kong This seems to be a worrying trend to me. Kurt

I was curious if E&Y was Ernst & Young, and indeed it is, apparently they go by the name of EY now. I found this attached PDF interesting as well: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831...

Yes, each of the Big Four isn't really a single company, that'd be too vulnerable to lawsuits when (let's face it, not if) they screw up. Instead they're a network of companies licensed to use the same name.

Mozilla was asked (I do not know if they actually did it) to have one of their London people stroll over to EY's headquarters building in that city and explicitly let them know about the Hong Kong EY's failures so that there's no opportunity to later pretend EY as a network didn't know this was a problem.

The nature of audit work, both for the Web PKI and for business accounting means that "capture" is a big problem, the auditors get paid by the company they're supposed to audit and further work is conditional on giving a good report, so, why look for trouble? Failure is inevitable.

If you're wondering when it became the Big Four, the Big Five had one more member, they audited Enron and signed off accounts which bore no resemblance to reality, then when they realised it was being investigated they destroyed all evidence of what they'd done. The resulting scandal destroyed them, although the US Supreme Court eventually decided that the people who ran the audit firm and gave orders to cover up what it had done were innocent...

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

#319

Post by tialaramex »

jasode wrote: post #114
gcp wrote: post #105

Earlier quoted context omitted.

This line of reasoning works for banks or commercial entities. But note, it does not work for governments. They can, and will, put up a red banner instructing the user to install another browser (or in case of Firefox 52, explain how to disable updates so you can keep using NPAPI plugins).

Interesting point. I spot checked CAs for some of the most popular USA government websites. irs.gov (Internal Revenue Service): Entrust CA va.gov (Veterans Affairs) : Symantec CA So if Symantec is the CA for a critical mass of government websites that won't abandon them, Google Chrome could lose this battle. Without looking at traffic data (e.g Alexa), my intuition says the vast majority of web traffic is not governm…

The US Federal Government has stated a long term plan to operate a CA in the Web PKI, because after all it does operate a whole shitload of web sites, and it has secure buildings and trustworthy employees needed to run the CA. Like some other government-owned CAs it has offered up front to limit its CA to a TLD it controls anyway (in this case gov) so it won't be offering certificates to the general public.

They don't have a formal proposal yet, such proposals take anywhere from 6-18 months to process once they come out, and so the IRS or Veterans Affairs won't be getting new certificates from them in 2017, but in 2018 that's definitely a possibility.

Of course, a US Federal Government CA in the Web PKI would be problematic for Google, Apple, Microsoft or Mozilla (all US corporations) to distrust later if things go wrong, this is doubtless why they ask to limit to one TLD, defusing concerns in advance...

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

#320

Post by tialaramex »

unethical_ban wrote: post #191
jldugger wrote: post #140

Earlier quoted context omitted.

> I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust? It doesn't. You can adjust your root certs in Firefox by going to about:preferences#advanced and clicking on certificates. But what does partial trust look like? Showing half of the HTML? An eyebrow raised emoji instead of a lock?

I wish CA management was easier to bulk-edit. Show me a table of root CAs with their data, their country of origin, etc., and allow me to filter and enable/disable all based on filters. Full disable would shut down trust entirely, and get the warnings similar to a self-issued cert. Reduced trust would have a "not Secure" label or something, like a plain http connection.

"Country of origin" is a really interesting one for precisely the Symantec scenario.

Symantec is a US company right? But the main _problem_ happened at a company called CrossCert, full name Korea Electronic Certification Authority. They're Korean.

So if you decided you don't trust Koreans, Symantec's root looks fine, nothing Korean about that. Except, somewhere Symantec signed a contract with CrossCert saying "OK, we'll issue any certificate you want, so long as you pay us and promise to do all these things". Oh, and then they didn't actually check CrossCert did any of the other things (I think we can assume they checked they got paid...). You don't get to see that contract. It wasn't even prohibited by the rules Symantec had agreed to. If Symantec hadn't been caught issuing bogus certificates as a result you wouldn't even be reading about it.

Post reply on HN