From owner-freebsd-security@FreeBSD.ORG Mon Jun 25 23:45:25 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 66CBD1065672 for ; Mon, 25 Jun 2012 23:45:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0264914E231; Mon, 25 Jun 2012 23:45:24 +0000 (UTC) Message-ID: <4FE8F814.5020906@FreeBSD.org> Date: Mon, 25 Jun 2012 16:45:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: RW References: <86zk7sxvc3.fsf@ds4.des.no> <20120625023104.2a0c7627@gumby.homeunix.com> <86pq8nxtjp.fsf@ds4.des.no> <20120625223807.4dbeb91d@gumby.homeunix.com> <4FE8DF29.50406@FreeBSD.org> <20120625235310.3eed966e@gumby.homeunix.com> In-Reply-To: <20120625235310.3eed966e@gumby.homeunix.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: Hardware potential to duplicate existing host keys... RSA DSA ECDSA was Add rc.conf variables... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:45:25 -0000 On 06/25/2012 15:53, RW wrote: > On Mon, 25 Jun 2012 14:59:05 -0700 > Doug Barton wrote: > >>>> Having a copy of the host key allows you to do one thing and one >>>> thing only: impersonate the server. It does not allow you to >>>> eavesdrop on an already-established connection. >>> >>> It enables you to eavesdrop on new connections, >> >> Can you describe the mechanism used to do this? > > Through a MITM attack if nothing else Sorry, I wasn't clear. Please describe, in precise, reproducible terms, how one would accomplish this. Or, link to known script-kiddie resources ... whatever. My point being, I'm pretty confident that what you're asserting isn't true. But if I'm wrong, I'd like to learn why. >>> and eavesdroppers >>> are often in a position to force reconnection on old ones. >> >> If you can get on the network link between the client and the host, >> yes, you can force an existing connection to drop. But that doesn't >> require the host's secret key. > > I didn't say it did, I was referring to the statement: "It does not > allow you to eavesdrop on an already-established connection." So, correct, but irrelevant. >>>> If the server is set up to require key-based user authentication, >>>> an attacker would also have to obtain the user's key to mount an >>>> effective man-in-the-middle attack. >>> >>> If an attacker is only interested in a specific client, it may not >>> be any harder to break the second public key, than the first one. >> >> Well that's just plain nonsense. The moon "may" be made of green >> cheese. > > It depends on the nature of the attack, but the possibility that two > arbitrary keys are of similar strength under a specific attack is not > on a par with the moon being made of cheese. Again, correct, but irrelevant. Doug -- This .signature sanitized for your protection