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:
> 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.
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
Princeton University department of Computer Science
dev-security-policy mailing list