--
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/20230609090430.3a4e8396e6e0b856fc81c6ab%40andrewayer.name.
--
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/528b5350-1a32-4730-8e7b-16644d135274n%40mozilla.org.
--
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/431eb7de-181e-4a32-9d22-3698bc7b0d0bn%40mozilla.org.
--
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/0f9174b3-02d6-4ff6-a7fa-3b931375076dn%40mozilla.org.
Mr Seifried,
> Is this really a situation where something extremely suspicious (remote code execution, CA's with multiple entities, some of which don't seem to properly exist, etc.) is going to be swept under the rug with a simple "yeah, we revoked this bad actors certificates, everything is fine"?
We are a reseller, not a physical root CA. This is a widely accepted solution for cross border businesses. We have business accepts online payment, the China users needs pay via alipay or wechat, to sign up the merchant we must have a china company,and foreign needs stripe, merchant must be a non-MainlandChina company. this is not suspicious.*. I represent the above opinion of my company
> If HiCA can do this, how do we know there are not more intermediate/reseller CAs doing this?
Most CA has no necessary to exploiting this RCE, because they can natively compatible with RFC 8555, they can define own CPS and CP, which contains validation policy, we does because we are not CA and can't to provider RFC 8555 ACME endpoint like a CA does. so a physical root CA has no necessary to provide ACME simulation by RCE. and also there're more difficulties for a ssl reseller to provide ACME service which real CAs won't undergo.- CSR stage difference: Most CA's subscriber request process or reseller API process, requires CSR be submitted in the `new-order` API, ACME requires CSR be submitted in `finalize` API. I have a topic in letsencrypt community years ago about this - https://community.letsencrypt.org/t/why-acme-requires-domain-auth-first-before-csr/98482- Challenge difference: Most CA's subscriber request process or reseller API process's DNS validation requires `_<md5>` / `_dnsauth` dnshost, and dnstype possibly CNAME or possibly TXT, But ACME's DNS validation dnshost is constant: `_acme-challenge`, dnstype `TXT`. And in a more deep talk ACME's dnsvalue needs publickey's thumbprint + server token which is totally different than traditional way's dnsvalue.My opinion is community can research how many ACME was publicly provided, and investigate is the provider a physical CA. if is natively compatible with RFC 8555, no worry about that one and continue do investigate next.*. I represent the above opinion of my personal. not my company.Sincere,Bruce.
To be explicit, GTS does not have a business relationship with HiCA.
Normally ACME services have protections against these types of MitM-CAs, but the remote RCE allowed HiCA to bypass these controls [1, 2].
For instance, it is possible HiCA replaced the local client's key authorization during challenge validation with a key authorization provided by HiCA, granting authorization of the domain names to HiCA. HiCA could theoretically use these authorizations to continue to issue certificates for the affected domain names, or revoke the certificates that were issued.
So clients of HiCA should also consider the lasting effects on the the domains in addition to your normal recovery procedures for an RCE. It may be prudent to reissue and revoke any certificates with your choice of CA directly and to watch certificate transparency logs for any future unintended issuance. GTS allows authorization reuse up to 28 days on our ACME endpoint and issues certificates with lifetimes up to 90 days. Other CAs may differ. By the current baseline requirements CAs can issue 398 day certificates and reuse the authorizations for 398 days [3].