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

191–200 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#191

Post by grandalf »

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…

> crypto success story

Suppose 5% of CAs are compromised. Is that a success? It is if you compare it to everyone using self-signed certs, but it is not if you consider that there are likely broad vulnerabilities that can be silently exploited by some groups/nations.

We don't hear much about man in the middle attacks because we have no reason to be aware of them.

> it just works

The point of my remark is not to suggest that a list of trusted CAs compiled by someone like Bruce Schneier would result in a broken web. If it would, then it's hard to argue that the system is not already broken.

The point is to allow experts to establish authority on the basis of careful (possibly paranoid) stewardship of a list of trusted CAs. Then when an attack is revealed experts who whitelisted that CA lose a bit of credibility, and those who blacklisted it gain some.

As it stands, firms that ship a default list of trusted CAs have an incentive to err on the side of whitelisting, and then claiming "oops we had no idea that CA x was compromised..."

There are clues about the relative trustworthiness of CAs, some of which are simply the governments that have jurisdiction to demand private keys, etc.

Re: Chrome's Plan to Distrust Symantec Certificates

#192

Post by walshemj »

driverdan wrote: post #59
antihero wrote: post #52

What are some trustable providers of EV certificates? LetsEncrypt is wonderful, but if I'm a company that needs to show the company name next to the padlock, who should I be using? What's an easy way to check if a provider (for instance Gandi, who I use for my domains) is going to be culled by this? In fact, I don't even seem to able to find certificate information in Chrome any more - clicking on the padlock just gi…

> I'm a company that needs to show the company name next to the padlock Does anyone actually look at or care about that?

if I am logging onto a bank or my broker Abso-fragging-lutely, damn it :-)

Re: Chrome's Plan to Distrust Symantec Certificates

#193

Post by walshemj »

reificator wrote: post #68
driverdan wrote: post #59

Earlier quoted context omitted.

> I'm a company that needs to show the company name next to the padlock Does anyone actually look at or care about that?

Marketing often cares about that a lot. Users seem to notice but often times there's confusion as to why the address bar is, for lack of a better term, stuttering. And god help you if your certificate uses a name you don't have any branding for.

Exactly for example the fiasco of behringer whose site is get this "www.music-group.com".

It always seem to be German firms that don't just get the internet at all

Re: Chrome's Plan to Distrust Symantec Certificates

#194

Post by e12e »

pebers wrote: post #161
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.

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

To a certain extent the alternative here is to put all your eggs in all the baskets - if an elephant steps on any one of the baskets the eggs (your security) breaks...

Re: Chrome's Plan to Distrust Symantec Certificates

#195

Post by dllthomas »

cortesoft wrote: post #25
cperciva wrote: post #20

Earlier quoted context omitted.

But "distrust" doesn't convey the full meaning. They're not talking about merely not trusting Symantec certificates; they're talking about removing existing trust in the certificates.

Isn't 'removing existing trust' the same as 'distrust'? The word 'distrust' in no way implies that you have NEVER trusted them.

"Distrust" doesn't imply that you have never trusted them, but it does allow for you never having trusted them, and so communicates less.

Re: Chrome's Plan to Distrust Symantec Certificates

#196

Post by Twirrim »

nailer wrote: post #107
Twirrim wrote: post #93

Earlier quoted context omitted.

>Does anyone actually look at or care about that? No. You'll note that Amazon doesn't. They spent a bunch of time trying to figure out if it made a difference for customers. It turns out it doesn't, so they don't bother with the extra expense.

