Hi Henry Birge-Lee, I found your USENIX presentation very interesting. However, I don't quite understand the example of the real world attack. In the graphic it seems that the malicious announcement propagated to about 50% of the internet. Will a malicous announcement stop propagating at some point and reach x% or could it reach around 100% if for example it is a more specific prefix? Le vendredi 14 octobre 2022 à 23:58:29 UTC+2, Henry Birge-Lee a écrit :
> 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/21219ee6-0437-450b-8715-1206c6bd8ac0n%40mozilla.org.
