Published on: 2015-01-12T09:40:51+00:00
On January 10, 2015, Ivan Jelincic raised concerns about the vulnerability of openssl1.0.1j, specifically regarding CVE-2014-8275. However, it was determined that OpenSSL 1.0.1j is unaffected by this vulnerability, as stated in the major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k on the OpenSSL website news section.The post discusses how to address the OpenSSL vulnerability in Bitcoin. OpenSSL is a crucial cryptographic library used for SSL/TLS connections in Bitcoin. To tackle the issue, patches have been developed for the new OpenSSL versions, which can be found on stable branches 0.8, 0.9, and rc branch 0.10. The post provides links for fetching, building, and testing these patches. Users can choose the appropriate branch and follow the necessary steps to update their systems. Additionally, the post mentions the Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, which serves as a hub for parallel software development.In a message dated January 10, 2015, Gregory Maxwell announced the availability of patches to assist those building from source to cope with the new OpenSSL versions. These patches are accessible on stable branches 0.8, 0.9, and rc branch 0.10. Links are provided for downloading, building, and testing each software version. Users can simply copy and paste the provided command into their terminal and follow the instructions for Bitcoin versions 0.8, 0.9, and 0.10rc1+.In January 2015, Gregory Maxwell discussed an incompatibility issue caused by an OpenSSL update, which altered the behavior of ECDSA validation to reject signatures that were not encoded strictly. While this change is generally acceptable for most applications, it poses a challenge for Bitcoin, a consensus system where all participants must agree on the precise validity or invalidity of input data. This modification was a response to CVE-2014-8275, known as "Certificate fingerprints can be modified." It is important to note that this vulnerability is not limited to miners and affects various advanced Bitcoin protocols. In micropayment channel protocols, the receiver must validate signatures from the sender to ensure they can broadcast transactions containing those signatures in the future. If the receiver accepts a signature that the majority of hashing power deems invalid, the sender can exploit the micropayment channel timeout to recover their funds entirely, defrauding the receiver. Similar vulnerabilities may exist in non-Bitcoin protocols. The aforementioned incompatibility raises concerns about the design of OpenSSL itself in terms of consensus-critical considerations. Given Maxwell and Wuille's recent findings and the presence of CVE-2014-3570, it is recommended to migrate Bitcoin Core to libsecp256k1 in the near future. This move would provide a consensus-focused library with a well-understood design, resulting in fewer consensus problems compared to the existing OpenSSL dependency. Furthermore, it would benefit advanced protocol implementations by offering a clear dependency for consensus-critical signature evaluation.Bitcoin users have been cautioned against updating to OpenSSL 1.0.0p/1.0.1k, as it could lead to consensus forks and is incompatible with the Bitcoin system. Binaries released by Bitcoin Core from Bitcoin.org are unaffected, as are those built utilizing the gitian deterministic build system. However, if running third-party or self-compiled Bitcoin Core or an alternative implementation using OpenSSL, it is crucial not to update OpenSSL or to use a Bitcoin software containing a workaround. Tests included with Bitcoin Core in the test_bitcoin utility already identify this condition and fail. The incompatibility stems from the change in ECDSA validation behavior due to the OpenSSL update, which now strictly rejects signatures that are not encoded as required. While many applications can tolerate rejecting certain signatures, Bitcoin's consensus system necessitates agreement among participants on the exact validity or invalidity of input data. Consistency takes precedence over "correctness. "To address the underlying issue of relying on software not designed or distributed for consensus use (specifically OpenSSL) for consensus-normative behavior, patches have been proposed for a targeted soft-fork to enforce strict DER compliance. This proposal utilizes a subset of BIP62. Implementing a blockchain rule for strict DER would minimize the risk of consensus inconsistencies arising from alternative signature parsing or verification implementations, simplify BIP62, and enhance the separation between cryptographic validation code and the consensus algorithm. Failure to adopt this solution may result in a persisting or potentially worsening situation in the future.It is worth noting that the relevant incompatible transactions have already been classified as non-standard on the network since the release of Bitcoin Core 0.8.0 in February 2013. Although one miner continued mining these incompatible transactions, they have been contacted and rectified their software. Therefore, a soft-fork without chain forking should be achievable.
Updated on: 2023-08-01T11:06:21.826004+00:00