[Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Gregory Maxwell]

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.

Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On Sat, Jan 10, 2015 at 04:26:23AM +0000, Gregory Maxwell wrote:
> 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 an aside, it's interesting to note that this issue is not entirely
unique to miners.

For example in micropayment channel protocols the receiver must validate
signatures from the sender to ensure that they will be able to broadcast
transactions containing those signatures in the near-future. If they
accept a signature as valid that the majority of hashing power rejects
as invalid the sender can simply wait until the micropayment channel
timeout expires to recover 100% of their funds, ripping off the
receiver. There's many other advanced Bitcoin protocols with similar
vulnerabilities; I'd be interested to hear if anyone can come up with a
similar vulnerability in a non-Bitcoin protocol, and wouldn't be that
surprised if they did.

While I have often cautioned people before to avoid using libsecp256k1
for verification on the grounds that consensus trumps correctness, the
above incompatibility does strongly suggest that OpenSSL may not itself
have very good consensus-critical design. Along with Maxwell and
Wuille's recent findings¹ CVE-2014-3570 - strong evidence of the
excellent testing the library has undergone - I personally am now of the
opinion that migrating Bitcoin Core to libsecp256k1 in the near future
is a good idea on the grounds that it provides us with a well-written,
and well-understood library designed with consensus in mind that'll
probably give us fewer consensus problems than our existing OpenSSL
dependency. It'll also help advanced protocol implementations by giving
them a clear dependency to use when they need consensus-critical
signature evaluation.

1) https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/

-- 
'peter'[:-1]@petertodd.org
000000000000003b82d8644b56c846e7497118b04a6ec68d3e0a23d33323b82e

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Wladimir]

On Sat, Jan 10, 2015 at 4:26 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
> (versions of this will be backported to other stable branches soon)

For those that build from source, patches to cope with the new OpenSSL
versions are now available on stable branches 0.8, 0.9 and rc branch
0.10:

0.8 branch (on top of 0.8.6)
========================
https://github.com/bitcoin/bitcoin/tree/0.8
https://github.com/bitcoin/bitcoin/commits/0.8

To fetch, build, and test:
```
git clone -b 0.8 https://github.com/bitcoin/bitcoin.git bitcoin-0.8
cd bitcoin-0.8/src
make -f makefile.unix
make -f makefile.unix check
```

0.9 branch (on top of 0.9.3+)
========================
https://github.com/bitcoin/bitcoin/tree/0.9
https://github.com/bitcoin/bitcoin/commits/0.9

To fetch, build, and test:
```
git clone -b 0.9 https://github.com/bitcoin/bitcoin.git bitcoin-0.9
cd bitcoin-0.9/src
./autogen.sh
./configure
make
make check
```

0.10 branch (on top of 0.10.0rc1+)
========================
https://github.com/bitcoin/bitcoin/tree/0.10
https://github.com/bitcoin/bitcoin/commits/0.10

```
git clone -b 0.10 https://github.com/bitcoin/bitcoin.git bitcoin-0.10
cd bitcoin-0.10/src
./autogen.sh
./configure
make
make check
```

Wladimir

Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Ivan Jelincic]

Is openssl1.0.1j unaffected?

On 01/10/2015 09:35 AM, Wladimir wrote:
> On Sat, Jan 10, 2015 at 4:26 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>> https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
>> (versions of this will be backported to other stable branches soon)
> For those that build from source, patches to cope with the new OpenSSL
> versions are now available on stable branches 0.8, 0.9 and rc branch
> 0.10:
>
> 0.8 branch (on top of 0.8.6)
> ========================
> https://github.com/bitcoin/bitcoin/tree/0.8
> https://github.com/bitcoin/bitcoin/commits/0.8
>
> To fetch, build, and test:
> ```
> git clone -b 0.8 https://github.com/bitcoin/bitcoin.git bitcoin-0.8
> cd bitcoin-0.8/src
> make -f makefile.unix
> make -f makefile.unix check
> ```
>
> 0.9 branch (on top of 0.9.3+)
> ========================
> https://github.com/bitcoin/bitcoin/tree/0.9
> https://github.com/bitcoin/bitcoin/commits/0.9
>
> To fetch, build, and test:
> ```
> git clone -b 0.9 https://github.com/bitcoin/bitcoin.git bitcoin-0.9
> cd bitcoin-0.9/src
> ./autogen.sh
> ./configure
> make
> make check
> ```
>
> 0.10 branch (on top of 0.10.0rc1+)
> ========================
> https://github.com/bitcoin/bitcoin/tree/0.10
> https://github.com/bitcoin/bitcoin/commits/0.10
>
> ```
> git clone -b 0.10 https://github.com/bitcoin/bitcoin.git bitcoin-0.10
> cd bitcoin-0.10/src
> ./autogen.sh
> ./configure
> make
> make check
> ```
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

[Wladimir]

On Sat, Jan 10, 2015 at 12:18 PM, Ivan Jelincic <parazyd@archlinux.info> wrote:
> Is openssl1.0.1j unaffected?

Yes. It concerns CVE-2014-8275.

Which in https://www.openssl.org/news/openssl-1.0.1-notes.html is under:

Major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k [8 Jan 2015]

Wladimir