Dimitris, I think it is not accurate to characterize this as being outside of the CAs controls. Several CAs utilize multiple network perspectives and consensus to mitigate these risks. While this is not a total solution it is fairly effective if the consensus pool is well thought out.
Ryan On Thursday, August 24, 2017 at 5:45:11 AM UTC-7, Dimitris Zacharopoulos wrote: > On 26/7/2017 3:38 πμ, Matthew Hardeman via dev-security-policy wrote: > > On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5,birg...@princeton.edu wrote: > >> We have been considering research in this direction. PEERING controls > >> several ASNs and may let us use them more liberally with some convincing. > >> We also have the ASN from Princeton that could be used with cooperation > >> from Princeton OIT (the Office of Information Technology) where we have > >> several contracts. The problem is not the source of the ASNs but the > >> network anomaly the announcement would cause. If we were to hijack the > >> prefix of a cooperating organization, the PEERING ASes might have their > >> announcements filtered because they are seemingly launching BGP attacks. > >> This could be fixed with some communication with ISPs, but regardless > >> there is a cost to launching such realistic attacks. Matthew Hardeman > >> would probably know more detail about how this would be received by the > >> community, but this is the general impression I have got from engaging > >> with the people who run the PEERING framework. > > I have some thoughts on how to perform such experiments while mitigating > > the likelihood of significant lasting consequence to the party helping > > ingress the hijack to the routing table, but you correctly point out that > > the attack surface is large and the one consistent feature of all > > discussion up to this point on the topic of BGP hijacks for purpose of > > countering CA domain validation is that none of those discuss have, up to > > this point, expressed doubt as to the risks or the feasibility of carrying > > out these risks. To that ends, I think the first case that would need to > > be made to further that research is whether anything of significance is > > gained in making the attack more tangible. > > > >> So far we have not been working on such an attack very much because we are > >> focusing our research more on countermeasures. We believe that the attack > >> surface is large and there are countless BGP tricks an adversary could use > >> to get the desired properties in an attack. We are focusing our research > >> on simple and countermeasures CAs can implement to reduce this attack > >> space. We also aim to use industry contacts to accurately asses the false > >> positive rates of our countermeasures and develop example implementations. > >> > >> If it appears that actually launching such a realistic attack would be > >> valuable to the community, we certainty could look into it further. > > This is the question to answer before performing such an attack. In > > effect, who is the audience that needs to be impressed? What criteria must > > be met to impress that audience? What benefits in furtherance of the work > > arise from impressing that audience? > > > > Thanks, > > > > Matt Hardeman > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > That was a very interesting topic to read. Unfortunately, CAs can't do > much to protect against network hijacking because most of the > counter-measures lie in the ISPs' side. However, the CAs could request > some counter-measures from their ISPs. > > Best practices for ISPs state that for each connected peer, the ISP need > to apply a prefix filter that will allow announcements for only > legitimate prefixes that the peer controls/owns. We can easily imagine > that this is not performed by all ISPs. Another solution that has been > around for some time, is RPKI > <https://www.ripe.net/manage-ips-and-asns/resource-management/certification> > along with BGP Origin Validation > <https://www.ripe.net/manage-ips-and-asns/resource-management/certification/bgp-origin-validation>. > > Of course, we can't expect all ISPs to check for Route Origin > Authorizations (ROAs) but if the major ISPs checked for ROAs, it would > improve things a lot in terms of securing the Internet. > > So, in order to minimize the risk for a CA or a site owner network from > being hijacked, if a CA/site owner has an address space that is Provider > Aggregatable (PA) (this means the ISP "owns" the IP space), they should > check that their upstream network provider has properly created the ROAs > for the CA/site operator's network prefix(es) in the RIR authorized > list, and that they have configured their routers to validate ROAs for > each prefix. If the CA/site operator has a Provider Independent (PI) > address space (this means the CA/site operator "owns" the IP space), > then the CA/site operator should create the ROAs. > > In Matt's example, if eff.org had ROAs for their network prefixes (that > include their DNS servers) and if Let's Encrypt provider (or Let's > Encrypt router) was validating ROAs, this attack wouldn't work. > > > Dimitris. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
