Date: Sat, 6 Jan 2001 13:41:54 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Wes Peters <wes@softweyr.com> Cc: Artem Koutchine <matrix@ipform.ru>, security@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Antisniffer measures (digest of posts) Message-ID: <Pine.NEB.3.96L.1010106133125.17685E-100000@fledge.watson.org> In-Reply-To: <3A56ABF8.90C9F0D8@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm going to reply to Wes's message, but not necessarily specifically in response to his comments. I haven't had a chance to read all the messages in the thread yet, as I'm still catching up on back e-mail from my travel, but had a few comments to make that might or might not be relevant: - Ethernet switches generally don't help with sniffing problems, even with hard-coded MAC addresses, as they only provide link-layer protection. As has been pointed out, a variety of ARP-layer, IP-layer, and application-layer tricks can be employed to overcome link-layer switch limitations, including ARP spoofing, IP redirects and router message spoofing, in addition to DNS spoofing. - Limitations in SSH stem from the lack of an automated certification process, and from some clients that don't provide an interface for managing public key introduction or inconsistency reporting. In addition, all SSH clients I've used have problems differentiating service and transport namespaces, meaning that they are vulnerable to a variety of DNS and IP-spoofing based attacks. Most of these attacks can be addressed by integrating some form of certification into SSH (manual or automatic) using a signing or certificate mechanism, such as PGP-signed key fingerprints, integration into X.509 or DNSSEC cert hierarchies, or a key distribution service. However, the lack of a well-defined name->key binding mechanism presents a number of problems that must be resolved. I know of ongoing work to integrate DNSsec and OpenSSH at NAI Labs and (I believe) ISI. I assume other work has been done relating to X.509, but haven't seen it if so. The statements that the well-known dsniff man-in-the-middle attack stems entirely from user error is probably not correct -- clients don't provide even minimal key management functionality, many not even displaying fingerprints for new keys introduced, or not making correct use of name/IP->key mappings. That said, users who are careful and understand the implications of keying decisions made when using SSH will be safe from these attacks. End-to-end encryption is probably the answer to the problems seen by this user -- however, FreeBSD has relatively poor IPsec integration due to lack of IKE in the base system, making configuration and management of IPsec somewhat of a nightmare. And without DNSsec, DNS spoofing can provide a number of avenues for attack even with IPsec (especially if NFS is used). If you limit use of network protocols to properly pre-keyed and certified SSH and anonymous services (such as http), you should be fine in practice. Kerberos can also provide relatively comprehensive protection, if configured correctly and with integrity/privacy protection turned on when appropriate. For those seeking to remedy these problems, you might consider what would be involved in adding X.509 certificate support to SSH in the style of SSL, working with the OpenSSL project to provide an improved crypto-API with better algorithm abstractions, as well as work to improve the quality and integration of DNSsec implementations to help with deployment. Similarly, work to help the KAME project get their IKE daemon into production-quality condition would probably be widely welcomed and appreciated. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010106133125.17685E-100000>