Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

51–60 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#51
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…

Not completely true. There's nothing to prevent customers to obtain a new certificate from a reputable CA while keeping the old one around for the embedded devices to use.

Re: Symantec CA Response to Google Proposal and Community Feedback

#52
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…

If the embedded devices are accessed over the net by Chrome, or access services that also need to be accessed by Chrome, then there is an issue.

But I don't think Google is going to be swayed by "you can't distrust us if we do wrong because too much depends on us" because if they do, it encourages laxness at big CAs.

Re: Symantec CA Response to Google Proposal and Community Feedback

#53
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…

Imagine the embedded device or mobile app connects to a https://api.example.com/... and so does their web app. They need to use a new certificate for api.example.com, signed by a different CA root, because when Chrome tries to run the web app it won't trust the old certificate, nor a new cert signed by the old root. So they get a new cert signed by a different root so Chrome works, but then the embedded or mobile apps stop working.

In this case the story is more complicated - I think new certificates signed by existing Symantec CA roots would be trusted if their duration is 90 days or less. Historically, most CAs offered one, two, or three year duration. Presumably, the "big customers" would not accept the need to rotate their certificates for this purpose in less than 90 days, they need their 3 years because it takes over 90 days to get something through their bureaucracy. And presumably there are other things they can't do in 90 days, like update an embedded device configuration or firmware, or a mobile app.

Of course it depends on the particulars, but of course these "big customers" can't figure any particulars out in 90 days. But that's why Google proposed a slow sliding scale that would gradually reduce the max duration allowed over the course of a year, so random unknown stuff breaks more gradually throughout the year, not in one huge event like Symantec's blog post suggests.

Re: Symantec CA Response to Google Proposal and Community Feedback

#54

Earlier quoted context omitted.

Mozilla seems in total agreement with Chrome on this, and it also takes unilateral CA authority action. This is not a negotiation where the orgs have the right side of the power dynamic.

It's always a negotiation. He who has the least to lose wins. "Why isn't my browser working??" "So sorry about that, those darn nerds made a change on us." I have seen this exact scenario play out. Mozilla and Google might be respected in the tech community; to most people they're an extremely tiny part of their life. "Your the IT man, just make it work"

You're arguing "Right" vs. "Easy".

Re: Symantec CA Response to Google Proposal and Community Feedback

#55
post #18

Earlier quoted context omitted.

"Buying" as if Let's Encrypt isn't a thing. ;-)

If you think Let's Encrypt is an acceptable solution for all the affected organizations, you know very little about the state of browser certificates.

Or they see through it.

Re: Symantec CA Response to Google Proposal and Community Feedback

#56

> 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 public discussions, particularly in an area related to security. Are these large organizations somehow incapable of putting out official statements regarding CAs? If they're be…

To me it was really bold of them to take the tone and stance that they did with regard to these large organizations. They're making the case as to why Google needed to do what it did ... all of these large organizations that will be severely impacted by having to replace all of these certificates are relying on a CA that has shown itself to not be worthy of the trust that CAs are relied upon to provide.

I'm at a loss for a good analogy so I'll pick a lousy one: it'd be like if Samsung's response to the exploding Note 7 recall mandate were "Don't do this -- you're going to keep some of the biggest customers -- users of our phones -- from being able to make emergency calls/check their e-mail/respond to texts" ...yeah, but I'm still not OK with the small possibility that carrying my phone in my front pocket might result in third-degree genital burns.

Re: Symantec CA Response to Google Proposal and Community Feedback

#57
post #17

>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…

Isn't that largely Google's stance with regard to Android? They blame the carriers and point to how slow they are, meanwhile tons of smart phones go without patching, which is no good for the general internet or users'

I'm constantly amazed by how some people think Google has this magical ability to update an OS that was built by another OEM. That's like asking Debian to update Ubuntu.

Re: Symantec CA Response to Google Proposal and Community Feedback

#58

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.

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.

If you're going to automatically create certificates you are shifting the entire authentication burden to that automated system.

This is the exact issue with the public CA system, their automated processes have been found lacking and now what they certify can not be trusted.

Re: Symantec CA Response to Google Proposal and Community Feedback

#59

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.

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.

[deleted]

Re: Symantec CA Response to Google Proposal and Community Feedback

#60
post #54

Earlier quoted context omitted.

It's always a negotiation. He who has the least to lose wins. "Why isn't my browser working??" "So sorry about that, those darn nerds made a change on us." I have seen this exact scenario play out. Mozilla and Google might be respected in the tech community; to most people they're an extremely tiny part of their life. "Your the IT man, just make it work"

You're arguing "Right" vs. "Easy".

Easy there Tex, I'm not arguing. I am simply describing the behaviors between large orgs in a dysfunctional ecosystem/marketplace.

As you get older, you transition from "this is how it should be!" to "this is how it works, what is a realistic amount of change that can occur?"

Post reply on HN