According to the previous discussion, sslcom.cn should be actually controlled by ssl.com, but we found that both ocsp.sslcom.cn and crl.sslcom.cn are not compliant.
1. ocsp.sslcom.cn returned an incorrect response to the ocsp verification request, so the certificate could not be revoked. 2. crl.sslcom.cn responds to historical data (data before revoking), and the cache time is as long as 1 year. ``` # openssl crl -inform DER -in http://crl.sslcom.cn/SSLcom-RootCA-RSA-4096-R1.crl -text -issuer -hash -lastupdate -nextupdate issuer=/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root Certification Authority RSA 6fa5da56 lastUpdate=Jun 15 15:54:47 2023 GMT nextUpdate=Jun 9 15:54:46 2024 GMT Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root Certification Authority RSA Last Update: Jun 15 15:54:47 2023 GMT Next Update: Jun 9 15:54:46 2024 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59 X509v3 CRL Number: 19 Revoked Certificates: ... ``` Not compliant with CPS <https://legal.ssl.com/documents/SSLcom-CP-CPS-v1.17.pdf> 4.9.7 and 4.9.9. 在2023年6月20日星期二 UTC+8 03:24:19<Thomas Zermeno> 写道： > This is to provide an update on the revocation of the QuantumCA SubCAs. > They were all revoked within the required timeframe. Since they were never > enabled for ACME, there was never an issue with these SubCAs being used in > the HiCA acme.sh RCE client. > > With regards to other issues raised in the discussion and which mention > SSL.com: > > Before issuing SubCAs to any resellers, SSL.com performs verification > equivalent to an Extended Validation review of the organization applying > for the SubCA(s). In summary, this includes verification of the legal, > physical and operational existence, and verification of the authorization > of the request. It does not include background checks, reputational > research, or any checks for criminal records of the organization > representatives, other than checks against the applicable sanctions lists. > > In the case of Quantum, our checks included doing lookups on the > organization using the UK Registry Companies House and a Qualified > Independent Information Source (QIIS), verifying the identity of contact > persons representing the organization and comparing them against several US > sanctions lists. Additionally, we performed live interviews with company > representatives over teleconference and via the verified means of > communication with the organization. All required verifications were > performed and approved before issuance of QuantumCA’s SubCAs. > > Furthermore, we confirm that the sole purpose of domain sslcom.cn was to > serve CRL and OCSP responses, and SSL.com is the only entity operating the > OCSP responders and CRL distribution points under that domain. There are no > active certificates relying on that domain. > > Finally, we would like to point out that section 5.3.1 of our CP/CPS only > applies to employees, agents or independent contractors of SSL.com and > delegated third parties which are engaged in the Certificate Management > Process. As a branded SubCA consumer, QuantumCA was not a delegated third > party of SSL.com. Although not required, SSL.com still performed EV review > on them as we do with all other SubCA resellers. > > To summarize, the Quantum SubCAs were never enabled for ACME by SSL.com > and they could not have been used to issue certificates with the vulnerable > acme.sh client. During the course of this discussion, due to the > dissolution of Quantum CA Limited, we took additional action in revoking > their SubCAs. We hope these statements address all relevant concerns > regarding HiCA’s use of Quantum SubCAs issued by SSL.com. > > On Saturday, 17 June 2023 at 12:58:13 UTC-5 Xiaohui Lam wrote: > >> John Liptak, >> >> For the www1.hi.cn, >> >> There have *no payment business* entry *at the web. *it only accepts >> payments only on command line. So this one is controversial, You can’t ask >> a website that provides only an online donation button for a blog to also >> go through the ICP revenue registration which needs taking more than 10,000 >> yuan. >> >> So we think a website only published tutorials needn't ICP revenue >> business registration. >> You can check the website no member link to register/login, and cart >> functions to purchase product. >> >> - http://web.archive.org/web/20230330032620/https://www1.hi.cn/ >> >> We have no plan to invest resources(about thousands dollars) to apply the >> ICP revenue registration for a dead business. >> >> --- >> >> For www.quantumca.com.cn it have revenue business online, that's our >> mistake and, we decide to apply ICP revenue business registration at Q3. >> Sounds a little off-topic about the question, this thread should closely >> talking about RCE security or things technical. >> 在2023年6月18日星期日 UTC+8 01:33:39<John Liptak> 写道： >> >>> > We looked up the crt.sh tool [^1], It is a widely accepted way for >>> subordinate CA customization resellers to provide domain for CA’s different >>> OCSP hosting. Look up ocsp responder which public-suffixing .cn，We can find >>> my many responders of Sectigo and DigiCerr own domain ICP but no business >>> ICP. >>> >>> This is a red herring fallacy. What I asked was your the person in >>> charge of the domain sslcom.cn is different from the person in the ICP >>> beian application you sent to the government. This is what I said: >>> *If it is operated by SSL.com, then that means you had provided false >>> materials to the government and the person/legal entity in charge of the >>> website is different from the person in your application*. >>> >>> Also, Tom from SSL.com has claimed "other than to provide them brandable >>> certificates"; however, I think you must have helped or assisted SSL.com to >>> establish this CRL/OCSP server in China. You are more than a reseller. >>> >>> Since you mentioned digicert, I did look them up. >>> >>> digicert.cn is registered and operated by Digicert China. The ICP beian >>> also shows the domain belongs to Digicert China. >>> >>> dcocsp.cn is registered by iTrusChina. Do you have evidence that >>> iTrusChina is not operating dcocsp.cn? iTrusChina is listed in >>> Digicert's Trusted partners directory. >>> https://www.digicert.com/es/partners/trusted-partners-directory >>> >>> iTrusChina is a root CA and has obtained webtrust audits. >>> Moreover, iTrusChina has ICP license. They also have 电子认证服务许可证, >>> 电子认证服务使用密码许可证, and 电子政务电子认证服务批文 issued by the State Cryptography >>> Administration (国家密码管理局). >>> >>> Even iTrusChina is not operating dcocsp.cn, again, just because someone >>> else is doing the same thing doesn't mean it's not illegal. >>> >>> > And many of them have ICP license for domain, but no ICP business >>> license. >>> Since you asked this question: I want to point out Digicert has never >>> used digicert.cn to SELL certificates. However, you sell certificates >>> directly on your quantumca.com.cn and www1.hi.cn >>> On Saturday, June 17, 2023 at 1:54:11 AM UTC-4 inao...@gmail.com wrote: >>> >>>> Thank you for your further response and questions. >>>> >>>> > You claimed "We never operates the CRL and OCSP responders. But CA >>>> does(SSL.com can confirm it)," but you are serving CRLs and OCSP responses >>>> from the domain sslcom.cn, which is registered by 上海帝熙科技有限公司 and the >>>> ICP beian shows it belongs to 上海帝熙科技有限公司. If it is operated by SSL.com, >>>> then that means you had provided false materials to the government and the >>>> person/legal entity in charge of the website is different from the person >>>> in your application. >>>> >>>> We looked up the crt.sh tool [^1], It is a widely accepted way for >>>> subordinate CA customization resellers to provide domain for CA’s >>>> different >>>> OCSP hosting. Look up ocsp responder which public-suffixing .cn，We can >>>> find >>>> my many responders of Sectigo and DigiCerr own domain ICP but no business >>>> ICP. >>>> And many of them have ICP license for domain, but no ICP business >>>> license. >>>> So I think meantimes the subordinate CA’s created at, there’s no leads >>>> to reveal the way is illegal toChinese regulations or violations to CPS/CP. >>>> >>>> >>>> If my opinion wrong, correct it welcome >>>> >>>> >>>> [1]. https://crt.sh/ocsp-responders >>>> >>>> Sincere, >>>> Bruce Lam >>>> ------------------------------ >>>> 发自我的iPhone >>>> >>>> >>>> ------------------ Original ------------------ >>>> *From:* John Liptak <johnli...@gmail.com> >>>> *Date:* Sat,Jun 17,2023 10:33 AM >>>> *To:* dev-secur...@mozilla.org <dev-secur...@mozilla.org> >>>> *Cc:* xiaohuilam <inao...@gmail.com>, Thomas Zermeno < >>>> madca...@gmail.com> >>>> *Subject:* Re: RCE used by Intermediate CA to issue certificates. >>>> I've been a member of chromium-dev group and am particularly interested >>>> in internet security. I choose not to reply all because I'm asking >>>> questions to specific people. The screenshot you've taken shows I'm asking >>>> that question to you and the SSL.com representative, not to everyone else. >>>> >>>> Because SSL.com CPS 5.3.1 claims they will verify the trustworthiness >>>> of an independent contractor and apparently you are doing this business >>>> illegally in China (e.g., selling digital certificates online without the >>>> ICP license), so I don't think they follow their CPS. >>>> >>>> You claimed "We never operates the CRL and OCSP responders. But CA >>>> does(SSL.com can confirm it)," but you are serving CRLs and OCSP responses >>>> from the domain sslcom.cn, which is registered by 上海帝熙科技有限公司 and the >>>> ICP beian shows it belongs to 上海帝熙科技有限公司. If it is operated by SSL.com, >>>> then that means you had provided false materials to the government and the >>>> person/legal entity in charge of the website is different from the person >>>> in your application. >>>> >>>> Again, all these evidence reveals SSL.com did not verify the >>>> trustworthiness of an independent contractor and I think they don't follow >>>> their CPS. >>>> >>>> I am not Chinese and I have no interest in attacking HiCA. >>>> Nevertheless, I am interested in whether SSL.com and you have followed the >>>> CPS and operated legally. >>>> On Friday, June 16, 2023 at 4:07:33 AM UTC-4 xiaohuilam wrote: >>>> >>>>> Your horner Mozilla PKI Policy team and CA members, >>>>> >>>>> >>>>> The accusation is fabricated and I have good evidence that >>>>> bir...@gmail.com and johnli...@gmail.com appearing on this mailing >>>>> list are new potential detractors with the identity and speech style of >>>>> https://github.com/acmesh- >>>>> official/acme.sh/issues/4675 and DDOS attack criminals >>>>> https://hostloc.com/thread-1177834-1-1.html are highly similar (do >>>>> not care about technical and industry compliance or even RCE >>>>> vulnerability >>>>> itself, rather than trying to discredit a company as credible). >>>>> >>>>> I will introduce some of the origins of these IDs with me. >>>>> After Matthew Holt revealed that ACME.sh had an RCE vulnerability and >>>>> was exploited by HiCA, our 2 Chinese servers and 6 overseas servers were >>>>> severely attacked by DDOS, and also considered to so we try to close >>>>> HiCA >>>>> to avoid DDOS attacks from affecting our kernel business users (it is web >>>>> page accepts CSR to issue certificates which registered online, which has >>>>> nothing to do with ACME in command line). >>>>> >>>>> However, due to DNS cache and other reasons, the attack continued; >>>>> during this period, we analyzed the logs and switched routes to block a >>>>> large number of IPs. Later we saw that acme.hi.cn and www1.hi.cn had >>>>> no traffic at all and the attack was still affecting until we saw >>>>> >>>>> - https://hostloc.com/thread-1177834-1-1.html >>>>> (He tried to call on others to participate in the CC Flood/DDOS >>>>> website using the webbench tool made by golang, and we believe himself >>>>> participated) >>>>> >>>>> We contacted the attack source IP ASN owner/ISP: the abuse prevention >>>>> team of IPXO LLC, and finally blocked the attacker's IP. >>>>> [image: 网页捕获_16-6-2023_153756_help.ipxo.com.jpeg] >>>>> >>>>> When we collected all the evidence and prepared to report the case >>>>> added a statement on restored www1.hi.cn website and, the attacker’s >>>>> settlement new topic came, to compromise >>>>> >>>>> - https://hostloc.com/thread-1178837-1-1.html >>>>> - https://hostloc.com/thread-1179012-1-1.html >>>>> >>>>> The other party expressed their willingness to pay for the part of the >>>>> bill that we can prove to be related to him due to the loss caused by >>>>> DDOS. >>>>> We did not take the next legal action to advocate punishment for the >>>>> network DDOS attackers because they did pay me: >>>>> [image: 1521686900808_.pic.jpg] >>>>> (Note that the memo information of the other party’s remarks is: DDOS >>>>> attack compensation. To protect the privacy of him we did mosaic) >>>>> >>>>> >>>>> We thought the matter was over. I had some unanswered questions on >>>>> twitter just before Matthew Holt's twitter reply. (Forgive the twitter >>>>> account I registered more than ten years ago that has not been used for a >>>>> long time and cannot meet the risk control; it took a lot of time to >>>>> re-register one). >>>>> >>>>> Until this Issues appeared, >>>>> - https://github.com/acmesh-official/acme.sh/issues/4675 >>>>> >>>>> It's hard to imagine such abusive voices in the community and on the >>>>> dev-security-policy mailing list. Even though it's an accusation we can >>>>> try >>>>> to respond to, it's frustrating that this post isn't a technical >>>>> accusation. And we found an interesting thing: >>>>> >>>>> The issuer ID gzchjz007 of >>>>> https://github.com/acmesh-official/acme.sh/issues/4675 is highly >>>>> similar to the criminal ID gzchenjz of our ddos server! >>>>> >>>>> When I pointed out that their slander is fake, this ID gzchjz007 and >>>>> gzchenjz stopped acting, but a new ID appeared, and came to this >>>>> dev-security-policy post. That's why I think they're suspicious: >>>>> - bir...@gmail.com >>>>> - johnli...@gmail.com >>>>> >>>>> >>>>> Because they are Chinese speaking people, but pretend to be non-asian. >>>>> they made same mistake i did, they replied author only but when i respond >>>>> they quick reposted one time suspicious >>>>> [image: image.png] >>>>> >>>>> >>>>> they are obviously Chinese to don't understand two button(“回复全部” and >>>>> “回复作者”)'s difference, they are very familiar with the Chinese network but >>>>> pretend to be English nicknames and IDs and to bash competitors., and >>>>> what >>>>> is even more unbelievable is that they did not have any maillist >>>>> participation records before this mailing group. >>>>> >>>>> [image: image.png] >>>>> >>>>> [image: image.png] >>>>> >>>>> >>>>> >>>>> But if we look up other real industry participants there must be a >>>>> mail listing included.(i tried lookup, No offenses, Mr Kurt Seifried) >>>>> [image: image.png] >>>>> >>>>> I think everyone has the right to accuse because this is freedom, but >>>>> it doesn't mean that one person can play multiple roles to abuse this >>>>> dev-security-policy mailing list, besides who're affiliated with the >>>>> Cybercriminals DDoS Team. >>>>> >>>>> If they are really an industry participant who will not commit the >>>>> misconception that OCSP and CRL will be operated by resellers, please >>>>> register an official ID to participate in the discussion. We welcome it, >>>>> and I believe the community does too. But I am convinced that they are >>>>> the >>>>> ones who denial-of-service cyber attacks on our servers, and we have >>>>> decided to formally prosecute them for criminal acts. >>>>> >>>>> >>>>> >>>>> Roger M Lambdin <bir...@gmail.com> 于2023年6月16日周五 14:34写道： >>>>> >>>>>> Dear members. >>>>>> >>>>>> I have conducted a background check on HiCA administrator Xiaohui Lam >>>>>> and would like to share the following with you. These findings are for >>>>>> reference only, so please evaluate them for yourself. >>>>>> >>>>>> First, in 2013, Xiaohui Lam hijacked AFF promotions by exploiting >>>>>> vulnerabilities in Aliyun forums, defrauded hostloc members by >>>>>> installing >>>>>> backdoors in Discuz forum plugins, and stole others' social accounts >>>>>> through leaked data from CSDN [^1]. >>>>>> >>>>>> Second, in 2015, Xiaohui Lam exploited a vulnerability in the >>>>>> GlobalSign system to sell a large number of 5-year wildcard >>>>>> certificates, >>>>>> but all certificates were revoked after they were discovered [^2]. >>>>>> >>>>>> I would like to emphasize that these are past actions of HiCA >>>>>> administrators and I do not think he will repeat the same mistakes >>>>>> again. >>>>>> However, these events show that he is not a developer who knows very >>>>>> little >>>>>> about security. In the past, he has been someone who knew how to mine >>>>>> vulnerabilities, exploit them and commit fraud and threats against >>>>>> customers. >>>>>> >>>>>> Based on the above findings, I believe we need to take the following >>>>>> steps: >>>>>> >>>>>> 1. Considering that he suggested users to execute his script RCE[^3] >>>>>> with root privileges on his official website, we should send a reminder >>>>>> email to all users who have applied for a certificate, asking them to >>>>>> evaluate whether there is unauthorized code on their machines. >>>>>> >>>>>> 2. the results of the query found that Mr. Lam has two CAs: HiCA and >>>>>> Quantum CA. the website for registration information about Quantum CA is >>>>>> acme.hi.cn. then we need to confirm whether they are using the same >>>>>> infrastructure and whether Quantum CA also uses RCE to issue >>>>>> certificates >>>>>> [^4]. >>>>>> >>>>>> Mr. Lam has shut down HiCA's infrastructure after he was found to be >>>>>> using RCE, but we still need to do a more detailed assessment. >>>>>> >>>>>> As a member of the community, I believe transparency and trust are >>>>>> vital to us. I hope Mr. Lam will provide the community with a more >>>>>> complete >>>>>> statement and evidence so that the community can evaluate this incident. >>>>>> >>>>>> [^1]: >>>>>> https://web.archive.org/web/20130816004143/http://bbs.aliyun.com/read.php?tid=144441 >>>>>> [^2]: https://v2ex.com/t/178503?p=1 >>>>>> [^3]: >>>>>> https://web.archive.org/web/20230325041716/http://www1.hi.cn/docs/getting-started/acme.sh-installation >>>>>> [^4]: https://www.tianyancha.com/company/5599034293 >>>>>> https://www.tianyancha.com/company/3435468365 >>>>>> >>>>> 在2023年6月16日星期五 UTC+8 06:00:39<John Liptak> 写道： >>>>>> >>>>>>> > First, the cryptography license license is mandatory only for CAs >>>>>>> (organizations who operate PKI facilities); >>>>>>> >>>>>>> You are operating a CRL & OCSP server in China, right? >>>>>>> >>>>>>> > Secondly, There are many sole proprietorship (self-employed >>>>>>> people) are also selling SSL digital certificates and running their own >>>>>>> websites, which is totally unable to enroll ICP Registration License. >>>>>>> >>>>>>> Just because someone else is doing the same thing doesn't mean it's >>>>>>> not illegal. >>>>>>> >>>>>>> > your post is completely weering off topic. >>>>>>> >>>>>>> I'm concerned with SSL.com CP/CPS 5.3.1. It claims "SSL.com >>>>>>> verifies the identity and trustworthiness of all personnel, whether as >>>>>>> an >>>>>>> employee, >>>>>>> agent, or an independent contractor, prior to the engagement of such >>>>>>> person(s)." >>>>>>> >>>>>>> If an independent contractor operates illegally in his/her country, >>>>>>> how can he/she be considered trustworthy? >>>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/aa0ce0ff-fcc9-4c9b-974d-023c2be81b34n%40mozilla.org.
