Entrust, ransomware, can they be trusted?

[LB]

Given news that Entrust were subject to a ransomware attack, which until now they have not confirmed or given any details on in public - what point do we need to assume the CAs and CA operations are compromized?

Should action be taken by Mozilla to eliminate risk and remove trust in root authority?

[Ben Wilson]

Actually, Entrust reached out about a month ago with this message to me:

On June 18, 2022, we determined that an unauthorized party accessed certain of our systems used for internal operations – functions such as HR, finance, and marketing. We promptly began an investigation with the assistance of a leading third-party cybersecurity firm and have informed law enforcement.  

While our investigation is ongoing, we have found no indication to date that the issue has affected the operation or security of our products and services, which are run in separate environments from our internal systems and are fully operational. Regarding our Public Certification Authority - all roots are offline and require multiple security cleared people be physically present in a secure room to access.

We take seriously our responsibility to protect our systems and have been engaged with our customers on the issue.      

 

As stated, there was no impact to our roots as the roots are offline and can only be accessed if two people are physically present in a secure room. Also, our PKI system is on a separated infrastructure, so was not accessed.

 

Since there has been no impact to our PKI and certificate issuance systems, which use roots distributed by your application, we did not raise an incident.

Ben

On Mon, Aug 22, 2022 at 9:26 AM 'LB' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Given news that Entrust were subject to a ransomware attack, which until now they have not confirmed or given any details on in public - what point do we need to assume the CAs and CA operations are compromized?

Should action be taken by Mozilla to eliminate risk and remove trust in root authority?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/zEcsmYjEJdXUd-H8gWEsBaGnIx44oLKyjOHxvd7edfkpHSc58eRxXoWH7sfZot5hWqBNaPe-7topJps-0YQQedb1UvuUwvBe4T43dNoSALE%3D%40proton.me.

[LB]

Oh, that's ok then. Nothing to worry about. Absolutely no risk to the public here and definitely not worth discussing.

Sent with Proton Mail secure email.

------- Original Message -------

[Ryan Hurst]

While that is positive news I will point out that in past incidenta compromise of non-issuance related infrastructure enabled attackers to achieve lateral movement which in turn led to deeper compromises, in some cases such as DigiNotar, this led to miss-issuance. 

I think if nothing else this begs the question what kind of notification requirements to the community should exist for such situations. 

It just doesn't feel right that this incident is public and the only details relating to its impact on the WebPKI is discovered by the community in this fashion.

Ryan Hurst

(Personal Capacity)

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZmE5vqWKiyXwWHbz-AV5piXM0oshc%3DoVrAAw3MVh_NHw%40mail.gmail.com.

[LB]

It does not feel right, I agree Mr Hurst.

More information from the attack is coming to light, and it is concerning.

To Mozilla: when the full extent of the leak comes out, with the data (and it will) - what will be your threshold for action? Are you expecting '-----begin rsa private key-----' or something less?

Risk is posed to all users of Mozilla products (and also Microsoft and Apple and Google who i am sure are having similar thoughts).

At very least Entrust should stop issuing certificates - they should have before.

why do we trust Entrust here?

What will Mozilla do if it comes to light there was a real compromise and huge risk and Mozilla knew privately but did nothing? Is risk to internet users of no concern?

Sent with Proton Mail secure email.

------- Original Message -------

[Phillip Hallam-Baker]

Is Mozilla going to hold itself accountable to whatever absurd maximalist requirements come from the game of 'beat up the third party because we have power here'?

Browsers have bugs. The result of a coding error that permits a script injection or buffer run attack is at least as serious as any error or omission by any CA. In my experience, those are found with much higher frequency than CA errors or omissions.

The issue with DigiNotar was not that they were breached, it was that they lied about it. The breach itself was a lot more serious because of the way they had configured their internal systems but even that might have been fixable if they hadn't lied about the breach.

I haven't worked for a CA for several years now. I do Threshold Key Infrastructure these days.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3NWDj3HP1779rDQl1tUjIFERNRMjAUZgoVR6msxTHPIqa9hUCmM6W6HbRkJLUq1gNBHC4wuKEzmPNKoSf33gsJmQ7OmopvwgDz97dlMsdbU%3D%40proton.me.

[Matthias Merkel]

I agree that even considering removing a CA just because of a compromise unrelated to CA infrastructure is completely inappropriate if the breach has been handled well.

As long as a breach is handled properly and learned from, there should be no reason to take such drastic measures, especially if no misissuance occurred. At least this allows for security problems to be resolved.

If we remove every CA that ever had any incident of any kind, we will end up with only new CAs that likely have even more security problems, just ones no one has discovered yet.

Matthias Merkel

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwg6cvDrck2dK-6wxXxEj_sRBpUeA8q16dbWjpJRURA-UA%40mail.gmail.com.

[Jeffrey Walton]

On Tuesday, August 23, 2022 at 2:58:53 PM UTC-4 matt...@matthias.zone wrote:

I agree that even considering removing a CA just because of a compromise unrelated to CA infrastructure is completely inappropriate if the breach has been handled well.

As long as a breach is handled properly and learned from, there should be no reason to take such drastic measures, especially if no misissuance occurred. At least this allows for security problems to be resolved.

If we remove every CA that ever had any incident of any kind, we will end up with only new CAs that likely have even more security problems, just ones no one has discovered yet.

I think you may be missing the bigger picture. The industry is built upon trust. Lack of transparency has some people concerned. I really don't trust companies when they say "trust us...". It makes the hair on the back of my neck stand up.

"Trust us" failed with DigiNotar, and it failed with Symantec when they were repeatedly caught issuing certificates for domains not under their administrative control. Once the trust is lost the commodity the company is peddling evaporates.

If Firefox or Chrome has a bug, the browsers are transparent about it. It usually lands in the bug tracker or change log. Everyone knows about due to the transparency. It is easy to trust a browser because we can verify it.

Jeff

 

[Matthias Merkel]

Absolutely, it is important that CAs are transparent about these incidents, that's why I said "if handled properly" - but I don't think that was an issue here? I understand that Entrust has not provided many details, but they did not hide the breach either. Removing CAs for non-critical security breaches that are being properly handled and disclosed would probably achieve the opposite, i.e. CAs trying to hide them completely.

Maybe there should be a policy that requires CAs to disclose incidents not involving CA operations on Bugzilla in detail like they do mis-issuances?

Matthias Merkel

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ac21e5cc-5c5f-483e-b2ea-8305e929728bn%40mozilla.org.

[Ben Wilson]

All,

I have opened an issue in Github to begin work on drafting reporting requirements for CA operators that encounter cyberattacks and other kinds of security-related incidents. See https://github.com/mozilla/pkipolicy/issues/252 (Add Requirements for Reporting Attacks and other Security Incidents).

Ben

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKtZuQ5XF-7pFkfYsvZ8P%2B-HJ2qe8kLwwjxtChPt3wmSR8718A%40mail.gmail.com.