Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

111–120 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#111
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'

Similar, but the system architecture is different.

The CA system is composed of alow-moving companies like Symantec dependent on, or more specifically, beholden to fast-moving companies like Google.

In the mobile space, the situation is inverted. Android can move quickly, but they have little to no leverage over the slow-moving carriers.

Re: Symantec CA Response to Google Proposal and Community Feedback

#112
post #102
post #91

Earlier quoted context omitted.

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.

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-... Certs could be checked via Certificate Transparency but currently this is not required for DV certs.

But isn't EV certs where the money is?

Re: Symantec CA Response to Google Proposal and Community Feedback

#113
post #86
post #72

Earlier quoted context omitted.

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

You have to have planned for this (or be lucky) though. Some people just put their api on www.example.com; assuming you have clients in the field which have pinned BIG CA, and you've got HSTS preloaded (because you're forward thinking). Unless you can detect Chrome N+1 from your existing clients during the TLS handshake, you have to pick between browsers or existing clients. If Chrome ships this at the same time as r…

I know it's not going to help companies which pinned Symantec, but that's exactly why every serious guide to HPKP will have you pin two separate CAs.

Re: Symantec CA Response to Google Proposal and Community Feedback

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

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

Re: Symantec CA Response to Google Proposal and Community Feedback

#115
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'

Similar, but the system architecture is different. The CA system is composed of alow-moving companies like Symantec dependent on, or more specifically, beholden to fast-moving companies like Google. In the mobile space, the situation is inverted. Android can move quickly, but they have little to no leverage over the slow-moving carriers.

https://news.ycombinator.com/item?id=14208865

Re: Symantec CA Response to Google Proposal and Community Feedback

#116

Earlier quoted context omitted.

Easy, just apply the block to new devices -- the only thing the OEMs care about. They can easily write the contract to that effect.

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.

Re: Symantec CA Response to Google Proposal and Community Feedback

#117
post #30

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

>recoded, recompiled and redistributed. I suppose that's true for mobile apps with embedded certs. Bet there's an app store / play store approval logjam for Symantec customers that miss this news, and all come crashing in after the expiry.

Were Google really nice, they could scan their app store and notify the developers if their app contains embedded shitty certs.

Re: Symantec CA Response to Google Proposal and Community Feedback

#118
post #45
post #28

Earlier quoted context omitted.

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!

That's the problem, a lot of Big Corps thought Symantec is okay, because it's (was?) expensive as fuck and it has a nice long history! (So reputation. They're on NASDAQ, they must be okay!)

But that's just business as usual. You never know when your vendor goes rouge. And really Big Corps should have plans for these events.

Re: Symantec CA Response to Google Proposal and Community Feedback

#120
Read the statement carefully. Symantec still does not offer a verifiable audit trail like Google's Certificate Transparency requires. They just offer to have 3rd parties review the certificates sold to customers. Without a COMPLETE audit trail Symantec can still continue to secretly issue additional certificates not part of any audit trail. The whole announcement rather decreases my trust in Symantec even more.
Post reply on HN