Hi Michel, You are correct that it is possible for an attack to propagate to the vast majority of the Internet (I hesitate to say 100% as there are usually some clients using a particular route) and sub-prefix attacks (where the adversary announces a more-specific prefix than the victim) are a good example of this. That said, I think it is important to mention that sub-prefix attacks are becoming increasingly less viable as more and more of the route table is secured with RPKI. Let’s Encrypt’s vantage points all perform Route Origin Validation (or ROV where routes are filtered based on RPKI data) and the major cloud providers we see hosting TLS domains have published Route Origin Authorizations (or ROAs, cryptographic authorizations of IP prefix length and origin AS): Amazon, Azure, ClouFlare, Google, OVH to name a few (see https://isbgpsafeyet.com/). RPKI prevents sub-prefix attacks because it specifies not only the proper origin ASN for IP prefixes but also the length of the IP prefix that can be announced in the route table. Thus, sub-prefix attacks are filtered by ROV (which is deployed by Let's Encrypt).
Furthermore, sub-prefix attacks are very easy to detect with BGP monitoring both because of their global propagation (meaning they propagate to pretty much any monitoring node) and because of their distinctive signal in the BGP feed. As for equally-specific prefix attacks, affecting the entire Internet is extremely difficult which is what we demonstrated with our Internet topology simulations and resilience calculations. An equally-specific prefix attack can be thought of as competing for traffic with the victim's own announcement, and the result is that nodes topologically closer to the victim tend to prefer the victim's route and vice versa. We modeled millions of equally-specific attacks to see how many of them multiple vantage point validation could detect, and Let's Encrypt's current deployment was able to detect the vast majority (94%) of them. The attacks that were missed could be detected simply by adding more vantage points. I think the overall takeaway is that because of the dynamics of BGP routing and continually improving routing security measures, actually launching an attack that affects the entire Internet is extremely difficult. Furthermore, multiple vantage point validation synergies very well with what is happening in the world of BGP, as sub-prefix attacks are much easier to address with BGP security measures than equally-specific prefix attacks. Feel free to reach out if you have any more questions. Best, Henry P.S. We are working on some really interesting new results looking at the interaction of multiple vantage point validation and RPKI which we are hoping to publish in a conference paper coming up. On Sat, Oct 22, 2022 at 6:56 AM Michel Le Bihan < [email protected]> wrote: > 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/CAGxVKU7_fJqa__oHfyzOR1ZWmX1Te51m4CHTkK0q2rRSG5KtOw%40mail.gmail.com.
