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

181–190 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#181

Post by kuschku »

dested wrote: post #133
Joeri wrote: post #42

Earlier quoted context omitted.

Norton protect quietly reinstalled itself after I ran that tool. Oracle snuck it onto my system in a java update and I ended up having to dig through the registry and disk to weed it out. It is malware, plain and simple.

What could the lifetime value of a Norton customer be that they went to such incredible lengths to aquire?

Quite a lot, and it’s not just Norton. Google does the same, and pays companies to secretly include Chrome in their installers and auto-updaters, like they included the Google Toolbars before.

Here’s an interview with the VLC developers, where the VLC developers complain how Google tried to get them to secretly install Chrome with it, and offered enormous amounts of money, but they obviously said no: https://www.youtube.com/watch?v=jWx1P93nS0c&t=48s

Re: Chrome's Plan to Distrust Symantec Certificates

#182

Post by nailer »

darklajid wrote: post #150
nailer wrote: post #119

Earlier quoted context omitted.

Yep, what @detaro said. Here's the specifics: https://certsimple.com/blog/wildcard-ev-certificate

Like the site, but the example seems off. It talks about 'bankofamerica.com.fraud.ru' in the first paragraph, but then discusses how 'fraud.ph' (why did we change TLDs? This should stick to ru or the above should be changed to ph) gets a wildcard cert for '* .com.fraud.com' (we changed TLDs again, to com this time. I assume we're talking about 'fraud.ph' getting a cert for * .com.fraud.ph - or .. we stick with ru)

Good point - I was experiencing a bunch of fraud from the Phillippines and thought the Russian example was too cliched. I'll tweak the example to be more consistent.

Re: Chrome's Plan to Distrust Symantec Certificates

#183

Post by icebraining »

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

Earlier quoted context omitted.

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

The issue is not whether they are capable of understanding it, it's that they don't currently, and browsers have to be designed with that fact in mind. Showing them a message like you suggested only works if they already understood it.

Re: Chrome's Plan to Distrust Symantec Certificates

#184

Post by kuschku »

cbhl wrote: post #51
JoeMalt wrote: post #22

Earlier quoted context omitted.

Wow, I never realised VeriSign was a Symantec brand. I'm not sure what it says that Google doesn't trust the company that operates the registry for .com

Operating a domain registry and issuing EV certificates require different levels of trust. Don't read too much into Alphabet/Google using other gTLDs instead of .com, like https://abc.xyz or https://blog.google -- that's separate work done by separate people on a separate team.

From my own experience with TLDs, .com, .info, etc are the worst to deal with. It’s insane how wrong they get the TRANSFER process, and everything.

On the other hand, I’m positively surprised by how well DENIC (.de) handles it all.

Re: Chrome's Plan to Distrust Symantec Certificates

#185

Post by bryanrasmussen »

likelynew wrote: post #178
iliketosleep wrote: post #171

Earlier quoted context omitted.

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.

the implication being that if you don't find it easy enough to do it, then you probably aren't expert enough that you should be doing it.

Re: Chrome's Plan to Distrust Symantec Certificates

#186

Post by mehrdadn »

icebraining wrote: post #183
mehrdadn wrote: post #180

Earlier quoted context omitted.

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

The issue is not whether they are capable of understanding it, it's that they don't currently, and browsers have to be designed with that fact in mind. Showing them a message like you suggested only works if they already understood it.

> The issue is not whether they are capable of understanding it, it's that they don't currently, and browsers have to be designed with that fact in mind. Showing them a message like you suggested only works if they already understood it.

But I'm only saying the current UX could become much better, not that they have to switch to my suggested UI by tomorrow. Of course spending some time on user education and transitioning gradually would be a great idea. I was never against that; I'm all for it. So why implicitly rule this out as an impossibility?

Re: Chrome's Plan to Distrust Symantec Certificates

#187

Post by j_s »

dotancohen wrote: post #148
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.…

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 something like this that is easy to use.

Re: Chrome's Plan to Distrust Symantec Certificates

#188

Post by vertex-four »

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

Earlier quoted context omitted.

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

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

Not in my experience - people reuse passwords regularly, and are exceptionally vulnerable to phishing scams, as you should ask anybody working in corporate IT. This is why people actually working in security are very excited about U2F - a U2F-generated token is tied to a specific domain, so password reuse and phishing are both no longer as serious a problem, since a login to scammer.com no longer works as a login to mybank.com.

On top of that, people give their bank passwords to e.g. mint.com on a regular basis, when it's specifically asking for their bank password and they have no reason to trust that website.

> they understand why they shouldn't give their ID numbers to random strangers

Also not in my experience, and the basis of many scams.

People at large are terrible at security. We've been moving towards "automatic security" for a while for a reason. And that's before you get to the phenomena where critical thinking goes out the window as soon as something is on a computer instead of "in real life".

> Surely someone's already looked into this kind of an approach and what you're saying isn't just pure speculation?

Moxie Marlinspike's Convergence would be the closest thing, iirc. Whenever you access example.com, you ask a handful of user-selected notary servers to access example.com and tell you its TLS cert. If all of them match, you're not being MITMed. You don't have to trust any individual notary server, because it's all of them put together that provide the trust.

Of course, trying to figure out a good UX for "my Government and Google say it's fine, but Estonia and Facebook say it's not" in such a way that users aren't going to be severely inconvenienced by a malfunctioning/MITMed notary server but also aren't going to click on "I have no idea what this is just let me see the website" on a MITMed page is hard - probably impossible. Moxie has since given up on it.

Re: Chrome's Plan to Distrust Symantec Certificates

#189

Post by bugmen0t »

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…

I agree with Hanno here. There are great tools to make the CAs behave or at least make their mistakes being easily spotted: Name Constraints, DNS CAA records, Certificate Transparency and, if you must, HPKP and much more.

Re: Chrome's Plan to Distrust Symantec Certificates

#190

Post by chaz6 »

likelynew wrote: post #178
iliketosleep wrote: post #171

Earlier quoted context omitted.

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.

This makes me think that the package containing the trusted certificate list ought to be separated into a standalone repository, so that it is easy to change (like how you subscribe to an adblock list).
Post reply on HN