Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

41–50 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#41
post #32

> Embedded devices that are pinned to certificates issued by a Symantec public root to communicate to resources over the Internet or Intranet. Replacing these certificates would result in immediate failures and the need to recode and reimage the firmware for these devices. > Mobile applications that have pinned certificates. Replacing server certificates would require these applications to be recoded, recompiled and…

It was either a bizarre misunderstanding on what will happen on Symantec's side, or "pinned" was used not in the technical meaning.

I could see someone translating "these devices use Symantec's server certs and serve web traffic" to "these devices are pinned to certs issued by Symantec". But if that's the case, they should pay more attention in announcements like this one...

Re: Symantec CA Response to Google Proposal and Community Feedback

#42
post #38

>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now on and suffer no consequences, cause it'd be really shitty for us if we had to be penalised". They also posture a lot talking about how big their customers are, almost boasting about how inflexible and slow these big companies are, as if that's somehow Google's…

This comment irritates me. 1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply ma…

Part of the premise of Google's plan is that Symantec's customers will experience disruption. If you poll Symantec's customers, the overwhelming majority of them will day "no, don't punish our CA". We didn't need Symantec to tell us that.

On the other hand, Symantec's CA was caught mis-issuing certificates. That affects everyone, not just Symantec's own customers.

Re: Symantec CA Response to Google Proposal and Community Feedback

#43
post #32

> Embedded devices that are pinned to certificates issued by a Symantec public root to communicate to resources over the Internet or Intranet. Replacing these certificates would result in immediate failures and the need to recode and reimage the firmware for these devices. > Mobile applications that have pinned certificates. Replacing server certificates would require these applications to be recoded, recompiled and…

I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.

Re: Symantec CA Response to Google Proposal and Community Feedback

#44
post #2

I don't think Google was soliciting for a counter proposal from Symantec. Will be interesting to see their reply, and whether it's a literal reply or just a version push of chrome with their original plan.[1] [1] https://groups.google.com/a/chromium.org/forum/m/#!topic/bli... Edit: They did ask for community feedback, comments on risk, etc. But they do already have a timeline. See link above.

"This site does not support Chrome. Please use a browser that does not take unilateral CA authority action." might very well be the response of orgs married to Symantec. As a user, you need your bank (or other large org) more than you need your preference of browser.

I disagree, a bank should especially be knowledgeable of security (and certificate) issues. I've switched banks because of bad security practices before, it's a simple matter of voting with your feet.

Re: Symantec CA Response to Google Proposal and Community Feedback

#45
post #28
post #9

Earlier quoted context omitted.

Bold move though, when the fix is just buying a new cert. And the browser you're blocking has majority market share.

Certificate pinning means it's a hell of a lot more than just "buying a new cert".

Finally, there's some value in, and a reason to, picking a responsible CA instead of the cheapest or most convenient one!

Re: Symantec CA Response to Google Proposal and Community Feedback

#46
post #6

Earlier quoted context omitted.

Given some of the internal CA systems I've dealt within the past, I'd almost prefer a public CA in some cases. Sometimes your internal CA is just the group with manual access to the certificate provisioning and signing systems with either no API or some awful re-implemented API.

What API do you need? The signing system should be airgapped or you end up with the same shit that is the public CA system such as roots sitting on public FTP servers. It's a bunch of command line scripts because if you are using it any different way you are probably doing it wrong.

There's more to it than you've seen so far. Think about environments with hosts starting on demand. You need to encrypt data in flight -> how do you automatically assign a new certificate to an instance on startup? You can't do it with an airgapped system.

Re: Symantec CA Response to Google Proposal and Community Feedback

#47
post #25

> These customers include many of the largest financial services, critical infrastructure, retail and healthcare organizations in the world, as well as many government agencies. This cohort is an important constituency that we believe has been under-represented to date in the public commentary that has been posted to the Google and Mozilla boards since large organizations rarely authorize employees to engage in such…

> These are some of the most important organizations in the world and you'll cause worldwide chaos

Thanks for that -- reading this comment connected a few thoughts I was struggling with.

Their response felt like "if you don't follow through with your plan to punish us we'll do all of these nice things for you." It reminds me of when my kids get caught doing something wrong and I get "but I'll do all of my chores and treat my siblings nice" along with a handful of other promises of future deeds which I know will be partially or completely not-done. How different the result would have been if they came to me with the chores done and some/all of the promises fulfilled already. It would have been much better for Symantec to have responded with these items in the "completed" category with a smaller number of "we will's".

But to the quote I highlighted: the issue at hand is the past failures indicate that "some of the most important organizations in the world" need to not be trusting Symantec in the first place. They've had a big enough history of failures as a CA to get the attention of Google, who I'm sure isn't terribly interested in degrading the browsing experience of their customers. The choice becomes: (1) Banhammer Symantec, take the resulting pain all at once, visibly and obviously, and get the problem fixed painfully (but it's fixed) or (2) Trust that things will be different this time and if they're not, have another security failure of some kind that results in these critically important company's customers' data being exposed, which is a circumstance that will almost certainly go unnoticed for a period of time, will be covered up if the exposure is minimal and covering up the exposure is possible or may not be discovered at all. The CA system is centered around trusting a handful of rather powerful bodies with an enormous responsibility around the overall security of the Internet. It's not a great model to begin with, but it's what we have and I haven't read about any alternatives that are viable. The only way to keep a model like this secure is to ensure that the CAs themselves are actually trustworthy and one of the more likely ways that will happen is to enforce violations of that trust in the manner Google is suggesting.

Re: Symantec CA Response to Google Proposal and Community Feedback

#48

Earlier quoted context omitted.

What API do you need? The signing system should be airgapped or you end up with the same shit that is the public CA system such as roots sitting on public FTP servers. It's a bunch of command line scripts because if you are using it any different way you are probably doing it wrong.

Seriously. The fancy CA systems are wacky expensive.

I'm sure people make plenty of money wrapping OpenSSL in ever more elaborate Enterprise schemes.

But if the net effect is that one bug in a frontend can cause the server to tell the cert server to tell the secure enclave to tell the wire mesh protected crypto coprocessor to sign a bogus certificate then what are we really doing here.

Re: Symantec CA Response to Google Proposal and Community Feedback

#50
post #38

>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now on and suffer no consequences, cause it'd be really shitty for us if we had to be penalised". They also posture a lot talking about how big their customers are, almost boasting about how inflexible and slow these big companies are, as if that's somehow Google's…

This comment irritates me. 1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply ma…

> The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people."

The real question is, what effect would doing nothing have on all of those people? If Symantec continues to mis-issue certificates (as they have done repeatedly: https://wiki.mozilla.org/CA:Symantec_Issues), keeping their EV status intact could be much, much worse for them.

> As the blog post states explicitly, there are a lot of use cases where updating a deployed app is very difficult, almost impossible, or cost prohibitive.

As others have pointed out, this change would actually have no effect on the 'complex dependencies' Symantec identified:

* This has absolutely no effect on embedded devices, which are certainly not running Chrome. * Mobile applications that pin certificates shouldn't be affected, since the very fact that they're pinning certificates means they're not using Chrome (there's no way for an app to tell Chrome to pin a specific certificate).

Post reply on HN