From owner-freebsd-security@FreeBSD.ORG Tue Jun 26 07:24:42 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B335E106564A for ; Tue, 26 Jun 2012 07:24:42 +0000 (UTC) (envelope-from andy@brodnik.org) Received: from svarun.brodnik.org (www.brodnik.org [193.77.156.167]) by mx1.freebsd.org (Postfix) with ESMTP id 69FE68FC14 for ; Tue, 26 Jun 2012 07:24:42 +0000 (UTC) Received: from [192.168.127.8] (AndyAir.gotska.brodnik.org [192.168.127.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by svarun.brodnik.org (Postfix) with ESMTPSA id E5B914AC07 for ; Tue, 26 Jun 2012 09:12:27 +0200 (CEST) Message-ID: <4FE96172.6090109@brodnik.org> Date: Tue, 26 Jun 2012 09:14:58 +0200 From: "Andrej (Andy) Brodnik" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <86pq8nxtjp.fsf@ds4.des.no> <20120625223807.4dbeb91d@gumby.homeunix.com> <4FE8DF29.50406@FreeBSD.org> <20120625235310.3eed966e@gumby.homeunix.com> <4FE8F814.5020906@FreeBSD.org> <20120626015323.02b7f348@gumby.homeunix.com> <4FE9094A.4080605@FreeBSD.org> <20120626024624.4c333bd2@gumby.homeunix.com> <4FE916AA.6050503@FreeBSD.org> <20120626035609.0d0f061b@gumby.homeunix.com> <20120626034727.GA56503@DataIX.net> In-Reply-To: <20120626034727.GA56503@DataIX.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 26 Jun 2012 11:23:23 +0000 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: Tue, 26 Jun 2012 07:24:42 -0000 Dne 6/26/12 5:47 AM, piše J. Hellenthal: > > On Tue, Jun 26, 2012 at 03:56:09AM +0100, RW wrote: >> On Mon, 25 Jun 2012 18:55:54 -0700 >> Doug Barton wrote: >> >> >>>>> My point is that the ssh protocol is designed specifically to >>>>> prevent what you're describing. >>>> If you've obtained the server's private key by breaking the public >>>> key you can accept connections from clients just as if you are are >>>> the real server. >>> Right. That's what Dag-Erling and I have been saying all along. If you >>> have the private host key you can impersonate the server. That's not a >>> MITM attack. That's impersonating the server. >> If only the server is authenticated, then impersonating the >> server is the only impediment to a MITM attack (aside from >> intercepting the netwok traffic). If the server has client keys then >> obviously it wont work. >> >>>> If the server doesn't store client keys then there's >>>> nothing to stop you establishing a separate connection with any >>>> client side key and performing a MITM attack. >>> Last chance ... how, precisely, do you claim to be able to do this? >> What's to stop you doing it where there's no authentication of clients? >> All the attacker needs to do is establish an ssh connection to the >> server and relay what he's getting from the original client. The >> situation is analogous to performing a MITM attack against a website >> where the ssl keys have been stolen by the attacker. > Client -> FakeSSHD -> RealHOST > > If FakeSSHD has RealHOST's ssh_host_*_key's then they are able to > impersonate RealHOST and prompt for a password that no matter wether it > is correct will just silently drop all further traffic and relay to the > RealHOST in which they never realize the difference while the operator > of FakeSSHD now has a password for RealHOST from the user. The user > would not be the wiser to just think there is something wrong in their > environment or the servers environment and will be left clueless. > > Still have yet to hear of something like this happening but its real > enough considering some of the exploits out there. > > But this is all way to far beyond what this thread is supposed to be > about and beyond the scope of FreeBSD entirely so lets just let it drop > or pick it up on FD. However, in the above scenario, the RealHOST will answer using Client's public key which FakeSSHD will not be able to understand without having Client's private key. LPA (== {Lep pozdrav! Andrej}_{Slovene} == {Best Regards, Andrej})