4 ms·

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

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 mandate that Chrome is no longer an acceptable browser. For external applications, companies would have to engage in an enormous PR effort to communicate to customers that their product doesn't work with Chrome. These companies have done nothing wrong, but they're the one being punished, as customers don't know and don't care about cert issues. 2) "Updating" can be an enormous effort. 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. Again, remember that the person being punished here is not Symantec; you're publishing some poor development company who happened to use Symantec—one of the most popular cert providers on the planet—for an SSL cert. Not good. I'm not taking sides on the issue, because I honestly don't know that much about it. But comments like the above really trivialize the huge impact that something like this will have.

fosco 9y ago
>) 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 has already led to better decisions regarding security.
- mdip 9y ago
  > 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.
tptacek 9y ago
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.
- mentat 9y ago
  The "survey" that accompanied the original customer facing message was so biased as to be ridiculous. Like "Will Google's proposed change be disruptive, massively disruptive, or business ending for you?"
Aaron1011 9y ago
> 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 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).
bayfury 9y ago
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.
kevinburke 9y ago
They've been playing the same game for literally 10 years https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089 https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...
fredsanford 9y ago
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.
ryandrake 9y ago
Unless your software is running on a 30 year old embedded system, located in a submarine, 5KM below the ocean, guarded by tigers, and stuck there for the next decade, it's hard to muster sympathy about how hard updating your software is. If the cost to a company to deploy an update their software is really greater than the cost to just allowing the software fail, then maybe they should just let the software fail and prepare a great story for their users--I'd love to hear it.
kbar13 9y ago
would simply refusing to recognize NEW symantec certificates issued after a certain date in the near future be a sufficient compromise? it won't affect institutions that have pre-existing certificates, which will eventually expire by themselves.
- hdhzy 9y ago
  It's not that simple as they can backdate the cert, like StartSSL/WoSign: > It turns out WoSign has repeatedly been lying to Mozilla about backdating SHA-1 SSL Certificates Source: https://www.riskiq.com/blog/labs/wosign-and-startcom-caught-red-handed/ https://www.riskiq.com/blog/labs/wosign-and-startcom-caught-... Certs could be checked via Certificate Transparency but currently this is not required for DV certs.
  - majewsky 9y ago
    But isn't EV certs where the money is?
MichaelGG 9y ago
Again, how is this anyone else's problem? It'd be rewarding bad behaviour and poor technical solutions. These companies will find a way to workaround it. A suitable compromise could be an override switch that can only be activated via Group Policy. That'd at least be a reasonable suggestion from Symantec. Not their current offer of nothing. As far as "updating" my point was that they described a routine mobile app update as "recoding" as if it'd be lots of actual code to rewrite. And again, the fact a large company has no way to easily update in face of a security problem really is their problem, not ours.
pas 9y ago
> These companies have done nothing wrong, Sometimes doing nothing is the wrong thing. They did wrong by supporting Symantec (or whatever shitty CA they originally did business with that Symantec acquired) with their money. Or if initially they did not know about how shitty Symantec is, now they ought to know, and yes, it's a business risk (counterparty/vendor risk basically).
dragonwriter 9y ago
> 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." Those are precisely equivalent. > Again, remember that the person being punished here is not Symantec; Yes, it is, though you make exactly the standard "too big to fail" argument. yes, customers who relied on the misbehaving CA will also incur some costs, but if misbehaving CAs don't see reduced or eliminated trust at the level of browsers and similar trust stores, the entire ecosystem -- including the good actors and their customers -- pays the price as end-user trust in the ecosystem weakens because certificates do not guarantee what they are supposed to. And if any actor is recognized as too big to fail, that creates an unlimited license for bad behavior on the part of that actor at the price of the whole ecosystem.

fosco 9y ago

>) 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 has already led to better decisions regarding security.

mdip 9y ago
> 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.

tptacek 9y ago

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.

mentat 9y ago
The "survey" that accompanied the original customer facing message was so biased as to be ridiculous. Like "Will Google's proposed change be disruptive, massively disruptive, or business ending for you?"

Aaron1011 9y ago

> 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 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).

bayfury 9y ago

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.

kevinburke 9y ago

They've been playing the same game for literally 10 years https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089 https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...

fredsanford 9y ago

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.

ryandrake 9y ago

Unless your software is running on a 30 year old embedded system, located in a submarine, 5KM below the ocean, guarded by tigers, and stuck there for the next decade, it's hard to muster sympathy about how hard updating your software is. If the cost to a company to deploy an update their software is really greater than the cost to just allowing the software fail, then maybe they should just let the software fail and prepare a great story for their users--I'd love to hear it.

kbar13 9y ago

would simply refusing to recognize NEW symantec certificates issued after a certain date in the near future be a sufficient compromise? it won't affect institutions that have pre-existing certificates, which will eventually expire by themselves.

hdhzy 9y ago
It's not that simple as they can backdate the cert, like StartSSL/WoSign: > It turns out WoSign has repeatedly been lying to Mozilla about backdating SHA-1 SSL Certificates Source: https://www.riskiq.com/blog/labs/wosign-and-startcom-caught-red-handed/ https://www.riskiq.com/blog/labs/wosign-and-startcom-caught-... Certs could be checked via Certificate Transparency but currently this is not required for DV certs.
- majewsky 9y ago
  But isn't EV certs where the money is?

MichaelGG 9y ago

Again, how is this anyone else's problem? It'd be rewarding bad behaviour and poor technical solutions. These companies will find a way to workaround it. A suitable compromise could be an override switch that can only be activated via Group Policy. That'd at least be a reasonable suggestion from Symantec. Not their current offer of nothing. As far as "updating" my point was that they described a routine mobile app update as "recoding" as if it'd be lots of actual code to rewrite. And again, the fact a large company has no way to easily update in face of a security problem really is their problem, not ours.

pas 9y ago

> These companies have done nothing wrong, Sometimes doing nothing is the wrong thing. They did wrong by supporting Symantec (or whatever shitty CA they originally did business with that Symantec acquired) with their money. Or if initially they did not know about how shitty Symantec is, now they ought to know, and yes, it's a business risk (counterparty/vendor risk basically).

dragonwriter 9y ago

> 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." Those are precisely equivalent. > Again, remember that the person being punished here is not Symantec; Yes, it is, though you make exactly the standard "too big to fail" argument. yes, customers who relied on the misbehaving CA will also incur some costs, but if misbehaving CAs don't see reduced or eliminated trust at the level of browsers and similar trust stores, the entire ecosystem -- including the good actors and their customers -- pays the price as end-user trust in the ecosystem weakens because certificates do not guarantee what they are supposed to. And if any actor is recognized as too big to fail, that creates an unlimited license for bad behavior on the part of that actor at the price of the whole ecosystem.