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 [email protected] 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 <[email protected]> >> *Date:* Sat,Jun 17,2023 10:33 AM >> *To:* [email protected] <[email protected]> >> *Cc:* xiaohuilam <[email protected]>, Thomas Zermeno <[email protected]> >> *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 >>> [email protected] and [email protected] 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: >>> - [email protected] >>> - [email protected] >>> >>> >>> 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 <[email protected]> 于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 "[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/b83eb2f2-f386-4417-b1e7-64a0f9e1ae71n%40mozilla.org.
