On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote: > It seems that a group of Princeton researchers just presented a live > theoretical* misissuance by Let's Encrypt. > > They did a sub-prefix hijack via a technique other than those I described > here and achieved issuance while passing-through traffic for other > destination within the IP space of the hijacked scope. > > They've got a paper at: > https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf > > I say that theoretical because they hijacked a /24 of their own /23 under a > different ASN but I am given to believe that the "adversarial" ASN is also > under their control or that they had permission to use it. In as far as this > is the case, this technically isn't a misissuance because hijacking ones own > IP space is technically just a different routing configuration diverting the > traffic to the destination they properly control to another point of > interconnection they properly controlled.
Hi, I am Henry Birge-Lee, one of the researchers at Princeton leading that effort. I just performed that live demo a couple hours ago. You are correct about how we performed that attack. One minor detail is that we were forced to use the same ASN twice (for both the adversary and the victim). The adversary and the victim were two different routers peering with completely different ASes, but we were forced to reuse the AS because we were performing the announcements with the PEERING testbed (https://peering.usc.edu/) and are not allowed to announce from another ASN. Thus from a policy point of view this was not a misissuance and our BGP announcements would likely not have triggered an alarm from a BGP monitoring system. Even if we had the ability to hijack another ASes prefix and trigger such alarms we would be hesitant to because of ethical considerations. Our goal was to demonstrate the effectiveness and ease of interception of the technique we used, not freak out network operat ors because of potential hijacks. I know some may argue that had we triggered alarms from the major BGP monitoring frameworks, CAs might not have issued us the certificates the did. We find that this is unlikely because 1) The DV certificate signing process is automated but the type of BGP announcements we made would likely require manual review before they could be definitively flagged as an attack 2) There is no evidence CAs are doing this (we know Let's Encrypt does not use BGP data because of their transparency and conversations with their executive director Josh Aas as well as their engineering team). As for further work, implementation of countermeasures into the CA and Browser forum Baseline Requirements is our eventual goal and we see engaging with this ongoing discussion as a step in the right direction. Over the next couple days I will look over these conversations in more detail and look for ways that we can integrate these ideas into the research we are doing. Best, Henry Birge-Lee Princeton University department of Computer Science _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
