Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
On Sat, Jan 10, 2015 at 12:18 PM, Ivan Jelincic 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 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. vanity: www.gigenet.com ___ Bitcoin-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
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 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
On Sat, Jan 10, 2015 at 4:26 AM, Gregory Maxwell 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
On Sat, Jan 10, 2015 at 04:26:23AM +, 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 003b82d8644b56c846e7497118b04a6ec68d3e0a23d33323b82e signature.asc Description: Digital signature -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
