Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Symantec CA Response to Google Proposal and Community Feedback

symantec.com

Post reply on HN
Print view View original

61–70 of 129 posts

Re: Symantec CA Response to Google Proposal and Community Feedback

#61

Post by viraptor »

ahmeni wrote: post #6
revelation wrote: post #3

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

Given some of the internal CA systems I've dealt within the past, I'd almost prefer a public CA in some cases. Sometimes your internal CA is just the group with manual access to the certificate provisioning and signing systems with either no API or some awful re-implemented API.

The are some very-not-enterprisey internal solutions. For example there's Anchor from the OpenStack project with a minimalistic approach (as long as you're cool with the idea of rotating certs daily)

Re: Symantec CA Response to Google Proposal and Community Feedback

#62

Post by mdip »

mjevans wrote: post #10
toomuchtodo wrote: post #7

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.

You're better off moving your accounts to a local credit union that does security correctly.

Have local credit unions gotten better at this? I left a local credit union a decade ago because they didn't offer online banking at all and when they finally did, the security practices they used were horrible. Memory may not serve perfectly here but I recall they had no EV cert (while common with banks, not everyone had them back then), the login form was provided in-the-clear POSTing to HTTPS and many of the banking functions were issued via GET requests, causing certain "internet accelerator extensions" that worked by requesting data before you clicked them to actually make changes to your accounts on certain pages (this is where memory doesn't serve -- I think it was a "theoretical" problem because these extensions usually didn't pre-request HTTPS pages for this very reason).

Re: Symantec CA Response to Google Proposal and Community Feedback

#63

Post by geofft »

mdip wrote: post #47
geofft wrote: post #25

> These customers include many of the largest financial services, critical infrastructure, retail and healthcare organizations in the world, as well as many government agencies. 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…

> 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 Symantec to behave. The largest certificate customers in the world have all voluntarily made it infeasible to choose a Symantec competitor, so as long as Symantec has any product at all of any quality, the market will keep buying Symantec.

If what Symantec is saying is true, the mere fact that they went to their largest customers and said "Suppose you had to buy certs from one of our competitors, what would you do" and they replied "We've never thought about that before" is itself a major victory.

Re: Symantec CA Response to Google Proposal and Community Feedback

#64

Post by kevinburke »

eykanal wrote: post #38
MichaelGG wrote: post #4

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

They've been playing the same game for literally 10 years

https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...

Re: Symantec CA Response to Google Proposal and Community Feedback

#65

Post by eropple »

5ilv3r wrote: post #55
AceJohnny2 wrote: post #37

Earlier quoted context omitted.

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.

It really, really doesn't matter if a Hacker News poster "sees through it". It matters that the rest of the world cares.

Technically-correct well-actuallys lose to real-world perception ninety-nine percent of the time.

Re: Symantec CA Response to Google Proposal and Community Feedback

#66

Post by viraptor »

revelation wrote: post #58
viraptor wrote: post #46

Earlier quoted context omitted.

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.

The topic was internal CAs. Those have completely different requirements and possibilities than public ones. The authentication will look completely different as well. You just can't compare those issues.

And you're missing the point I raised as well - if you have hosts coming up automatically, you either need automatic certificates, or shared keys. As long as you rely on SSL, there's no other way to go.

(For example of authentication: public CA verifies your domain, internal CA can ask the hypervisor to verify a token on your instance - not remotely in the same class)

Re: Symantec CA Response to Google Proposal and Community Feedback

#67

Post by tyingq »

Spooky23 wrote: post #12
revelation wrote: post #8

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.

Seriously. The fancy CA systems are wacky expensive.

I know several companies are using Amazon's ACM and public domains that resolve to internal ip addresses. It's not 100% automated, as it requires a validation email, but better than most homegrown stuff.

Re: Symantec CA Response to Google Proposal and Community Feedback

#68

Post by lsh123 »

CA infrastructure business is built on trust. Symantec lost the trust and got thrown out by Chrome. I hope that as the result Symantec will lose significant amount of CA business thus making a show case for other CAs to demonstrate that good processes and trust are key for staying in this business.

Re: Symantec CA Response to Google Proposal and Community Feedback

#69

Post by will_hughes »

revelation wrote: post #3

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 supported CAs. (e: Also, don't forget the tons of 'smart' phones out there running ancient versions of whatever)

If you're someone who supports applications that run on those, then your choices for what CAs you offer on your API/Media/etc endpoints is extremely limited. Some of these decisions were made more than a decade ago, and migrating off those is going to take another decade (i.e as old hardware dies).

Re: Symantec CA Response to Google Proposal and Community Feedback

#70

Post by Spooky23 »

revelation wrote: post #48
Spooky23 wrote: post #12

Earlier quoted context omitted.

Seriously. The fancy CA systems are wacky expensive.

I'm sure people make plenty of money wrapping OpenSSL in ever more elaborate Enterprise schemes. But if the net effect is that one bug in a frontend can cause the server to tell the cert server to tell the secure enclave to tell the wire mesh protected crypto coprocessor to sign a bogus certificate then what are we really doing here.

They sure do! We have an offline root on an HSM for various reasons.

We looked at various systems to manage intermediate ca issuance and reminders for renewal and the cost was incredible... most were >$200k!

Using scripts to automatically generate certificates and using the ugly but effective Windows CA web interface for "vanity" stuff does 90% of what those solutions do. I think we had an intern write a monitoring plugin to open tickets for soon to expire certificates and a few other things that covered the remaining 10%.

Post reply on HN