> 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/d869a8d5-809d-4b08-9641-d89220bceb76n%40mozilla.org.
