Date: Sat, 06 Jan 2001 23:09:18 -0700 From: Wes Peters <wes@softweyr.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Artem Koutchine <matrix@ipform.ru>, security@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Antisniffer measures (digest of posts) Message-ID: <3A58080E.335DEC57@softweyr.com> References: <Pine.NEB.3.96L.1010106133125.17685E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A58080E.335DEC57>