shackleford posted:

like the "maybe we will consider establishing a process to review our contact details in the database once a year" thing where another CA piped up with "actually here is the chain of rules that result in requiring your contact details to be kept up to date within 14 days"

flakeloaf posted:

almost as though people have been standing by waiting for a reason to stick a knife in them

Martin Sullivan posted:

On 29th of April 2024 a DigiCert employee received a personal call from a Sectigo employee. During the call, Sectigo mentioned that they had seen some issues with the case sensitivity of entries in the business category for some EV certificates. This was escalated internally, and an investigation was started.

The initial investigation showed there is no issue with certificates currently being issued. Expanding this investigation to previously issued certificates, we confirmed there is some subset of certificates issued in 2023 where the Business Category included "Private organization" rather than "Private Organization" and "Government entity" rather than "Government Entity".

Section 7.1.4.2.3 states that the businessCategory field MUST contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non‐Commercial Entity”.

Although we will file a full incident report later, our initial investigation shows that part of the issue resulted from an internal debate on whether the language required a case-sensitive string. Section 71.1.4.2.3 was also confused with section 9.2.5 as the initial report was for “Government entity”. Note that section 9.2.5 does not have the same exact string requirement.

The fact the EV guidelines were written by lawyers a long time ago. While engineers are case sensitive by default, lawyers are not, which makes this a question of intent. It's plausible to interpret the EVGs as non-case sensitive, while retaining case sensitivity for the BRs. Note that not all terms surrounded by quotes are case sensitive. For example, in 8.5.2 would be ridiculous if an “inactive” company was blocked but not an “Inactive” company.

This is especially true as there is a general [mis] conception that X.509 is case insensitive due to domain names being case insensitive. Although X.509 itself does not explicitly state that it is case insensitive, a quick google search shows this is a widely held believe: https://security.stackexchange.com/questions/150770/are-certificate-sans-case-sensitive or https://security.stackexchange.com/questions/187095/do-tls-standards-require-applications-to-be-picky-on-case-sensitivity-of-hostnam. As part of this effort we are rectifying this misunderstanding.

DigiCert is currently investigating the full scope of this issue and compiling a list of certificates. We will post the results of our investigation along with a root cause by the 9th of May.

David Benjamin / Google posted:

Subscribers typically provision a single certificate for all
supported relying parties, because relying parties do not communicate
which CAs are trusted. This certificate must then simultaneously
meet requirements for all relying parties.

This constraint imposes costs on the ecosystem as PKIs evolve over
time. The older the relying party, the more its requirements may
have diverged from newer ones, making it increasingly difficult for
subscribers to support both. This translates to analogous costs for
CAs and relying parties:

* For a new CA to be usable by subscribers, it must be trusted by
all relying parties. This is particularly challenging for older,
unupdatable relying parties. Existing CAs face similar challenges
when rotating or deploying new keys.

* When a relying party must update its policies to meet new security
requirements, it must choose between compromising on user security
or imposing a significant burden on subscribers that still support
older relying parties.

This document aims to remove this constraint with a multi-certificate
deployment model. Subscribers are instead provisioned with multiple
certificates and automatically select the correct one to use with
each relying party. This allows a single subscriber to use different
certificates for different relying parties, including older and newer
ones.

Wiggly Wayne DDS posted:

so entrust's pr team added themselves to the cc list on the snowballing issue involving ben. i gather they didn't realise that's all public..

anyway only through the pr team inviting themselves did i notice they have a cybersecurity podcast with an episode as recent as 7 days ago. the cert expired april 28th

digitalist posted:

digitalist posted:

digitalist posted:

quote:

Hello,

We’re reaching out because on April 24th, we became aware of unauthorized access to the Dropbox Sign (formerly HelloSign) production environment. Upon further investigation, we discovered that a threat actor had accessed Dropbox Sign customer information. You are receiving this message because your information was in the data the third party accessed.

What happened
We can confirm that Dropbox Sign customer information such as emails, usernames, phone numbers and hashed passwords, in addition to general account settings information and certain authentication information such as API keys, OAuth tokens, and multi-factor authentication were obtained. Recipient names and emails were also exposed. Based on our investigation, there is no evidence of unauthorized access to the contents of customers’ accounts (i.e. their documents or agreements), or their payment information.

What we’re doing
When we became aware of this issue, we launched an investigation with industry-leading forensic investigators to understand what happened and mitigate risks to our users. In response, our security team reset users’ passwords, logged users out of any devices they had connected to Dropbox Sign, and is coordinating the rotation of all API keys and OAuth tokens.
What you can do
API key rotation: To ensure the security of your account, you will need to rotate your API key by generating a new one, configuring it with your application, and deleting your current one. Until you’ve rotated your API key, we’ll be restricting certain functionality as an additional precaution. Only signature requests and signing capabilities will continue to be operational for your business continuity. Once you rotate your API key, restrictions will be removed and the product will continue to function as normal. Here is how you can easily create a new key.

OAuth token rotation: You will need to reprovision your OAuth token by revoking the granted permission and re-authenticating it. Here is how you can easily create a new token.

Salesforce integration: If you've integrated Salesforce with Dropbox Sign, we've rotated your key to protect your account. Please disconnect and reconnect the Dropbox Sign Salesforce integration by following these instructions.

