Hello Henry, Thank you very much for your patience in clarifying this matter.
We appreciate your correction of my misconception. We have also noted the significant difference in processing times when mainstream browsers remove trust for DigiNorta and Symantec CAs. It is indeed unrealistic to equate handling man-in-the-middle attacks with removing trust for misissued CAs. Additionally, regarding the MitM attacker's network control capabilities, we'd like to clarify one point. If an attacker (perhaps fearing condemnation or for other reasons) wishes to launch a low-profile attack, would this limit the scope or duration of their network hijacking? Once again, thanks for your generous insights. Best, Jin Tong 在2025年11月9日星期日 UTC+8 00:03:02<Henry Birge-Lee> 写道： > Hi Jin and community, > > I can provide some perspective on this. I am a security researcher > (formerly Princeton University) and I have been involved in threat > investigations related to PKI MITM (similar to the Klayswap attack > <https://blog.citp.princeton.edu/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/> > > ), I wrote two CA/Browser Forum ballots that directly addressed the MitM > threat to the PKI (MPIC and DNSSEC ballots which are now part of the > baseline requirements), and I have done some work on nation-state > censorship/interception behavior (e.g., https://arxiv.org/abs/2304.01073 > ) (see https://henrybirgelee.com/ ). > > Regarding 1: A long time (if ever). Actually mitigating the MitM risk from > a fraudulent certificate is a multi-step process and each step has a high > error rate. First the fraudulent certificate and attack needs to be > detected. This is often the longest and most difficult step even with CT. I > am aware of many attacks where either because of inaccurate root cause > analysis or the victim's desire to not make the attack publicly known, the > certificate in question simply expires (i.e., is never revoked). Even when > a certificate is revoked, it is often long after actual issuance because > someone is poking around CT logs. If we take CloudFlare's recent 1.1.1.1 > certificate issue for example (see > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SgwC1QsEpvc > ), this certificate was signed in May 2025 and not revoked until September > 2025 ( see https://crt.sh/?id=18603461241 ). This example comes from one > of the highest-profile TLS use cases in the world run by a major cloud > provider, so it's reasonable to assume smaller cases are going undetected. > Another sample of interest is the certificate involved in the Klayswap > attack ( https://crt.sh/?q=6097052179 ). This is one of the cases where > threat intel correctly identified the attack in a timely manner and the > victim took preventative action. The fraudulent cert was still valid from > Feb 3 to Feb 8 2022 ( 5 days). CA removal is a different story and has more > to do with the CA's specific behavior or with regard to the CA/Browser > Forum Baseline Requirements than simply the presence of a misissued > certificate. Sectigo (the CA that signed the Klayswap cert) is still > trusted because this cert was signed per CA/B guidelines and Sectigo > implemented the appropriate checks during domain validation. The 1.1.1.1 > cert is a different story. Regardless, CA removal is a much longer much > slower process than cert revocation and requires an incident report and > investigation into CA behavior (i.e., it is not an immediate reaction to a > known attack cert). > > Regarding 2: I would say it depends on the nation state and how > extensively the fraudulent certificate was used for interception. Some > nation states block VPNs and some populations are less likely to leave the > country in a short timeframe (e.g., rural). If a nation-state targeted a > MitM attack at specific subpopulations which were not likely to leave the > country, I would personally feel it could take much longer than a day. > Perhaps targeting of journalists or tourists would see subjects leaving the > area affected by the MitM on a more frequent basis. I should note that > there is no guarantee that a nation-state MitM is regional. Many nation > states have unfiltered BGP routers at their top ISPs and can launch a > global interception against many prefixes (e.g., Pakistan youtube > <https://www.nbcnews.com/id/wbna23339712> incident), although this type > of attack has significantly more implications in international politics > than an internal attack within the nation. > > (shameless plug) If you know an organization that is concerned about PKI > MitM attacks, I am CEO of a company that specializes in detecting and > preventing these types of attacks: https://www.crosslayerlabs.com/ > > Let me know if that information is helpful. > > Best, > Henry > > On Sun, Oct 5, 2025 at 10:26 PM Jin Tong <[email protected]> wrote: > >> Hello everyone, >> >> I'd like to discuss the potential impacts of a man-in-the-middle (MitM) >> attacker after a fraudulent certificate is issued. I hope someone can >> provide answers or recommend relevant materials addressing these questions: >> >> 1. >> >> After a fraudulent certificate is discovered, how long does it >> typically take to remove the fraudulent certificate and the associated CA >> to eliminate potential MitM attacks? >> 2. >> >> State-level MitM attacks often involve hijacking critical network >> nodes, suggesting such attacks typically exhibit geographic >> characteristics. Is it reasonable to assume that for most countries or >> regions, at least one victim node would escape the compromised >> environment >> within a day (e.g., by using a VPN or relocating their physical >> location)? >> If not, what would be a more accurate timeframe? >> >> Sincerely looking forward to your reply, >> Jin Tong >> >> -- >> 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 visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/2177e84b-e4a5-42bb-8782-56044ee09993n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/2177e84b-e4a5-42bb-8782-56044ee09993n%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ca053662-12e6-429a-92ff-89e95d064063n%40mozilla.org.
