From owner-freebsd-questions Sat Jan 6 22: 3:27 2001 Delivered-To: freebsd-questions@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B45D337B400; Sat, 6 Jan 2001 22:03:06 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14F914-0000MW-00; Sat, 06 Jan 2001 23:09:18 -0700 Message-ID: <3A58080E.335DEC57@softweyr.com> Date: Sat, 06 Jan 2001 23:09:18 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Artem Koutchine , security@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Antisniffer measures (digest of posts) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > 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. Or just provide us with a really good telnet-over-SSL client. An excellent summary, Robert. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message