Passwords and multi-factor authentication: We’ve expired your password and logged you out of any devices you had connected to Dropbox Sign to further protect your account. The next time you log in to your Sign account, you’ll be sent an email to reset your password. Customers who use an authenticator app for multi-factor authentication should reset it as soon as possible. Please delete your existing entry and then reset it. If you use SMS you do not need to take any action.

If you reused your Dropbox Sign password on any other services, we strongly recommend that you change your password on those accounts and utilize multi-factor authentication when available. Instructions on how to do this for your Dropbox Sign account can be found here.
At Dropbox, our number one value is to be worthy of trust. We hold ourselves to a high standard when protecting our customers and their content. We didn’t live up to that standard here, and we’re deeply sorry for the impact it caused our customers. We are grateful for your partnership, and we’re here to help all of those who were impacted by this incident. For more information on this incident, how to contact us, and updates, see here.

- The Dropbox team

digitalist posted:

Wiggly Wayne DDS posted:

quote:

While engineers are case sensitive by default, lawyers are not

SeaborneClink posted:

https://www.sectigo.com/resource-library/root-causes-260-ca-trustcor-deprecated

Wiggly Wayne DDS posted:

some things happened today:
- Entrust provided an incident report for Entrust: Not updating Problem Reporting Mechanism fields in CCADB... to say it is light in any concrete information is too kind.

- Some update on 'revocations':
2024-05-02 12:16: (delayedRevoc cPSuri): Update on the revocation progress: 14,736 certificates have been revoked or expired. 2,130 certificates have been re-issued with revocation pending. 866 out of 944 customer accounts have fully remediated the issue (certificates re-issued and old certificates revoked).
2024-05-02 12:18: (delayedRevoc serverAuth EKU): Update on the revocation progress: 310 certificates have been revoked or expired. 15 certificates have been re-issued with revocation pending. 101 out of 114 customer accounts have fully remediated the issue (certificates re-issued and old certificates revoked).

- This puts them at 55.26% revoked on cPSuri (26,668 certs) after revocation allegedly started 2024-03-19 (44 days).
- This puts them at 26.36% revoked on serverAuth (1,176 certs) after revocation allegedly started 2024-03-20 (43 days).

- The ongoing discussion about Entrust is currently split over 2 issues atm, latest comment is: https://bugzilla.mozilla.org/show_bug.cgi?id=1890896#c23

fins posted:

holy lol at the TrustCor thread.

tl;dr version:

q: hey trustcor, u scammin?

a: [giant wall of text about defence contractors and governments being in bed together, along with some thinly veiled threats of legal action]

quote:

Based on that understanding (and again, please let me know if any of that is incorrect), I personally believe it's possible that Rachel may be a victim here, if she really is the primary TrustCor shareholder (e.g., maybe the company was given to employees, after it was no longer useful). If TrustCor's private keys were compromised at its founding or before (e.g., so that Packet Forensics could sell TLS-interception boxes), the company itself would have little continued value, so long as it passed its audits (and remained trusted by browsers and operating systems). It's therefore possible that Rachel had no awareness of this, and as a result is in the denial phase of realizing that she's the victim of a scam. This is not a statement of fact, I'm just offering it as a possibility.

quote:

To now theorize and publicly suggest that "I am in a denial phase of realizing that I am a victim of a scam" is disrespectful and outlandish. I think you're taking this too far by making claims against me personally and I don't think its a good representation of your professionalism. You've forced us to be in a position to defend our company, but putting me in a position to have to defend myself personally is crossing the line. Would you have made the same assumption if I were a man?

For the record, I have been with TrustCor since its inception and have personally bared witness to the initialization and installation of the hardware baring TrustCor's roots and private keys and can absolutely vouch for the safe handling of TrustCor's keys and credentials at all times.

Raymond T. Racing posted:

Enterprise: "we use public web PKI for reasons"
Wayne: "so should it be secure"
Enterprise: "no comment"

shackleford posted:

i particularly enjoyed this part



bared witness lmao

shackleford posted:

i particularly enjoyed this part



bared witness lmao

Shame Boy posted:

i didn't read the thread, is trustcore just rachel in a trenchcoat or something

Lain Iwakura posted:

who was the last root to lose trust like this? it feels like it has been a few years

Applebees posted:

Also E-Tugra in https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/yqALPG5PC4s

fins posted:

holy lmao at the pen test reports. this is pretty much the entirety of the reports. page 1, cover page. page 2, blurb + these graphs. page 3, graph legend. there is no page 4.





plus the whole "3 minutes" thing. are they being wilfully ignorant?

Volmarias posted:

The linked issue in buganizer was a fun read of watching someone continuously avoid answering questions or intentionally misunderstand them. I did actually laugh when I saw the "executive summary" provided for their pen test.

quote:

E-Tugra EBG Information Technologies and Services Inc. Penetration tests of the systems
were carried out on the internet between 07.02.2023 and 27.02.2023, and verification
studies were completed on 10.05.2023.

Audits were carried out only on the Internet and non-technical attack methods such as
social engineering were not used. In addition, during the attack inspections, "denial of
service attacks" and techniques that could lead to this result were not used in order not to
damage the internet infrastructure of E-Tugra and to prevent any damage to the services
provided to the customers.

As a result of the verification studies, only 1 low-risk security vulnerability was identified.

During the studies, direct access to internal networks and databases could not be provided,
but it was observed that some server configurations were missing.

Thank you for choosing Lostar Information Security Inc.