Live data from Hacker News

Entrust Certificate Distrust

security.googleblog.com

81–90 of 118 posts

Re: Entrust Certificate Distrust

#81
post #20
post #17

Earlier quoted context omitted.

Certificate transparency prevents this style of attack.

As long as the victims are checking it and know what to look for!

Not only. Example: Chrome on Android did change some time ago so if CA is in System store (which means it got here from manufacturer or from user which does have root access) - such CA MUST use Certificate Transparency. This rule doesn't apply if CA is in User store (installable by regular user) - https://httptoolkit.com/blog/chrome-android-certificate-tran...

Another example: Yandex Browser ONLY trust Russian NUC certs if they are in public CT logs,not otherwise (https://habr.com/ru/companies/yandex/articles/667300/ - text is in Russian) (as far as I understood, NOT trusting this CA al all is not option for them or their users, and if user is using chrome/firefox and needs access to sites which use this CA - CA will be just be installed manually so Yandex's solution is more secure, thanks to CTs).

Re: Entrust Certificate Distrust

#82
post #20
post #17

Earlier quoted context omitted.

Certificate transparency prevents this style of attack.

As long as the victims are checking it and know what to look for!

Even still, it turns it much more into a gamble.

Intel people really don't want to get caught (and whatever CA they use really does not want to get caught), CT turns the attack into a gamble. Even if nobody is checking most sites, CT still creates a deterence factor. Not perfect, but a lot better than the previous status quo.

Re: Entrust Certificate Distrust

#83
post #76

Earlier quoted context omitted.

I think they're complaining that as an administrator, you only get a binary decision: trust all certificates signed by this CA, or trust none of the certificates signed by this CA. The Chrome devs can implement more fine-grained decisions, such as trust all certificates signed by this CA with SCT<October 2024, but they don't expose this type of control to admins.

Exactly. I’d also like to be able to trust a certificate for a limited set of domains. This would be extremely valuable for all kinds of use cases.

IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain.

It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their org provided device, but that org may MITM any trust chain for some administrative convenience.

The org itself could cross sign with name constraints if they opt to be good, but would probably end up filing a lot of bugs in various software that can't handle it and their being good is the kind of selfless act that rarely happens without a regulatory requirement to pay for consequences of doing a MITM of your employees on the Internet.

Re: Entrust Certificate Distrust

#84
I've always thought that company names like "Entrust" are hostages to fortune, daring the Fates to intervene. In this case the Fates are the browser vendors.

There's now also the problem of competing with a free alternative that increasingly almost everyone knows about.

Re: Entrust Certificate Distrust

#85
post #65

"Entrust encrypts and secures more than 24 million Swift messages daily." Wonder how secure that is? That has real potential for extracting value.

Entrust bought nCipher's product line from Thales in 2019.

nCipher make HSMs - a lot are used in banks to encrypt transactions on behalf of devices through APIs like PKCS11.

To answer your question "how secure that is?"; The answer is yes, secure.

Re: Entrust Certificate Distrust

#86

The list of affected websites, just in case: https://pastila.nl/?000882d6/bed25fdc842914abbc89e528012a961...

Wow. There's some fairly significant domains in that list.

"treasury.gov" and "uspto.gov" stand out (to me), let alone the lengthy list of banks and other gov places around the world.

Re: Entrust Certificate Distrust

#87
post #69
post #23

Earlier quoted context omitted.

Right up until the next contract renewal. "Not trustworthy enough to secure a basic website" isn't exactly a great look.

Untrusted by Google is what most laypeople will get out of it.

Google is still equivalent to the Web for a lot of laypeople.

Re: Entrust Certificate Distrust

#88
post #49

Earlier quoted context omitted.

api.cybersource.com This is gonna cause me some headaches, along with everyone else who processes payments through Cybersource, and possibly others :(

I'm curious why that is. Is your API client using a root store that doesn't contain CAs other than Entrust, or pinning to an Entrust CA?

I work on a managed platform (Salesforce B2C Commerce Cloud). Accessing and verifying CAs isn't something that's regularly done, but at least it's editable from the web management UI.

Re: Entrust Certificate Distrust

#89

It always fascinates me when this happens. Don't the CAs understand that the browser vendors can and will kill their business if they don't comply with the rules? It's not like a fine that can be ignored. How dysfunctional does a company have to be to let this happen?

> How dysfunctional does a company have to be to let this happen?

Surprised no one pointed to the nature of the business as a source of this behavior.

In a non-innovative, compliance-based industry, you make money by cutting costs.

This affects the entire business, as you find managers who are effective at cutting costs and architects/engineers who will work for lower salary.

Multiply that over enough years, and we know where it leads...

Re: Entrust Certificate Distrust

#90
post #76

Earlier quoted context omitted.

Exactly. I’d also like to be able to trust a certificate for a limited set of domains. This would be extremely valuable for all kinds of use cases.

IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain. It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their…

The local admin means "the user's employer's IT department", which, for the sake of a work laptop, they implicitly trust way more than Mozilla/Microsoft/Google/Apple etc who managed the public root stores.
Post reply on HN