Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

71–80 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#71
post #39
post #38

Earlier quoted context omitted.

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." not doing something is allowing the previous lack of security standards to put all of those people in danger. there is a tradeoff with every decision. the entire PKI ecoysystem relies on self management and I think google is making a tough decision, but one that ultimately ha…

> not doing something is allowing the previous lack of security standards to put all of those people in danger.

So glad others are making this point. Not to mention that the CA system is one who's sole feature and only purpose is trust. There is zero security if you can't trust the root. We'd love to live in a world where providing security didn't require a trusted third-party, but that's not the world the internet operates on, today. Transparency is provided by establishing strict guidelines and expectations for CAs. Maintaining this trust is enforcing those guidelines equally among the CAs regardless of size/scope and punishing (preferably severely) any violations. Otherwise the old saying of "rules that are not enforced are just suggestions" comes into play.

Because it's a trust-based model, the consequences for violations of that trust have to be strong enough to make a compromised actor willing to refuse government intelligence divisions, corporate criminal actors or even organized crime that has the resources and could stoop to any level of blackmail/bribery to squeeze out a certificate that would allow one to spoof a connection to a high-value target like Amazon, Google, Paypal or Microsoft.

Re: Symantec CA Response to Google Proposal and Community Feedback

#72
post #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 ap…

An easier way around this sort of issue is to change their web app to use a different domain, and only put the new certificate from a different CA on that domain. It's not necessary to update every device.

Embedded devices => https://api.example.com (Symantec cert)

Browsers => https://new-api.example.com (New trusted cert)

Another approach is that if the devices are old enough they're probably using a deprecated version of TLS, so the existing https://api.example.com server could choose which certificate to issue based on the version of TLS offered by the client.

Re: Symantec CA Response to Google Proposal and Community Feedback

#73
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.

Iirc you can have certs signed by multiple roots though, right? In which case these sites can just get their cert signed by the pinned symantec root and a real still-valid root. Nobody's stopping symantec from signing new certs, they just won't work in Chrome (and likely other browsers)

Or maybe I've misunderstood the situation.

Re: Symantec CA Response to Google Proposal and Community Feedback

#74
post #17

Earlier quoted context omitted.

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.

They set the terms for licensing Android, and have used leverage for other things they want or don't want.

Edit: Yes, really. https://arstechnica.com/gadgets/2014/02/new-android-oem-lice...

Re: Symantec CA Response to Google Proposal and Community Feedback

#75
post #63
post #47

Earlier quoted context omitted.

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

Yup. It's very interesting that the argument from Symantec is that their customers have to buy Symantec certs indefinitely - not that they can't replace existing certs in servers, but they've hardcoded the Symantec root in enough clients, such that buying certs from a Symantec competitor will break their clients. Among other things, if what Symantec is saying is true, this means there is zero financial incentive for…

I hadn't read it that way and that's a really good point.

If you have too many trusted-third parties in a trust model like this, you run into difficulties with enforcement due to scaling problems, but what we're seeing is the converse of that. Symantec went out and bought up other CAs (Verisign is the only one I can remember for some reason) and they've become so large that them losing CA status would be prohibitively damaging to the internet-at-large. This affects not only enforcement (we don't want to move on a bad actor because the consequences of enforcement would be more severe than the consequences of a rule violation), it also negatively affects the trust model -- now if I'm a bad actor, Symantec is my only target -- even though I could attack the others and yield some of the same benefits of attacking Symantec, if I breach Symantec, the rewards are larger by several orders of magnitude depending on what they store and how they store it.

To digress a little ... today ... I'm not all that surprised that Symantec has reached sort-of monopoly status in this area. Not because Symantec is a well managed company (I'm making no statement for or against that despite my personal opinions), but just because so much of The Internet has turned out this way. If you would have told me in 1998 that for the very vast majority of US Internet users, there'd be one search engine, one e-commerce company, one (expensive) ISP, one e-mail provider, all of it would be secured by services provided by one company's CA and all of that wouldn't matter much because the typical Internet experience would basically be a web-enabled, bluer version of AOL[0], I'd have called you some unfriendly things, but that's where we are. It's a centralized system operating on decentralized technology.

[0] Oh, and that the "one e-commerce company" was that bookstore web-site and would be responsible for hosting such a large part of the rest of the Internet that when they had a major failure and people had that handful of rare clicks off of FAOLBook, they'd have about a 50% chance that whatever their target was wouldn't load.

Re: Symantec CA Response to Google Proposal and Community Feedback

#76
post #34
post #28

Earlier quoted context omitted.

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

Ah, yes. If you didn't have a backup cert from another provider and missed your 60 day window. But what was your plan for any other incident that required revocation? I assume anyone turning on pinning hand wrings over it for a while first.

You can pin to the CA intermediate cert, which means revocation isn't a problem as long as you keep the same CA.

Re: Symantec CA Response to Google Proposal and Community Feedback

#77

I love how none of the example "dependencies" they give should be using public CA in the first place.

I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of suppo…

> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs.

What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption.

In this example, the device trusts the Symantec CA, and the server presents a certificate signed by the Symantec CA. Everything's hunky-dory. What's the problem?

Re: Symantec CA Response to Google Proposal and Community Feedback

#78
post #17

Earlier quoted context omitted.

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'

No, there's a huge difference. The difference here is that the Manufacturers and the Carriers are gatekeepers to the customer's phones. The manufacturer made customizations to Android for their phone. Android isn't a cleanly-separated stack where the manufacturer modifies only a certain part of the stack for their phone but Google could go and update another part without risk of breaking anything (is any software pro…

Google holds all the cards. They have to sign off, or the phones will lose access to the Play Store and Google services like Maps. Google only needs to play the cards it already holds.

Re: Symantec CA Response to Google Proposal and Community Feedback

#79
post #54

Earlier quoted context omitted.

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?"

i would say the relevant "this is how it works" is having a globally trusted CA system that isn't abused by large CAs just because they think no one will dare punish them. What would any of these large Symantec customers says if in the future their security was compromised due to mis-issued certificates? I doubt they'd be thrilled they were saved some dev time getting their certificates signed by another root in exchange. it's very clear from Symantec's language here and elsewhere that they wouldn't be doing shit about this is chrome weren't taking it so seriously

Re: Symantec CA Response to Google Proposal and Community Feedback

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

Symantec should have thought about this before using half ass processes and half ass people in a business that will cost other people money because of their screw ups.
Post reply on HN