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; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Laszlo Hanyecz <laszlo@heliacal.net>
In-Reply-To: <CAJHLa0NBJo+NFFFZEHNo81KPBwgx05tbuMwtSKMs=07+wCmQgA@mail.gmail.com>
Date: Fri, 8 Aug 2014 18:34:01 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5697066-6389-4F9A-99E6-B815ADB51006@heliacal.net>
References: <CAPS+U9-ze_-gcYh1WNVJ5h8AZ8owoQX=8OUgNcKnaxgvjxZATA@mail.gmail.com>
	<201408072345.45363.luke@dashjr.org>
	<CAJna-HjzMO68KSXYG++X-8vzQCLurkrAAhfrVo9-AbaoYdqZhw@mail.gmail.com>
	<201408080101.16453.luke@dashjr.org>
	<CANEZrP00kRtNxtG9OVOmQLSTZ-MSHSuCe1PniM6v1pnhzz5Jog@mail.gmail.com>
	<CAJHLa0NBJo+NFFFZEHNo81KPBwgx05tbuMwtSKMs=07+wCmQgA@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Miners MiTM
Precedence: list

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 <jgarzik@bitpay.com> 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 <mike@plan99.net> 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