Apple does, as a counterpoint. I'm interested in the Amazon study if you have a link, I haven't seen that before. (Note, I run CertSimple and we specialise in making the verification process for EV faster and much less painful, so I'm biased)

I don't have any link... but off the top of my head they found that such a tiny percentage of people actually noticed the EV, even amongst technical people, that the value added was negligible. Even those that notice the EV certificate indicated that it didn't change their decision to purchase from a site.

You can make the EV process as smooth and simple as you like, but unless there's good solid business value provided by it (in $$s terms), you've got way more of an uphill struggle ahead.

Re: Chrome's Plan to Distrust Symantec Certificates

#197

Post by MertsA »

rallison wrote: post #95
gscott wrote: post #79

Comodo is giving away free Certificates to Symantec customers https://www.comodo.com/Google-Chrome-announces-proposal-to-d...

For those considering Comodo, I'd ask that you reconsider. They tried to trademark LetsEncrypt: https://news.ycombinator.com/item?id=11964583 https://news.ycombinator.com/item?id=11973232 Bad OCR led to certificates being issued to the wrong people: https://news.ycombinator.com/item?id=12761248 They created their own Superfish-like adware: https://news.ycombinator.com/item?id=9091917

Don't forget Chromodo which was a reskin of Chrome with --disable-web-security set. Because that totally makes their browser super secure!

Re: Chrome's Plan to Distrust Symantec Certificates

#198

Post by tony101 »

duskwuff wrote: post #136
tony101 wrote: post #91

Earlier quoted context omitted.

We need an 'Expect-EV' header, just like 'Expect-CT'. Or maybe all websites that request certain info (like SSN or credit card) should be required to have EV. EV is more expensive and onerous but it has the potential to thwart phishing.

> We need an 'Expect-EV' header, just like 'Expect-CT'. What good would that header do? A phishing site (say, "paypaaaaal.com") would simply not set it. > Or maybe all websites that request certain info (like SSN or credit card) should be required to have EV. EV certificates are not available to everyone. In particular, they're only available to users in certain countries, and even then only to registered businesses.…

> What good would that header do?

It would protect against MitM attacks where the attacker has fraudulently obtained a non-EV certificate, such as through CA compromise or a BGP attack, especially since EV certs are required to have CT log entries. I guess since Expect-CT already solves this, Expect-EV may not be that helpful.

>EV certificates are not available to everyone.

I agree this is a problem. EV should be available to anyone anywhere willing and able to prove their legal identity, be it a person or an organization. Then if someone uses EV to phish, they can be held accountable.

>how do you enforce a requirement like that

If this becomes standard, then we can train users to expect EV indicators when asked for payment data. Any site asking for it without EV would automatically become out-of-the-norm.

Re: Chrome's Plan to Distrust Symantec Certificates

#199

Post by Drdrdrq »

kccqzy wrote: post #96

> This plan, arrived at after significant debate on the blink-dev forum, would allow reasonable time for a transition to new, independently-operated Managed Partner Infrastructure while Symantec modernizes and redesigns its infrastructure to adhere to industry standards. It's funny they still mention giving Symantec an opportunity to modernize and redesign its infrastructure when Symantec simply decides to give up: h…

Wise actually. This way nobody can say that they were being unfair to Symantec, and it costs them nothing. They can still decide either way.

Re: Chrome's Plan to Distrust Symantec Certificates

#200

Post by dotancohen »

j_s wrote: post #187
dotancohen wrote: post #148

Earlier quoted context omitted.

And how would one know which certs to include? Seriously, I've been trying to solve that issue for years. Discussion on Super User (Stack Exchange): https://superuser.com/questions/818065/how-to-know-which-cer...

Does SSLKEYLOGFILE include the server certs or only the session? Apparently, "Chrome stores SSL certificate state per host in browser history" if you can figure out how to access that. https://serverfault.com/questions/279984 In any case: scan the hosts in your web history, and follow the cert chains to the various roots. Not sure if you're asking how or if you're asking whethor or not someone has already implemented…

> scan the hosts in your web history

That's simple SQL query against the Firefox profile sqlite database. No problem.

> and follow the cert chains to the various roots.

Doesn't scale. If it can't be scripted, then it can't be done for tens of sites that I regularly visit, and hundreds more that I come across.

Post reply on HN