On Oct 17, 2013, at 7:58 AM, Stephen Kent <[email protected]> wrote: >> Capability wise, there is nothing except cryptographic data integrity that >> prevents an eavesdropper from injecting their own traffic. On HTTP, this >> enables redirecting the browser to an arbitrary site (for exploitation), >> extracting any not-SSL-only cookies, injecting arbitrary code at the end of >> a web page, etc. Absent DNSSEC validation on the part of the victim, DNS >> injection allows the attacker to MITM any connection.
> The ability to effect active and passive attacks is not uniform, and often > not equivalent, > at least not on a per link basis. An attacker may be able to listen to a > satellite down link or > a fiber cable, but not be able to inject packets into these links. Thanks to an ability to spoof packets from a gazillion different locations, as long as they can inject a spoofed packet from ANOTHER link in time, they will still be able to do packet injection. The attacker's point of injection needs to be closer (latency wise) on the network than the final destination of the packet, but thats usually a pretty easy constraint to meet. > So it is not quite accurate > to assert that any adversary who can passively monitor (a link) can also > engage in active attacks > (on that link). The general form of active attacks that we usually assume in > IETF security assesments > are MITM, which may be very hard to effect, depending on the context. If you are assuming MITM on a packet level rather than just an eavesdropper (man on the side), then it really is a full-active attack is just a matter of willingness to do so, since a full MitM can drop packets as well. >> Similarly, at layer 2, absent significant protection in the switch, properly >> configured, both DHCP and ARP injection allows similar total hijacking. >> There are no capability limitations of note for a "passive" eavesdropper who >> wants to become active. > What constitutes "significant protection?" Configurations like this: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?sp4ts.oid=1827663&spf_p.tpst=kbDocDisplay&spf_p.prp_kbDocDisplay=wsrp-navigationalState%3DdocId%253Demr_na-c02609533-1%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken for ARP, and similar configurations for DHCP. For the wireless "LAN", the problem is even worse, unless you deploy something like this: meraki.cisco.com/lib/pdf/meraki_datasheet_airmarshal.pdf you have to assume that the attackers can do all sorts of fun things if they know the password/can authenticate, such as spoofing an AP and relaying traffic. For both cases, this requires reasonably high end switches and almost invariably require that they be properly configured. Thus it is foolish to assume, in developing and deploying protocols, that the network does NOT suffer from man-in-the-middle attackers, even when you are "just in the LAN". >> Thus it really is "will" as convenient shorthand: is the attacker willing to >> use this and chance getting caught if a subtle detector is actually looking >> for the signs of attack? > I think it is more than just a concern re being detected. Why? Since its clear that there aren't technical limitations on an eavesdropper becoming a full MitM in most cases, its really is only "does becoming a full MitM benefit me as an attacker vs any increased risk of detection". > When you mention integrity do you mean integrity w/o authentication? To me > that's reminiscent of > the Rocky and Bullwinkle ad cut-away about fan mail from a flounder. If a > bottle containing a note > were securely sealed, then one might assume that it was afforded integrity. > But without authentication, > we don't know which flounder sent the note, which seems unsatisfying. > Integrity w/o authentication > is MUCH easier than authenticated integrity, but I worry that folks will > misinterpret the security > they're getting, with unfortunate results. You need full authentication of all data and communication, so sorry for being unclear. -- Nicholas Weaver it is a tale, told by an idiot, [email protected] full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
