summaryrefslogtreecommitdiff
path: root/ef/ebd88371e9011a838d42267d70960be4c72dc3
blob: af0577ef844a50326f997f28c3fc2f9b1f338b6c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1XFgrb-000783-8P
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 Aug 2014 09:53:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.48 as permitted sender)
	client-ip=209.85.218.48; envelope-from=mh.in.england@gmail.com;
	helo=mail-oi0-f48.google.com; 
Received: from mail-oi0-f48.google.com ([209.85.218.48])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XFgra-0002HV-F1
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 Aug 2014 09:53:31 +0000
Received: by mail-oi0-f48.google.com with SMTP id h136so3499930oig.35
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 Aug 2014 02:53:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.210.195 with SMTP id mw3mr1555351obc.82.1407491604939;
	Fri, 08 Aug 2014 02:53:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Fri, 8 Aug 2014 02:53:24 -0700 (PDT)
In-Reply-To: <201408080101.16453.luke@dashjr.org>
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>
Date: Fri, 8 Aug 2014 11:53:24 +0200
X-Google-Sender-Auth: w5QC-f1vvC_mQMqI1x3fgqWhra4
Message-ID: <CANEZrP00kRtNxtG9OVOmQLSTZ-MSHSuCe1PniM6v1pnhzz5Jog@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11c2a022230b5805001b2da5
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1XFgra-0002HV-F1
Cc: "bitcoin-development@lists.sourceforge.net"
	<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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 09:53:31 -0000

--001a11c2a022230b5805001b2da5
Content-Type: text/plain; charset=UTF-8

>
> 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.
>

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?

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.

--001a11c2a022230b5805001b2da5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">Certificate validation isn&#39;t=
 needed unless the attacker can do a direct MITM<br>
</div>
at connection time, which is a lot harder to maintain than injecting a<br>
client.reconnect.<br></blockquote><div><br></div><div>Surely the TCP connec=
tion will be reset once the route reconfiguration is completed, either by t=
he MITM server or by the client TCP stack when it discovers the server does=
n&#39;t know about the connection anymore?=C2=A0</div>
<div><br></div><div>TLS without cert validation defeats the point, you can =
still be connected to a MITM at any point by anyone who can simply interrup=
t or corrupt the stream, forcing a reconnect.</div></div></div></div>

--001a11c2a022230b5805001b2da5--