blob: 7b0c42aa687d506ae22c4906f147fde37fdd3e43 (
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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1WJdNm-0005h8-1a
for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 06:26:46 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1WJdNl-0007DV-9u for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 06:26:46 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co
; Fri, 28 Feb 2014 22:26:56 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Date: Fri, 28 Feb 2014 22:26:39 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xb05iptvyldrnw@laptop-air>
User-Agent: Opera Mail/1.0 (Win32)
X-Spam-Score: -1.6 (-)
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.0 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: 1WJdNl-0007DV-9u
Subject: [Bitcoin-development] Positive and negative feedback on certificate
validation errors
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: Sat, 01 Mar 2014 06:26:46 -0000
We currently have subtle positive feedback of a signed payment request in
the form of the green background. Unsigned requests simply show up without
the green background, as well as requests which provide a certificate but
have a missing or invalid signature.
There's a open bug (#3628) and pull request (#3684) to provide negative
feedback (yellow background) for a missing or invalid signature, but it
seems like there's some debate on whether bitcoind should do that...
If an attacker can avoid the negative feedback by just stripping the
signature and setting pki_type to none, then arguably there's no security
benefit by singling out badly signed payment requests from unsigned
payment requests.
So perhaps the root problem is that the positive feedback (green
background) is not strong enough to make its absence highly conspicuous to
the end user.
As an aside, how could we go about implementing the equivalent of HTTP
Strict Transport Security for payment protocol to prevent this trivial
signature stripping attack? Is this a possible extension field merchants
are interested in?
|
