/ ef / ebd88371e9011a838d42267d70960be4c72dc3
ebd88371e9011a838d42267d70960be4c72dc3
  1  Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
  2  	helo=mx.sourceforge.net)
  3  	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
  4  	(envelope-from <mh.in.england@gmail.com>) id 1XFgrb-000783-8P
  5  	for bitcoin-development@lists.sourceforge.net;
  6  	Fri, 08 Aug 2014 09:53:31 +0000
  7  Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
  8  	designates 209.85.218.48 as permitted sender)
  9  	client-ip=209.85.218.48; envelope-from=mh.in.england@gmail.com;
 10  	helo=mail-oi0-f48.google.com; 
 11  Received: from mail-oi0-f48.google.com ([209.85.218.48])
 12  	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
 13  	(Exim 4.76) id 1XFgra-0002HV-F1
 14  	for bitcoin-development@lists.sourceforge.net;
 15  	Fri, 08 Aug 2014 09:53:31 +0000
 16  Received: by mail-oi0-f48.google.com with SMTP id h136so3499930oig.35
 17  	for <bitcoin-development@lists.sourceforge.net>;
 18  	Fri, 08 Aug 2014 02:53:24 -0700 (PDT)
 19  MIME-Version: 1.0
 20  X-Received: by 10.182.210.195 with SMTP id mw3mr1555351obc.82.1407491604939;
 21  	Fri, 08 Aug 2014 02:53:24 -0700 (PDT)
 22  Sender: mh.in.england@gmail.com
 23  Received: by 10.76.35.234 with HTTP; Fri, 8 Aug 2014 02:53:24 -0700 (PDT)
 24  In-Reply-To: <201408080101.16453.luke@dashjr.org>
 25  References: <CAPS+U9-ze_-gcYh1WNVJ5h8AZ8owoQX=8OUgNcKnaxgvjxZATA@mail.gmail.com>
 26  	<201408072345.45363.luke@dashjr.org>
 27  	<CAJna-HjzMO68KSXYG++X-8vzQCLurkrAAhfrVo9-AbaoYdqZhw@mail.gmail.com>
 28  	<201408080101.16453.luke@dashjr.org>
 29  Date: Fri, 8 Aug 2014 11:53:24 +0200
 30  X-Google-Sender-Auth: w5QC-f1vvC_mQMqI1x3fgqWhra4
 31  Message-ID: <CANEZrP00kRtNxtG9OVOmQLSTZ-MSHSuCe1PniM6v1pnhzz5Jog@mail.gmail.com>
 32  From: Mike Hearn <mike@plan99.net>
 33  To: Luke Dashjr <luke@dashjr.org>
 34  Content-Type: multipart/alternative; boundary=001a11c2a022230b5805001b2da5
 35  X-Spam-Score: -0.5 (/)
 36  X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
 37  	See http://spamassassin.org/tag/ for more details.
 38  	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
 39  	sender-domain
 40  	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 41  	(mh.in.england[at]gmail.com)
 42  	-0.0 SPF_PASS               SPF: sender matches SPF record
 43  	1.0 HTML_MESSAGE           BODY: HTML included in message
 44  	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
 45  	not necessarily valid
 46  	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
 47  X-Headers-End: 1XFgra-0002HV-F1
 48  Cc: "bitcoin-development@lists.sourceforge.net"
 49  	<bitcoin-development@lists.sourceforge.net>
 50  Subject: Re: [Bitcoin-development] Miners MiTM
 51  X-BeenThere: bitcoin-development@lists.sourceforge.net
 52  X-Mailman-Version: 2.1.9
 53  Precedence: list
 54  List-Id: <bitcoin-development.lists.sourceforge.net>
 55  List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
 56  	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
 57  List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
 58  List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
 59  List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
 60  List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
 61  	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
 62  X-List-Received-Date: Fri, 08 Aug 2014 09:53:31 -0000
 63  
 64  --001a11c2a022230b5805001b2da5
 65  Content-Type: text/plain; charset=UTF-8
 66  
 67  >
 68  > Certificate validation isn't needed unless the attacker can do a direct
 69  > MITM
 70  > at connection time, which is a lot harder to maintain than injecting a
 71  > client.reconnect.
 72  >
 73  
 74  Surely the TCP connection will be reset once the route reconfiguration is
 75  completed, either by the MITM server or by the client TCP stack when it
 76  discovers the server doesn't know about the connection anymore?
 77  
 78  TLS without cert validation defeats the point, you can still be connected
 79  to a MITM at any point by anyone who can simply interrupt or corrupt the
 80  stream, forcing a reconnect.
 81  
 82  --001a11c2a022230b5805001b2da5
 83  Content-Type: text/html; charset=UTF-8
 84  Content-Transfer-Encoding: quoted-printable
 85  
 86  <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
 87  ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
 88  cc solid;padding-left:1ex"><div class=3D"">Certificate validation isn&#39;t=
 89   needed unless the attacker can do a direct MITM<br>
 90  </div>
 91  at connection time, which is a lot harder to maintain than injecting a<br>
 92  client.reconnect.<br></blockquote><div><br></div><div>Surely the TCP connec=
 93  tion will be reset once the route reconfiguration is completed, either by t=
 94  he MITM server or by the client TCP stack when it discovers the server does=
 95  n&#39;t know about the connection anymore?=C2=A0</div>
 96  <div><br></div><div>TLS without cert validation defeats the point, you can =
 97  still be connected to a MITM at any point by anyone who can simply interrup=
 98  t or corrupt the stream, forcing a reconnect.</div></div></div></div>
 99  
100  --001a11c2a022230b5805001b2da5--
101  
102