Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Entrust Certificate Distrust

security.googleblog.com

Post reply on HN
Print view View original

41–50 of 118 posts

Re: Entrust Certificate Distrust

#41

Post by olliej »

rxu wrote: post #9

Can someone ELI5 what the violations linked in the first line are? They seem pretty minor to me but I don't understand certs

There are some issues that are bad, but most of these issues with the _certificates_ are minor.

The problem is that to be a CA in the root stores you agree to (and entrust voted in support of) a pile of rules, and entrust demonstrated a complete disinterest in complying with those rules.

The reason for removing trust is not the severity of the original errors, it's the the severity of errors in the response.

1. The BRs requires revocation of invalid certificates with 5 days unless there is an exceptional reason not to. Entrust did not.

2. In the event a CA discovers that they are mis-issuing certificates they are required to stop issuing until they have resolved the error. In this case not only did entrust not do this, but they explicitly stated - after the issues were raised, and they were already told they were failing to revoke certs in the required time frame - that they were intentionally continuing to mis-issue

3. They repeatedly made errors in the past, promised to correct them, and then kept making the same errors

4. They made claims they were trying to get customers to prepare for revocation in the require 5 day window, but then it turned out they were telling customers that they had 30+ days (which was only discovered when one of the relevant customers forwarded info to someone else)

5. When a CA discovers miss issuance they are required to file an incident report, and provide detailed information about how it occurred, why it was not caught, what remediating steps are being taken, and what mechanisms are being introduced to ensure a similar failure cannot occur in future. None of Entrust's responses came close to this, until the chrome root store rep came in to say "this is unacceptable", and even then their "improved" reports were incomplete and lacked sufficient detail.

6. Once they were finally doing the basic steps they were meant to have done the moment they learned of the miss-issuance they repeatedly failed to produce an accurate set of the impacted certificates (as in the provided a list and people outside of Entrust were able to immediately turn around and say "but these certs are also broken, why aren't you listing those details")

and so on and so forth.

Google's post to CCADB provides more details than the blog post: https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...

Re: Entrust Certificate Distrust

#42

Post by darkhorn »

xeeeeeeeeeeenu wrote: post #10

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?

Software developers say that we have issues in the software that needs to be fixed or updated. Managment, who has never seen one line of code in their life says "no, make new features". And then the software starts to fall.

Re: Entrust Certificate Distrust

#43

Post by Sateallia »

schoen wrote: post #31
Sateallia wrote: post #21

Earlier quoted context omitted.

Chrom(e/ium) and Safari don't trust certificates that are not in public logs [0]. [0] https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...

Right, 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…

I got every self-hosting sysadmin I know to run certificate monitors for sites they maintain but it certainly isn't a common thing to do. I know Cloudflare has a beta certificate monitoring feature which would certainly help a lot with this problem considering their market share if they enable it by default. (Although one problem with this is that they issue backup certificates from other CAs so it'd easily trigger warning fatigue!)

(I wasn't aware of your credentials when I made my previous comment so I assumed you didn't know about mandatory certificate transparency which is a mistake on my part, sorry! I'll make sure to check profile about sections before I assume again.)

Re: Entrust Certificate Distrust

#44

Post by schoen »

Sateallia wrote: post #43
schoen wrote: post #31

Earlier quoted context omitted.

Right, 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…

I got every self-hosting sysadmin I know to run certificate monitors for sites they maintain but it certainly isn't a common thing to do. I know Cloudflare has a beta certificate monitoring feature which would certainly help a lot with this problem considering their market share if they enable it by default. (Although one problem with this is that they issue backup certificates from other CAs so it'd easily trigger w…

Yeah, I think it's tricky to know how most sysadmins could make good decisions about this information, especially when misissuance is likely to be less than 1% of 1% of all CA issuance and automated renewal is working properly. Warning fatigue is a pretty big deal here!

Also, we made Certbot randomize the subject key by default every time it renews, so you have a huge amount of churn in subject keys, so you can't just say "oh, well, this public key has been used for a long time, so it's probably correct!". Every subject key is typically new and is unrelated to every previous subject key.

I hope that won't turn out to have been a poor trade-off. (We thought it was good to have more turnover of keys in order to reduce the impact of successfully stealing or cryptographically attacking one.)

Re: Entrust Certificate Distrust

#45

Post by glzone1 »

doctorpangloss wrote: post #40
aaomidi wrote: post #15

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

I 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 towa…

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

Re: Entrust Certificate Distrust

#46

Post by Scaevolus »

kseifried wrote: post #13

Entrust 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 corpora…

Aren't BIMI certs an even sillier cash grab than EV certs?

Re: Entrust Certificate Distrust

#48

Post by agwa »

olliej wrote: post #39
mikeiz404 wrote: post #36

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

This kind of thing was one of the reasons CT was introduced :D

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

Re: Entrust Certificate Distrust

#49

Post by agwa »

theandrewbailey wrote: post #26
crazysim wrote: post #2

Some popular users: chase.com aa.com

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?

Re: Entrust Certificate Distrust

#50

Post by intelVISA »

Kwpolska wrote: post #30
kseifried wrote: post #6

Earlier quoted context omitted.

Entrust 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 corpora…

BIMI is a CA racket.

Thanks Google...
Post reply on HN