Hi Ben, My name is Henry Birge-Lee. I am a researcher at Princeton University. I began studying the use of BGP attacks to obtain bogus TLS certificates in 2017 and worked to design a countermeasure known as multiple vantage point domain validation which can be implemented by CAs. It involves a CA performing domain control validation from multiple vantage points spread throughout the Internet. This allows the CA to detect BGP attacks because many BGP attacks do not affect the entire Internet (vantage points not affected by the attack contact the server of the victim and realize that the victim never requested the certificate).
We have since worked diligently through a collaboration with Let’s Encrypt to get this countermeasure *fully deployed at scale *in Let’s Encrypt’s production operation and we co-authored a USENIX Security paper with Let’s Encrypt engineers to explain the details of and evaluate this deployment from a security and performance perspective ( https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee ). Cloudflare also has a deployment of multiple-vantage-point validation ( https://blog.cloudflare.com/secure-certificate-issuance/ ) which I was involved in evaluating as well. Finally, Google Trust Services recently started performing multiple vantage point validation and Ryan Hurst at google posted a series of tweets referencing this in light of these recent BGP + TLS attacks: https://twitter.com/rmhrisk/status/1574995320727293952 We have been internally working on the most appropriate way to bring this topic to the CAB Forum (I was lucky enough to be invited to a validation working group meeting several years ago, but this project was not as mature then and I feel it needs to be further reassessed in light of the recent attacks), but at a high level I feel it is really important to mention there is an effective and deployable mitigation available to CAs, and we are working on taking the next steps to expand the adoption of multiple vantage point validation. P.S. We also wrote a blog about the KLAYswap attack in February of this year that was performed using a similar technique: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/ On Wednesday, October 12, 2022 at 9:01:28 PM UTC-4 [email protected] wrote: > All, > In the article, I saw advice about actions that project owners can take to > protect themselves, but what about things that CAs or root store programs > can or should do? > Ben > > On Thu, Sep 29, 2022 at 12:16 AM Michel Le Bihan <[email protected]> > wrote: > >> Recently there was another case of BGP hijacking where an attacker >> acquired a TLS certificate: >> https://www.coinbase.com/blog/celer-bridge-incident-analysis >> Le mercredi 23 février 2022 à 12:53:37 UTC+1, >> [email protected] a écrit : >> >>> On Tue, Feb 22, 2022 at 2:30 AM Matt Palmer <[email protected]> wrote: >>> >>>> On Mon, Feb 21, 2022 at 06:03:43PM +0100, Matthias van de Meent wrote: >>>> > On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <[email protected]> wrote: >>>> > > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < >>>> [email protected]> wrote: >>>> > >> I know that this has been discussed several years ago, but I >>>> didn't see >>>> > >> any definitive final conclusion. In regards to the recent incident >>>> > >> >>>> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 >>>> > >> that involved the malicious actor reacquiring a valid TLS >>>> certificate, I >>>> > >> think that it might be worth to restart the discussion. >>>> > >> >>>> > >> I know that the recommended solution is RPKI, but should there be >>>> other >>>> > >> solutions that would mitigate this issue when RPKI is not deployed? >>>> > >> >>>> > >> Some possible solutions: >>>> > >> 1. Allow restricting validation methods in CAA records >>>> > >> 2. Require CAs to have multiple vantage points >>>> > >> 3. Not issue certificates shortly after suspicious BGP events >>>> > > >>>> > > I’m not sure I see how 1 addresses this risk by itself. Are you >>>> thinking >>>> > > about this in isolation, or combined with some other mitigations >>>> (like RPKI >>>> > > and DNSSEC)? And, if combining, do we really need 1 to bind the >>>> method, >>>> > > versus something like account binding? >>>> > >>>> > Account binding might not be available for certain CAs. >>>> >>>> Then don't use those certain CAs, and restrict those CAs from issuing >>>> for >>>> your domain by not including them the domain's CAA records. >>>> >>> >>> That assumes that there are CAs that implement RFC8657, and that I trust >>> for my domains, and would issue certificates for my use cases. >>> >>> > I would like it if >>>> > e.g. CAA would also allow for restricting validation methods: >>>> >>>> RFC8657 defines the `validationmethods` parameter to the `issue` and >>>> `issuewild` CAA properties. Again, if a given CA doesn't support those >>>> parameters, you can avoid the problem by not including that CA in your >>>> CAA >>>> records. >>>> >>> >>> Of the roots in the Mozilla root store [0], only one CPS mentions RFC >>> 8657, and that one does not give me any guarantee that it will actually >>> limit issuance to only the verification methods in my CAA record: "Google >>> may choose to limit issuance according to RFC 8657" (i.e. non-conformance >>> to RFC 8657 does not violate their CPS). Additionally, the CPS does not >>> provide validation method identifiers to be used for BR validation methods; >>> so only ACME validation methods are usable (while at the same time useless >>> because there is no ACME endpoint that I could use). >>> >>> CA/B Forum Baseline Requiremets requiring compliance to RFC 8657 would >>> be a great improvement. >>> >>> - Matthias >>> >>> >>> [0] >>> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport, >>> searched each root for CP/CPS queried for "CAA", stopping the search when I >>> find a CP/CPS for that root / CA that contains the Issuer Domain Name. >>> >> -- >> > 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/b84287a6-94bd-450e-aa6b-49c629cae2ddn%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b84287a6-94bd-450e-aa6b-49c629cae2ddn%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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0713099f-18c1-412a-9606-12ddedb18c9dn%40mozilla.org.
