Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

121–129 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#121
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."

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.

Re: Symantec CA Response to Google Proposal and Community Feedback

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

> If you think Let's Encrypt is an acceptable solution for all the affected organizations,

I think the world is changing in ways which may cause the affected organizations to reconsider what they consider an acceptable CA solution.

Re: Symantec CA Response to Google Proposal and Community Feedback

#123

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…

If you control the client and you control the servers it needs to communicate with, then you should probably not be using the public CA system.

Well yes if your "embedded" device has a user-facing webbrowser you will need the public CA system, but then I'd wager if you shipped such a device and don't have ongoing updates you have much much bigger problems than an outdated set of root CAs.

But there is zero reason for your mobile app communicating exclusively with your API endpoint to use the public CA system. You're paying for a less secure system with all the same hassles.

Re: Symantec CA Response to Google Proposal and Community Feedback

#125
post #77

Earlier quoted context omitted.

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

Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am" So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.

That certificate can be signed by whatever CAs you wish to use, including Symantec and others.

Re: Symantec CA Response to Google Proposal and Community Feedback

#126
post #99
post #56

Earlier quoted context omitted.

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…

As it happens, your hypothetical situation was exactly what did transpire: Samsung wanted to remotely deactivate the phones, but Verizon refused on those grounds. http://bgr.com/2016/12/09/galaxy-note-7-recall-verizon-samsu...

... and here I thought comparing security to burning genitals might have been too much of a farce, but that takes the cake, there. :o)

Re: Symantec CA Response to Google Proposal and Community Feedback

#127

Earlier quoted context omitted.

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.

The networks have to sign off too, or the phones won't get the OTA updates or be allowed to connect to the network.

The SoC / OEMs also have to sign off because they are the ones with access to the driver source code which needs to be updated and recompiled against a new release.

If Google plays hardball, these parties can always threaten Google with "We're leaving the OHA; we will be going with Amazon's Android fork and bundle Kindle and Prime apps." I'm sure Bezos will throw in Amazon Maps for free.

Re: Symantec CA Response to Google Proposal and Community Feedback

#128
post #116

Earlier quoted context omitted.

In the case of the carrier preventing the transmission of patches or OS upgrades you would be punishing the OEM for a problem created by the carrier and out of the control of the OEM. Tangentially, If I was a carrier I would use this to my advantage when negotiating. If you thought carriers were bad now, just wait until they have the power to withhold Google Play services and apps to an OEM's future phones.

Google could selectively disable play services with a very scary warning. Simply, if you are on a very old version of Android, display an alert that tells the end user to complain at the carrier.

Carriers would just get more money: "Your phone is too old for Google. Here's a link to our special offers for new phones that play nice with Google"

Re: Symantec CA Response to Google Proposal and Community Feedback

#129

Earlier quoted context omitted.

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

Could you give me some info about different banks' security practices?
Post reply on HN