7 ms·
Entrust Certificate Distrust
- jamesyates 2y ago[dead]
- PaulWard 2y ago[flagged]
- whitesammy 2y ago[dead]
- Tfoote01 2y agoI worked there. It doesn't surprise me at all!
- crazysim 2y agoSome popular users: chase.com aa.com
- dextercd 2y agoSome more: washingtonpost.com, cdc.gov, dell.com, jpl.nasa.gov, mastercard.com
- theandrewbailey 2y agoapi.cybersource.com This is gonna cause me some headaches, along with everyone else who processes payments through Cybersource, and possibly others :(
- qmarchi 2y agoCYBS Engineer here. We're already working on it. Keep an eye for merchant notifications if you use certificate pinning. Now, back to rotating certificates....
- crazysim 2y agoOut of curiosity, is your organization planning to switch to Let's Encrypt or just another year long certificate provider? It'll be interesting to see what, if any, organizations affected by this switch to: Stick with 1 YR certs or go to the future with free 90 days?
- mholt 2y ago[flagged]
- RulerOf 2y agoMaybe you (or anyone) could shed light on something for me? I'm sure leaf certificate pinning is very common among your customers. Assuming that pinning is a manual process where customers decide to implicitly trust a specific cert, what's the point of using a third party CA for those customers all? Does anybody self-sign or use a private CA on specific endpoints with longer certificate validity, and let the pinning customers use those?
- Plasmoid 2y agoWe have explicitly told customers not to pin our certificates and if they suffer downtime due to pinning it will not be considered a breach of our SLA. We have one customer who has demonstrated enough competence with certificates that we create a private ca endpoint and let them use that. The private root lasts around 5 years, and they pin to that.
- agwa 2y agoI'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?
- theandrewbailey 2y agoI 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.
- nahikoa 2y agoThe issues identified really show a dumpster fire: https://bugzilla.mozilla.org/buglist.cgi?o2=greaterthaneq&short_desc_type=casesubstring&o1=notequals&v1=Graveyard&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&classification=Graveyard&v2=2015-11-01&f1=classification&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc=Entrust&f2=creation_ts&component=CA%20Certificate%20Compliance&query_format=advanced&list_id=17064895 https://bugzilla.mozilla.org/buglist.cgi?o2=greaterthaneq&sh... Directly from Entrust: "Yes, there has been ongoing internal discussion and reflection on the issues found in this and other incidents, which has led to the action items described previously and ongoing changes, including the decision to revoke the certificates affected by this bug. Exceptional circumstances would need to be provided and justified by the Subscribers. Given the nature of the feedback we have received to date, we doubt that the community has any real interest in anything that Entrust could suggest, except to use against Entrust in a destructive, not constructive, way. We therefore would like more explicit and clear guidelines or a definition of “exceptional circumstances” to be adopted and applied equally to all CAs, perhaps through updates in the CA/B Forum requirements." https://bugzilla.mozilla.org/show_bug.cgi?id=1888714 https://bugzilla.mozilla.org/show_bug.cgi?id=1888714
- tg180 2y agoA honest translation from the corporate speak would be We’ve been endlessly talking about our repeated screw-ups, which led us to revoke the affected certificates. If subscribers want an exception, they need to come up with an extraordinary excuse. We don't care, so we demand clear and strict rules about what counts as “exceptional circumstances” that apply to all CAs, and these should be updated in the CA/B Forum requirements. We are big, who are you? ... it's not promising
- dextercd 2y agoI wonder if Entrust can survive this. Even if Web-PKI doesn't account for the majority of their income (which it might, I genuinely don't know) this is a huge blow to their credibility. And for a CA, credibility is everything
- kseifried 2y agoEntrust has BIMI certs which use a different root (CN = Entrust Verified Mark Root Certification Authority - VMCR1) and for which your choices of a BIMI certificate are: Entrust or Digicert. I doubt it makes as much money as their web certs (BIMI certs are not super common, and they are expensive to issue since there's an actual validation process that typically involves a public notary validating the ID of a corporate officer). If you believe https://bimiradar.com/glob https://bimiradar.com/glob it looks like Entrust is selling on the order of a few dozen certs a week to maybe upwards of 100-200. EDIT: I've asked Google if Gmail will be discontinuing support for Entrusts VMC certificate (and thus BIMI logos), I would guess not since BIMI has some actual requirements, but assumptions are not the best way to make decisions about risk (like our BIMI logo not working later this fall).
- Kwpolska 2y agoBIMI is a CA racket.
- intelVISA 2y agoThanks Google...
- ethbr1 2y agoEmail logo validation and prominent display seems like a perfectly valid use case. See arguments about red-warning unencrypted HTTP and how that pushed the web to update. Add in that genAI is going to make plausible-looking phishing emails a lot easier for the world to generate en mass, and giving the everyperson something better than "decide if it looks suspicious" is important.
- cedws 2y agoI wonder which root CA the intelligence agencies use to selectively MITM TLS traffic a la Crypto AG.
- aaomidi 2y agoCertificate transparency prevents this style of attack.
- schoen 2y agoAs long as the victims are checking it and know what to look for!
- Sateallia 2y agoChrom(e/ium) and Safari don't trust certificates that are not in public logs [0]. [0] https://en.wikipedia.org/wiki/Certificate_Transparency#Mandatory_certificate_transparency https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...
- schoen 2y agoRight, and that's a fundamental sea change in PKI security posture since the Iranian "ComodoHacker" and the Soghoian and Stamm compelled issuance paper! My point is just that some attackers might be willing to have their attacks show up in public logs if their victims are unlikely to ever notice that and if nobody else is likely to notice it either. With Let's Encrypt we made a lot of people's certificate management a "fire and forget" thing, which is exactly what we hoped to do, but if they completely forget about it, it may be that there will be lots of targets against whom nobody would notice certificate misissuance.
- aaomidi 2y agoThe other argument is, why bother MITMing when you can go to Cloudflare and get them to share the data with you :)
- noname120 2y agoThe real question is: why didn't they get booted out earlier?
- sieabahlpark 2y agoMy guess is Google wanted to really give them every opportunity so that most people come to your conclusion instead of "wow! Google is just trying to censor the internet"
- sybercecurity 2y agoProbably worried that it would break something for a significant number of customers, so they took a cautious approach. That's the problem with any Internet-wide change: you don't always know who will be impacted negatively or how severely. No one wants to make a quick change only to find out some critical system is now broken.
- rxu 2y agoCan someone ELI5 what the violations linked in the first line are? They seem pretty minor to me but I don't understand certs
- whizzter 2y agoSince contents of certificates contents sadly often diff there was a ballot to streamline the contents to lessen the burden on implementations to interpret the differences. Entrust missed/ignored the updates to how certificates were supposed to be formed and when caught declined to revoke the incorrectly issued ones (because it's probably a more or less manual process for many admins working in a pre-Let's Encrypt style of fashion) and they didn't want to inconvenience their customers and assumed that they themselves were the important party in the equation (CA's was that historically compared to site-admins). The certificate industry has always been quite ad-hoc with CA's being entitled middlemen, we have Let's Encrypt and almost ubiquitous encryption now because browser makers and other internet actors saw security as more important than protecting the CA's business and now that LE is established Google,etc aren't the slightest interested in pampering CAs if they aren't interested in cleaning up the system.
- plorkyeran 2y agoThey are very minor, but because the consequences of an mis-issued certificate can be so high, there’s an explicit policy that misissued certificates must be revoked and reissued promptly. The distrust was due to them refusing to comply with the policy and outright stating that they did not intend to comply in future incidents either.
- crote 2y agoCorrect, the violations are minor and should be trivial to deal with. The problem in this case is that Entrust displayed a complete disinterest into actually solving the underlying issues. Doing an oopsie is one thing. Doing an oopsie, lying about it, refusing to take precautions, and failing to take measures to prevent a repeat despite promising to do so? Completely different story. If they can't be trusted to respond properly to minor administrative issues, why should they be trusted to respond adequately during a real security incident?
- xeeeeeeeeeeenu 2y agoIt 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?
- skrebbel 2y agoI’m really impressed. CAs are 100% rent-seeking businesses and their position is solely derived from having convinced browser and OS vendors to put them in a list. You’d assume their top prio would be to stay in the list.
- crote 2y agoThey genuinely believe they are "too big to fail". They've got thousands of employees, they've been around for 30 years, they are a critical part of public infrastructure: surely something as trivial as a few weirdos in a mailing list couldn't instantly kill their entire business? Stuff like this happens when upper management has zero clue about the business they are in. They believe they are in the business of selling certificates, while in reality they are in the business of selling trust. They treat things like the CA/B Forum and the various Root Programs as more like an optional networking event than the combination of judge, jury, and executioner that it actually is - with a completely predictable outcome.
- hvenev 2y agoPerhaps they've decided to draw inspiration from https://bugzilla.mozilla.org/show_bug.cgi?id=647959 https://bugzilla.mozilla.org/show_bug.cgi?id=647959.
- syncsynchalt 2y agoThanks for this link, reading through it (and the bugs referenced in it) was a delight this afternoon.
- erikaww 2y ago
- kseifried 2y agoEntrust has BIMI certs which use a different root (CN = Entrust Verified Mark Root Certification Authority - VMCR1) and for which your choices of a BIMI certificate are: Entrust or Digicert. I doubt it makes as much money as their web certs (BIMI certs are not super common, and they are expensive to issue since there's an actual validation process that typically involves a public notary validating the ID of a corporate officer). If you believe https://bimiradar.com/glob https://bimiradar.com/glob it looks like Entrust is selling on the order of a few dozen certs a week to maybe upwards of 100-200. EDIT: I've asked Google if Gmail will be discontinuing support for Entrusts VMC certificate (and thus BIMI logos), I would guess not since BIMI has some actual requirements, but assumptions are not the best way to make decisions about risk (like our BIMI logo not working later this fall).
- Scaevolus 2y agoAren't BIMI certs an even sillier cash grab than EV certs?
- aaomidi 2y agoI’m one of the people who really went in depth with Entrust (Amir on Bugzilla). I’m also an author on https://webpki.substack.com https://webpki.substack.com. I will be writing my thoughts on the distrust soon. I can try to answer any questions folks may have. I can also help folks find ways they can also be involved! Root programs can only do so much and need surveillance of the CAs from the community.
- doctorpangloss 2y agoI am a layperson so I appreciate the attention on the matter. Regardless of how Entrust is operated, there appears to be significant complexity in CA program that the browsers operate. On the flip side, Let’s Encrypt is basically effortless for me to use, as an end user of an LE secured site and as a developer. Why misallocate all this toil on root CA compliance on the one hand, when LE could redirect that labor towards something valuable instead? What is so challenging about giving LE full leadership on this issue? Where does the proverbial political strength of Entrust and similar entities come from, in an ecosystem where there are functionally 5 cooperating, more or less transparent entities that decide the trust of certificates for 99% of end users? Why does anyone care about any of the CAs?
- glzone1 2y agoLE has to comply with the root CA standards too. For a variety of reasons there haven't been as many problems with LE - partly because they don't get paid by folks getting certs and issuing certs is a cost to them so their incentives are different. I don't get entrust here. It's not like they weren't told what to do.
- tialaramex 2y agoSimplicity is a shortcut to correctness. Let's Encrypt is a simple thing to implement. Relatively speaking of course. It would be tempting (unbearably so for a for-profit issuer) to have manual issuance, this means at least duplicating the effort as every system can also be manual and must have the appropriate checks in place for that. As an example of how wedded Let's Encrypt is to simplicity, part of routine application process is to show your certificates expire properly, often a CA would manually create a certificate which either was already expired (back dating it but arguably this is allowed for technical procedures) or had a very short lifetime and so would expire by the time the trust programme examines the demo cert. Let's Encrypt instead issued an ordinary 90 day certificate, using the same automatic process as their subscribers - and then just waited months for it to expire. Like a boss.
- mantra2 2y ago[flagged]
- MavisBacon 2y agoThis is a very difficult post not to reply to with a pun
- bpfrh 2y agoThere is a more detailed statement in the chrome CCADB Public group: https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM/m/-tvW5l-lAAAJ https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...
- mikeiz404 2y ago> This approach attempts to minimize disruption to existing subscribers using a recently announced Chrome feature to remove default trust based on the SCTs (signed certificate timestamps) in certificates. I was wondering how Chrome was able to revoke a certificate based on time without trusting the CA to not back date certificates and it looks like this is due to being able to trust certificate transparency logs instead. This is where they get the signed certificate timestamps (SCT) from. See also https://certificate.transparency.dev/howctworks/ https://certificate.transparency.dev/howctworks/
- olliej 2y agoThis kind of thing was one of the reasons CT was introduced :D
- agwa 2y agoCT was introduced to detect misissued certificates, but it was never intended to be used as a timestamping system like this. The point of the SCT timestamp was to start the clock on the deadline for the log to publish the certificate, not for use in trust decisions. So when Chrome announced they were using SCT timestamps for trust decisions, my first question[1] was whether anyone was auditing CT logs to detect backdated timestamps. Since then, I have added timestamp auditing to my monitor and should be able to detect a CT log backdating an SCT timestamp. [1] https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k/m/tvfZARR_AQAJ https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k...
- olliej 2y agoSorry I think my phrasing was not great. The goal of CT was not to make staged distrust of a CA possible (that's just a happy coincidence). It was to make it possible to detect CAs misissuing certificates, which includes CAs back dating certificates.
- tgsovlerkhgsel 2y agoEven before CT, policies generally trusted the CA to not backdate. Of course a CA could try that, but if caught, all certificates, including previous ones, would be treated as invalid, so it worked.
- zX41ZdbW 2y agoThe list of affected websites, just in case: https://pastila.nl/?000882d6/bed25fdc842914abbc89e528012a961c https://pastila.nl/?000882d6/bed25fdc842914abbc89e528012a961...
- zX41ZdbW 2y agoPotentially affected. No problem for now, per the linked blog post.
- justinclift 2y agoWow. 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.
- amluto 2y ago> Additionally, should a Chrome user or enterprise explicitly trust any of the above certificates on a platform and version of Chrome relying on the Chrome Root Store (e.g., explicit trust is conveyed through a Group Policy Object on Windows), the SCT-based constraints described above will be overridden and certificates will function as they do today. This continues to annoy me. Chrome (and other browsers) have detailed trust constraints, e.g. SCTNotAfter, in their own root stores. Why can’t administrators do the same thing?
- akoboldfrying 2y agoI don't understand what is annoying about this. Wouldn't it be more annoying for Chrome not to offer end users a way to override policy decisions they make in a Google office halfway across the world about what websites you can view on your own laptop?
- tsimionescu 2y agoI 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.
- amluto 2y agoExactly. 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.
- tardy_one 2y agoIMO 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.
- 1oooqooq 2y agoAll the google root security team's due diligence email are just a list of links to firefox's bugzilla who documented and followed up on all the issues. https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM/m/-tvW5l-lAAAJ https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...
- agwa 2y agoRepresentatives from the Chrome and Apple root programs participate in the Bugzilla discussions in an official capacity. But yes, there is significant help from the community in uncovering evidence and grilling CAs.
- tialaramex 2y agoIn practice the Web PKI is overseen by the general public, via Mozilla's m.d.s.policy. It makes no sense for the proprietary vendors, including Google, to insist on doing something themselves badly when Mozilla is the obvious host for this work. The older vendors are even less able to be properly open with their customers (let alone the general public) than Google. At Apple it's probably a firing offence to even confirm obvious decisions - it seemingly took months to get Apple's chosen representative to confirm that Apple's new 398 day rule was an issuance requirement, rather than just something where Apple wouldn't trust longer lived certs in Safari.
- 1oooqooq 2y agonone of what you list are good excuses for anything. I fail to see the point. Is it that marketing trumps technical know how and it should be ok?
- syncsynchalt 2y agoMozilla's bugzilla is the de-facto site for coordinating issues in CA/B. Any root program will refer to it for context on issues.
- dextercd 2y agoHas there been any public comment about this from Entrust yet?
- agwa 2y agoStatement from a spokesperson in the last paragraph of https://www.theregister.com/2024/06/28/google_axes_entrust_over_six/ https://www.theregister.com/2024/06/28/google_axes_entrust_o... It doesn't say much.
- Animats 2y ago"Entrust encrypts and secures more than 24 million Swift messages daily." Wonder how secure that is? That has real potential for extracting value.
- opless 2y agoEntrust 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.
- lambdaone 2y agoI'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.
- nucleardog 2y ago> There's now also the problem of competing with a free alternative that increasingly almost everyone knows about. If you read through some of the incidents in bugzilla, you get the strong impression that Entrust’s market is specifically the people for which something like LetsEncrypt isn’t currently a viable alternative (or at least a difficult one). In trying to justify not revoking misused certificates, one example they gave for a customer they were granting extended deadlines to was some organization that was contractually obligated to their customers to provide at least 90 days notice of any certificate updates. While the deliverable is essentially the same, I don’t think Entrust and LetsEncrypt have really been in competition.
- ranger_danger 2y agoI wonder what the chances are that some government has compromised one of the many "trusted" CA certs used by all browsers on earth?