From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XFpHt-0007PG-0E for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 18:53:13 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of heliacal.net designates 91.234.48.203 as permitted sender) client-ip=91.234.48.203; envelope-from=laszlo@heliacal.net; helo=mail3.heliacal.net; Received: from mail3.heliacal.net ([91.234.48.203]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XFpHr-0001qm-Jz for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 18:53:12 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Laszlo Hanyecz In-Reply-To: Date: Fri, 8 Aug 2014 18:34:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201408072345.45363.luke@dashjr.org> <201408080101.16453.luke@dashjr.org> To: Jeff Garzik X-Mailer: Apple Mail (2.1510) X-Spam-Score: -2.3 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XFpHr-0001qm-Jz Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Miners MiTM X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:53:13 -0000 Mutual CHAP could work. This is commonly done in PPP and iSCSI. The = idea is simply that both sides authenticate. The server expects the = client to provide a password, and the client expects the server to = provide a (different) password. If you masquerade as the server, you = won't be able to authenticate because every client has a different = password they expect from the server, so they won't do work for you. = MITM on the server can capture the exchange but CHAP protects against = replay. = https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol -Laszlo On Aug 8, 2014, at 6:21 PM, Jeff Garzik wrote: > gmaxwell noted on IRC that enabling TLS could be functionally, if not > literally, a DoS on the pool servers. Hence the thought towards a > more lightweight method that simply prevents client payout redirection > + server impersonation. >=20 >=20 > On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn wrote: >>> Certificate validation isn't needed unless the attacker can do a = direct >>> MITM >>> at connection time, which is a lot harder to maintain than injecting = a >>> client.reconnect. >>=20 >>=20 >> Surely the TCP connection will be reset once the route = reconfiguration is >> completed, either by the MITM server or by the client TCP stack when = it >> discovers the server doesn't know about the connection anymore? >>=20 >> TLS without cert validation defeats the point, you can still be = connected to >> a MITM at any point by anyone who can simply interrupt or corrupt the >> stream, forcing a reconnect. >>=20 >> = --------------------------------------------------------------------------= ---- >> Want fast and easy access to all the code in your enterprise? Index = and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>=20 >=20 >=20 >=20 > --=20 > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ >=20 > = --------------------------------------------------------------------------= ---- > Want fast and easy access to all the code in your enterprise? Index = and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development