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

Chrome's Plan to Distrust Symantec Certificates

security.googleblog.com

Post reply on HN
Print view View original

171–180 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#171

Post by iliketosleep »

hannob wrote: post #155
grandalf wrote: post #74

I wish browser vendors would let me choose a trusted entity and make it simple for me to trust only CAs that my trusted entity supports, or the intersection of what multiple trusted entities endorse. The incentive for a mass-market browser is to trust pretty much everything, but I'd prefer to use a browser that is a bit more paranoid. If a website can't load properly because I don't trust one or more of the CAs, I mi…

> I wish browser vendors would let me choose a trusted entity and make it simple for me to trust only CAs that my trusted entity supports, or the intersection of what multiple trusted entities endorse. This is an idea that I hear in variations from time to time, yet I think it's utterly wrong and goes against everything we know about IT security UI. The reason why HTTPS works at scale and is - with all its weaknesses…

The parent is not suggesting a deviation from the "it just works" model. They are suggesting a convenient way for expert or "paranoid" users to be able to make changes to whom they trust as they see fit - this does not affect average users at all, but may provide significant benefits to an important minority of users.

Re: Chrome's Plan to Distrust Symantec Certificates

#172

Post by infinity0 »

JoelJacobson wrote: post #100

SWIFT is the only single entity trusted by all banks in the world. I think they would be a perfect fit for a CA to issue online banking certificates, since there is no way to get around trusting SWIFT as a bank, so they might as well trust them for their certificates as well, instead of trusting Symantec or any other CA. The less entities you have to trust, the better.

That's really not good security logic. It's better to trust a very strong entity for 1/2 of your security and a weak entity for the other 1/2, so that when shit breaks you at least have a more accurate suspicions on which part of your system broke, to start the investigations from.

It's much worse to trust a single weak entity for 1/1 of your security.

That said, it's possible SWIFT can be a good CA. But you shouldn't choose them if they do a crap job of it, simply to "reduce the number of entities you trust".

Re: Chrome's Plan to Distrust Symantec Certificates

#173

Post by marbletiles »

mehrdadn wrote: post #169
hannob wrote: post #168

Earlier quoted context omitted.

Have you ever seen this picture? https://www.reddit.com/r/funny/comments/42xxdh/what_computer... Because that's exactly what you're proposing.

Not that particular one, though I have seen similar, but no, that is not what I was proposing. Where is the "technical crap" in what I just suggested? Which part of it was hard to understand or make a decision on?

Sorry, I know it was well-meaning, but it's riddled with "technical crap" and assumed knowledge which make it hard to decide upon. Not least a pretty foreign uses of "trust" and "certification" for non-technical people. E.g.:

1. "Certified by" — what does this mean? Is like a rating thing? A tripadvisor thing for the web?

2. "X" who are they? Do they want my money? Do I need a new one?

3. "Current trusted certifier" oh god, did I choose them? Are they bad now? Did I not pay them money? Has it been hacked? Didn't it do a review of BigWebsite yet maybe? I could just wait I guess.

4. There are three buttons that say "yes"! If I hit "always" what if it was wrong? And "if Google verifies" well that's obviously a scam because my web is Google so it would already know. This is all some kind of scam. I'm out of here.

Re: Chrome's Plan to Distrust Symantec Certificates

#175

Post by mehrdadn »

marbletiles wrote: post #173
mehrdadn wrote: post #169

Earlier quoted context omitted.

Not that particular one, though I have seen similar, but no, that is not what I was proposing. Where is the "technical crap" in what I just suggested? Which part of it was hard to understand or make a decision on?

Sorry, I know it was well-meaning, but it's riddled with "technical crap" and assumed knowledge which make it hard to decide upon. Not least a pretty foreign uses of "trust" and "certification" for non-technical people. E.g.: 1. "Certified by" — what does this mean? Is like a rating thing? A tripadvisor thing for the web? 2. "X" who are they? Do they want my money? Do I need a new one? 3. "Current trusted certifier"…

I edited it. Is this better?

I honestly don't see why the concept of "This site claims to be WorldBank.com, but we can't verify this. Whom do you trust enough to ask?" requires technical knowledge of any kind. People already understand this is why they have ID cards and background checks -- "I don't know if I can trust this guy; do you trust X to run a background check (or ask him to show an ID card issued by Y)?" is the same exact concept. Why do you think ordinary people fundamentally cannot understand this on the computer when they already understand it (and much more difficult things) just fine in real life?

Also, don't forget that none of this applies to when you choose the default settings. This is only if you choose to distrust some organizations.

Re: Chrome's Plan to Distrust Symantec Certificates

#176

Post by snowwrestler »

aseipp wrote: post #129
vacri wrote: post #116

Earlier quoted context omitted.

> The user should be the one controlling the list of trusted CAs and servers, not a third party such as ad-supported company or organization distributing a web browser. No, they really shouldn't. Security is a ridiculously complex arena, and the amount of knowledge you need to make an intelligent setup on this is considerable. For tech-heads, fine, but the vast majority of people are not tech-heads. If you switched o…

