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

161–170 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#161

Post by pebers »

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.

Aka. putting all your eggs in one basket...

Banks shouldn't be relying on outdated infrastructure providers to do things they aren't good at. The sensible thing (and indeed more or less what happens now) is for banks to choose a best-of-breed CA to issue SSL certs, the same way any other company offering sensitive services over the Internet would do it.

Re: Chrome's Plan to Distrust Symantec Certificates

#162

Post by dpacmittal »

Dylan16807 wrote: post #144
dpacmittal wrote: post #141

Slightly offtopic but still related to web-security in general; how can I be sure about chrome extensions that I'm using are not doing malicious stuff? I think if a state actor or a resourceful entity wishes to steal data of users, attacking/hijacking/buying a popular chrome extension would be so much easier than attacking a CA or doing MITM over SSL, and trying to decrypt it. I've always hated the concept of certain…

For web pages to indicate? No, that'll get attached to every terrible ad in the world.

Yes, that would actually do more harm than good, but no reason to not provide a setting where user can add to the list of URLs similar to what chrome is already doing for flash, notifications, location, camera etc

Re: Chrome's Plan to Distrust Symantec Certificates

#163

Post by _pmf_ »

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 don't understand the reasoning behind not being allowed to deactivate/deinstall the standard trusted root certificates.

Re: Chrome's Plan to Distrust Symantec Certificates

#164

Post by icebraining »

mehrdadn wrote: post #159
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…

Not really. To be honest, the existing UX for trust relationships is hardly near optimal. Nobody needs to understand what CAs and PKIs are. I actually think the proper UI could make it pretty smooth and understandable by the layperson. All a user needs to be asked is "Whom would you trust to certify that the websites you visit are genuinely those they claim to be?" and be presented with a few reasonable options, such…

I think that implies there's a choice, that when you access, say, ycombinator.com, you can choose to have that site certified by one or many agencies. In reality that choice only exists for the site owner, so if you choose a subset of CAs, you'll just have HTTPS errors on a bunch of sites.

If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really.

[1] https://en.wikipedia.org/wiki/Convergence_(SSL)

Re: Chrome's Plan to Distrust Symantec Certificates

#165

Post by icebraining »

ota0004 wrote: post #146
feelin_googley wrote: post #97

Earlier quoted context omitted.

1. Uninstall the CA certficates the browser has pre-installed 2. Create and install own CA certificate 3. Download or create desired server certficates, sign them with own CA and install them I have not tried 1 but I regularly do 2 and 3. (Usually for monitoring outgoing encrypted traffic.) Anyway, the idea of your comment is spot on, I think. The process whereby users blindly trust browser authors has serious flaws.…

Browsers are primarily in the user fingerprinting business, but I would not be surprised that there is absolutely no incentive nor desire to invest in "security and privacy"(tm) other than to facilitate their main purpose. Let me stress this once again, the main purpose of a modern browser is to enable global, cross-network user tracking so that companies like google can collect data regardless of whether you "accept…

What's Apple's incentive for doing that?

Re: Chrome's Plan to Distrust Symantec Certificates

#166

Post by mehrdadn »

icebraining wrote: post #164
mehrdadn wrote: post #159

Earlier quoted context omitted.

Not really. To be honest, the existing UX for trust relationships is hardly near optimal. Nobody needs to understand what CAs and PKIs are. I actually think the proper UI could make it pretty smooth and understandable by the layperson. All a user needs to be asked is "Whom would you trust to certify that the websites you visit are genuinely those they claim to be?" and be presented with a few reasonable options, such…

I think that implies there's a choice, that when you access, say, ycombinator.com, you can choose to have that site certified by one or many agencies. In reality that choice only exists for the site owner, so if you choose a subset of CAs, you'll just have HTTPS errors on a bunch of sites. If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really. [1] https://en.wikipedia.or…

(Edit: I edited this example here to make it even simpler.)

Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that the certificate is what they expect (so that we know it's not a MITM), whose public key they have already hopefully known about and pinned.

Note: I just came up with these ideas on the spot. I believe they're much better than the current system but in no way am I suggesting they have no room for further improvement.

Re: Chrome's Plan to Distrust Symantec Certificates

#167

Post by eyeareque »

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…

Moxie proposed something like this in the past, quite forward thinking: https://en.m.wikipedia.org/wiki/Convergence_(SSL)

Re: Chrome's Plan to Distrust Symantec Certificates

#168

Post by hannob »

mehrdadn wrote: post #166
icebraining wrote: post #164

Earlier quoted context omitted.

I think that implies there's a choice, that when you access, say, ycombinator.com, you can choose to have that site certified by one or many agencies. In reality that choice only exists for the site owner, so if you choose a subset of CAs, you'll just have HTTPS errors on a bunch of sites. If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really. [1] https://en.wikipedia.or…

(Edit: I edited this example here to make it even simpler.) Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that th…

Have you ever seen this picture? https://www.reddit.com/r/funny/comments/42xxdh/what_computer...

Because that's exactly what you're proposing.

Re: Chrome's Plan to Distrust Symantec Certificates

#169

Post by mehrdadn »

hannob wrote: post #168
mehrdadn wrote: post #166

Earlier quoted context omitted.

(Edit: I edited this example here to make it even simpler.) Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that th…

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?

Re: Chrome's Plan to Distrust Symantec Certificates

#170

Post by chris_wot »

mtgx wrote: post #26

I want to thank the Chrome people that continued to investigate the initial issues with Symantec certificates rather than just take their word for it that it was a honest one-time mistake. I imagine there has been a lot of tension between Google and Symantec over the past year because of this, so it must not have been easy to keep poking at Symantec. After all, Symantec almost was one of the "too big too fail" CAs. A…

Not just the Google Chrome guys, but also the Mozilla team who were also investigating a variety of issues.
Post reply on HN