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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Y9ndD-0007Tj-6t
for bitcoin-development@lists.sourceforge.net;
Sat, 10 Jan 2015 04:26:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y9ndA-0005A5-3W
for bitcoin-development@lists.sourceforge.net;
Sat, 10 Jan 2015 04:26:35 +0000
Received: by mail-ie0-f172.google.com with SMTP id tr6so18348007ieb.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Jan 2015 20:26:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.138.5 with SMTP id m5mr18409284iod.85.1420863983358;
Fri, 09 Jan 2015 20:26:23 -0800 (PST)
Received: by 10.107.16.30 with HTTP; Fri, 9 Jan 2015 20:26:23 -0800 (PST)
Date: Sat, 10 Jan 2015 04:26:23 +0000
Message-ID: <CAAS2fgR2a+3wb+He611pxy_Ypur0gq+o7SRjUHa4-R+xHLLnyA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Y9ndA-0005A5-3W
Subject: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible,
causes blockchain rejection.
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, 10 Jan 2015 04:26:35 -0000
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers. My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.
Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are any built with the gitian deterministic build system.
If you are running third-party or self-compiled Bitcoin Core
or an alternative implementation using OpenSSL you must not
update OpenSSL or must run a Bitcoin software containing a
workaround:
https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
(versions of this will be backported to other stable branches soon)
The tests included with Bitcoin Core in the test_bitcoin
utility already detect this condition and fail. (_Do not ignore or
disable the tests in order to run or distribute software
which fails_)
The incompatibility is due to the OpenSSL update changing the
behavior of ECDSA validation to reject any signature which is
not encoded in a very rigid manner. This was a result of
OpenSSL's change for CVE-2014-8275 "Certificate fingerprints
can be modified".
While for most applications it is generally acceptable to eagerly
reject some signatures, Bitcoin is a consensus system where all
participants must generally agree on the exact validity or
invalidity of the input data. In a sense, consistency is more
important than "correctness".
As a result, an uncontrolled 'fix' can constitute a security
vulnerability for the Bitcoin system. The Bitcoin Core developers
have been aware of this class of risk for a long time and have
taken measures to mitigate it generally; e.g., shipping static
binaries, internalizing the Leveldb library... etc.
It was somewhat surprising, however, to see this kind of change show
up as a "low" priority fix in a security update and pushed out live
onto large numbers of systems within hours.
We were specifically aware of potential hard-forks due to signature
encoding handling and had been hoping to close them via BIP62 in 0.10.
BIP62's purpose is to improve transaction malleability handling and
as a side effect rigidly defines the encoding for signatures, but the
overall scope of BIP62 has made it take longer than we'd like to
deploy.
(Coincidentally, I wrote about this concern and our unique demands on
cryptographic software as part of a comment on Reddit shortly before
discovering that part of this OpenSSL update was actually
incompatible with Bitcoin:
https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/cnitbz3
)
The patches above, however, only fix one symptom of the general
problem: relying on software not designed or distributed for
consensus use (in particular OpenSSL) for consensus-normative
behavior. Therefore, as an incremental improvement, I propose
a targeted soft-fork to enforce strict DER compliance soon,
utilizing a subset of BIP62.
Adding a blockchain rule for strict DER will reduce the risk of
consensus inconsistencies from alternative implementations of
signature parsing or signature verification, simplify BIP62,
and better isolate the cryptographic validation code from the
consensus algorithm. A failure to do so will likely leave us
in this situation, or possibly worse, again in the future.
The relevant incompatible transactions are already non-standard on
the network since 0.8.0's release in February 2013, although there
was seemingly a single miner still mining incompatible transactions.
That miner has been contacted and has fixed their software, so a
soft-fork with no chain forking should be possible.
|
