Forwarding this to the list, I'm not comfortable with off list discussions in private.
On Sat, Jun 10, 2023 at 11:18 AM Xiaohui Lam <[email protected]> wrote: > 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. > > > > > 在2023年6月11日星期日 UTC+8 00:39:16<Kurt 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"? > > If HiCA can do this, how do we know there are not more > intermediate/reseller CAs doing this? > > https://news.ycombinator.com/item?id=36252310. > > Just a note, apparently, websites have been shut down and stuff deleted > with respect to HiCA. > > Posting some of the threads here in case they get removed or whatever: > > ================== > egecks 1 day ago | prev | next [–] > > I think the title buries the most horrifying part of this. The HiCA > certificate authority is relying on an RCE to do an end-run around the > semantics of the ACME HTTP-01 validation method. > Fucked up and they should be booted from every root program for this. > > ================= > > 0x0 1 day ago | prev | next [–] > > Looks like they are issuing under a sub-CA of "ssl.com" according to > https://github.com/acmesh-official/acme.sh/issues/4659#issue... > Interestingly, the mozilla dev-security-policy group seems to contain a > recent discussion about including "ssl.com" in the root store here > https://groups.google.com/a/mozilla.org/g/dev-security-polic... > > Curious to know if this could, maybe it should, have ripple effects to the > various SSL Root CA programs. Having someone run a subCA that actually > exploits an RCE against ACME clients doesn't seem very trustworthy, and any > CA enabling this behaviour should probably be kicked out of the trust > stores? > > reply > > > agwa 1 day ago | parent | next [–] > > The sub CA is operated by ssl.com, not HiCA (which is not a trusted > certificate authority). HiCA is relaying the certificate requests to > ssl.com, which is properly validating the requests in accordance with all > the requirements. ssl.com isn't doing anything wrong. That's why HiCA > needs to exploit an RCE in acme.sh - ACME doesn't support relaying > certificate requests to other CAs like this. > reply > > > 0x0 23 hours ago | root | parent | next [–] > > Someone posted a comment on github claiming they are the founder of > Quantum (the sub CA of ssl.com - see https://crt.sh/?caid=200960 ) and > that they are the provider of the HiCA service. So it does sound like there > is a closer link here than your comment would indicate: > https://github.com/acmesh-official/acme.sh/issues/4659#issue... > > reply > > > agwa 23 hours ago | root | parent | next [–] > > Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA > with the name "Quantum" in it, but this intermediate CA is operated by > ssl.com under all the same controls as ssl.com's other intermediate CAs. > Quantum has no ability to issue trusted certificates themselves. > reply > > > 0x0 23 hours ago | root | parent | next [–] > > So the person claiming to be the founder of "QuantumCA" does not possess > the private key corresponding to https://crt.sh/?caid=200960 - can we be > sure the private key is only accessible by ssl.com's CA system? So the > certificates listed here aren't issued by this person, but by the ssl.com's > system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de... > Also, why would ssl.com even create a subCA named "QuantumCA"? Are they > in business with this person claiming to be the founder of "QuantumCA" who > appears to be responsible for exploiting this acme.sh 0day? What does this > say about ssl.com's trustworthiness? Or is the person in the github > comments lying? > > reply > > > agwa 23 hours ago | root | parent | next [–] > > > So the person claiming to be the founder of "QuantumCA" does not possess > the private key corresponding to https://crt.sh/?caid=200960 - can we be > sure the private key is only accessible by ssl.com's CA system? So the > certificates listed here aren't issued by this person, but by the ssl.com's > system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de... > Correct. You can see the Quantum intermediates listed in ssl.com's most > recent audit statement, meaning an auditor has verified that ssl.com has > controls to protect the private key: > https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at... > > (The audit could be flawed, but it's the same amount of assurance we have > for any intermediate CA's private key - the fact that "QuantumCA" is in the > name does not change the risk calculus) > > > Also, why would ssl.com even create a subCA named "QuantumCA"? Are they > in business with this person claiming to be the founder of "QuantumCA" who > appears to be responsible for exploiting this acme.sh 0day? What does this > say about ssl.com's trustworthiness? Or is the person in the github > comments lying? > > There is a business relationship between QuantumCA and ssl.com. QuantumCA > is a reseller of ssl.com, and they've paid extra to ssl.com so that the > certificates they purchase get issued from an intermediate CA named > "QuantumCA" rather than one of ssl.com's usual intermediate CAs which > have "ssl.com" in the name. This lets QuantumCA pretend to be a real CA. > This is a common practice in the industry, and I don't think it says > anything about the trustworthiness of ssl.com, because the business > relationship with QuantumCA doesn't in any way subvert the integrity of the > WebPKI since ssl.com retains control of the issuance. Still, I wish > intermediate CA white-labeling were banned because it causes terrible > confusion about who is and isn't a CA. > > reply > > > 0x0 23 hours ago | root | parent | next [–] > > I find it troubling that a root CA (ssl.com) is apparently OK with > lending their name in a business relationship with an actor that is > actively exploiting an acme.sh 0day. > > > tptacek 20 hours ago | root | parent | next [–] > > This feels a little bit like doubling down to find ways to implicate the > actual CA instead of the reseller. It's clear how mismanagement by a real > CA would make a more interesting story than by this random > no-longer-existing pseudo-reseller, but I don't think there's evidence to > support that story yet. > reply > > > 0x0 20 hours ago | root | parent | next [–] > > But it's not a random pseudo-reseller? The one github comment from "the > founder of Quantum CA" seems to say they are also the creator of HiCA, > which is the entity that was exploiting the 0day in acme.sh. And the crt.sh > link shows an intermediate CA cert named "QuantumCA", signed by ssl.com. > So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same > entity? The intermediate CA could just as well be named "0dayexploitersCA"? > Why is it not a huge concern that ssl.com is fine with operating such a > "0dayexploitersCA" intermediate? > > Am I missing something here? > > reply > ================= > > > > > > > On Fri, Jun 9, 2023 at 1:32 PM Xiaohui Lam <[email protected]> wrote: > > Mr mochaaP, > > We're running businesses under multi entities, one is UK company, and one > is CN company, the UK company is registered and running by a former > workmate which leaved our team, and CN company is registered and running by > me. > > We do stopped from selling SSL.com certificate due to business concern and > the cross-sign root expiration concern, That meantime we do have some > cooperates with other CAs without whitelabel/intermediateCA, some CAs are > directly implemented and some are tier-2 implements(under other resellers). > So, our website is kept running, including HiCA keeps. > > But we will stop all misleading business to stop provide our Quantum brand > products, only contain our China company's materials. > > My KEY OPINION: our China entity has been kept in existence so we kept the > reselling business. > > Sincere. > Bruce Lam > 在2023年6月10日星期六 UTC+8 03:13:11<mochaaP> 写道： > > Hi Xiaohui, > > I think you may have misunderstood my message. What I meant to convey was > that I am skeptical of your intention to resell your own CA for a dissolved > Ltd. that was not subject to having its certificate revoked. We believe > that this practice is uncommon for a reseller in such a case. > > Please understand that my message was not intended to be hateful towards > you or your team. If you believe that this was an honest mistake, please > reply to this thread with more details. The community values transparency > and trust, and we would be happy to hear your perspective. > > Best regards, > Zephyr Lykos > On Saturday, June 10, 2023 at 1:08:08 AM UTC+8 Xiaohui Lam wrote: > > Thanks John to share this topic to the dev-security forum. > > This is HiCA founder, let me to explain your concern, Mr John , > the RCE is fully used to finish the challenge which validated by CAs, in > another word, the ACME.sh-enrolled certificates which passing this RCE, it > does compliant with each CA's BR validation requirements. CA did nothing > wrong. And also by this trick can enroll any CA's certificate before > acme.sh fix patch. > > and to Mr @mochaaP, you said to punish our team, we're NOT a public CA or > private CA(in my understanding, a CA must manage a or more PKI > infrastructure physically), [3]so the clarify relationship to HiCA w/ > QuantumCA is no necessary, but we still told we runs HiCA inside QuantumCA > project's source code, it's a sub-application inside it. > > I agree @Andrew's opinion, CAs shouldn't take any responsibilities to the > RCE incidents. or there are hundreds acme-tools for CAs need to concern. > 在2023年6月10日星期六 UTC+8 00:43:47<mochaaP> 写道： > > Hello, > > Although HiCA is not a CA itself, the person own HiCA seems also owns (or > at least works for) Quantum CA[1][2]. they also confirmed that Quantum CA > is operated by both their team and SSL.com team[3]. > > I think this probably is not as simple as a white-label intermediate CA > being abused, rather a CA that resells their own product to themselves to > prevent being punished for bad behaviors. > > [1]: https://github.com/xiaohuilam (see "Pinned" section) > [2]: https://github.com/quantumca (see "People" section) > [3]: > https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584546150 > (note that this person never clearified their relationship with Quantum CA > and only replied with "So this isn't the evidence to proof HiCA is a CA > which managed PKI.") > > Regards, > Zephyr Lykos > > On Friday, June 9, 2023 at 9:04:34 PM UTC+8 Andrew Ayer wrote: > > On Fri, 9 Jun 2023 05:42:22 -0700 (PDT) > "John Han (hanyuwei70)" <[email protected]> wrote: > > > Here is the story. > > https://github.com/acmesh-official/acme.sh/issues/4659 > > > > Seems like they exploited acme.sh and let user to evade certificate > > issuing procedure. > > > > Do we need to discuss this? > > The party in question (HiCA/QuantumCA) is not a certificate authority, > and I don't see any evidence that the actual CAs in question evaded any > validation requirements. > > HiCA/QuantumCA is just acting as an intermediary between subscribers > and the issuance APIs operated by actual CAs[1]. Literally anyone can > do this and do monumentally stupid/insecure things; it's not productive > to have a discussion every time this happens. > > Regards, > Andrew > > [1] It's true they have a reseller relationship with ssl.com, who are > operating a white-label intermediate CA with "QuantumCA" in the > subject, but HiCA/QuantnumCA are also fronting other CAs, including > GTS, which doesn't require a reseller agreement to access their free > ACME API, so I don't see that aspect as being productive to discuss > either. > > -- > > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0f9174b3-02d6-4ff6-a7fa-3b931375076dn%40mozilla.org?utm_medium=email&utm_source=footer> > . > > > > -- > Kurt Seifried (He/Him) > [email protected] > > -- Kurt Seifried (He/Him) [email protected] -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa3_qRN9Z7HeGfV20e-o-V2E4%2BB%2BNN%3D6o9xbBRCArB4RnHA%40mail.gmail.com.