The funniest part of this ongoing debate I see -- to me, at least -- is that the end result is, effectively, one of two options. Given the way we as a society use technology, today: 1) Piss off the like, 10,000 technical nerds who care about this, by having sensible defaults. "We should really teach people to fully manage their CA chain! It sucks I have to spend 20 minutes doing this once a year after spending 10,000…

It seems to me that if someone is truly an expert, they should already be able to manually manage their certificate authorities if they want to. It's just a list stored somewhere on their computer, after all, and at least 2 major browsers are open source and can be forked into a private repo for personalized development.

What I see in this thread looks more like an insidious middle: people who think they are experts, but are asking browser providers to do the development to change the entire product and provide a nice friendly UI.

This seems like an area where the old maxim applies that if you have to ask for help, maybe you're not as expert as you think you are.

Re: Chrome's Plan to Distrust Symantec Certificates

#177

Post by snowwrestler »

dlubarov wrote: post #105
valarauca1 wrote: post #92

Earlier quoted context omitted.

This is a managed by your OS. You are free to delete CA's from its trust store. What Chrome is doing is irreguarless if that cert is in your OS's store it won't trust it. Keychain for OSX mmc in windows cmd prompt Linux has /usr/share/certificates

> This is a managed by your OS. It depends on the browser -- e.g. Chrome uses the system's CA certs, but Mozilla ships with its own.

Ok well the broader point still applies, right? You can edit Firefox's CA list if you want to.

Re: Chrome's Plan to Distrust Symantec Certificates

#178

Post by likelynew »

iliketosleep wrote: post #171
hannob wrote: post #155

Earlier quoted context omitted.

> I wish browser vendors would let me choose a trusted entity and make it simple for me to trust only CAs that my trusted entity supports, or the intersection of what multiple trusted entities endorse. This is an idea that I hear in variations from time to time, yet I think it's utterly wrong and goes against everything we know about IT security UI. The reason why HTTPS works at scale and is - with all its weaknesses…

The parent is not suggesting a deviation from the "it just works" model. They are suggesting a convenient way for expert or "paranoid" users to be able to make changes to whom they trust as they see fit - this does not affect average users at all, but may provide significant benefits to an important minority of users.

We can add or remove root certificates for OS, it's just deliberately not easy.

Re: Chrome's Plan to Distrust Symantec Certificates

#179

Post by vertex-four »

mehrdadn wrote: post #175
marbletiles wrote: post #173

Earlier quoted context omitted.

Sorry, I know it was well-meaning, but it's riddled with "technical crap" and assumed knowledge which make it hard to decide upon. Not least a pretty foreign uses of "trust" and "certification" for non-technical people. E.g.: 1. "Certified by" — what does this mean? Is like a rating thing? A tripadvisor thing for the web? 2. "X" who are they? Do they want my money? Do I need a new one? 3. "Current trusted certifier"…

I edited it. Is this better? I honestly don't see why the concept of "This site claims to be WorldBank.com, but we can't verify this. Whom do you trust enough to ask?" requires technical knowledge of any kind. People already understand this is why they have ID cards and background checks -- "I don't know if I can trust this guy; do you trust X to run a background check (or ask him to show an ID card issued by Y)?" is…

Most people, funnily enough, don't run background checks on other people, and don't have a well-formed mental model of why they're necessary and what the security risks in using them are.

Re: Chrome's Plan to Distrust Symantec Certificates

#180

Post by mehrdadn »

vertex-four wrote: post #179
mehrdadn wrote: post #175

Earlier quoted context omitted.

I edited it. Is this better? I honestly don't see why the concept of "This site claims to be WorldBank.com, but we can't verify this. Whom do you trust enough to ask?" requires technical knowledge of any kind. People already understand this is why they have ID cards and background checks -- "I don't know if I can trust this guy; do you trust X to run a background check (or ask him to show an ID card issued by Y)?" is…

Most people, funnily enough, don't run background checks on other people, and don't have a well-formed mental model of why they're necessary and what the security risks in using them are.

> Most people, funnily enough, don't run background checks on other people

They don't do it because they're not employers/landlords/etc. and hence the need never arises, not because they somehow have a complete lack of understanding of the concept.

> and don't have a well-formed mental model of why they're necessary and what the security risks in using them are

They understand why they need to keep their bank passwords safe, and hence they can understand that they shouldn't enter it on someone else's website. They understand what a fake ID or passport is, and they understand why they shouldn't give their ID numbers to random strangers.

The specific examples I used are not the point. I explicitly said they're not perfect; they're just there to get a bigger point across. Look at the larger point. The point is people are already dealing with much more complicated stuff on a daily basis. They understand the concept of lying. They understand that identity theft can wreak havoc on their lives. They understand how to prevent it. So they can handle the concept of what it means to enter their credentials on the wrong site. It's not technical and it's not complicated, and it's not necessary for them to understand how exactly doing the wrong thing might lead to an undesirable result.

If you'd like to convince me that the average person can't understand this concept, at least support your claim by providing a link to a study or something that isn't based on a cherry-picked strawman version of what I've suggested? Surely someone's already looked into this kind of an approach and what you're saying isn't just pure speculation?

Post reply on HN