Diffusing the OpenSSL time bomb

Todays newsletter continues with chapter 4 from Bitcoin: A Work in Progress.

I’ll be in London next week for Advancing Bitcoin. Use libsecp256k1 for 20% off.

A wrote a few comments on Mastodon regarding the recent Wallstreet Journal article about Bitcoin Core maintainers. I was also a guest on the Bitcoin.Review podcast to discuss Bitcoin Core development.

Last week we explained how a bug in OpenSSL almost led to a chain split. This timebomb was diffused with several measures.

First, users could still download the Bitcoin Core binary as usual, since it came bundled with this older version of OpenSSL. Even though this version had a security bug in it, remember that each piece of software on your computer can choose to bring its own version of OpenSSL. This particular bug impacted browser software, but not Bitcoin Core, so your browser would have to ship the new version immediately, while Bitcoin Core could wait a little longer.

Second, those who prefer to compile their own software from source were offered two possible workarounds. They could either hold off on updating OpenSSL, or use a sufficiently recent version of the source code, which now contained a patch that worked around the issue.

Third, the BIP 66 soft fork was proposed, and it was indeed successfully activated (read more on soft fork activation in chapter 12). This fork required that future signatures all abide by the stricter standard, so that both old and new versions of OpenSSL would accept them.

This incident wasn’t necessarily surprising, as OpenSSL is famous for its vulnerabilities. The main reason for this is because these libraries have been used by everyone for decades, but they’re only maintained by a tiny number of volunteers on a shoestring budget.

cURL is another example of this. It’s a library that downloads files, and it’s used everywhere, but again, there isn’t a well-funded team behind it.

In the case of OpenSSL, one reason it had these bugs is that it’s easy to make mistakes with cryptographic code. What’s more, OpenSSL is written in C, so if you forget a semicolon, whoops, now you’re skipping a line, and perhaps that line was actually checking the password. A famous example of this is the Heartbleed bug from 2014, in which a small mistake made it so anyone with the know-how could log into any computer on the internet without a password.

When a bug in Bitcoin isn’t discovered and fixed in time, a malicious person can trigger a sudden network split. In the example above, someone could’ve broadcast a transaction with a signature that’s valid according to old versions of OpenSSL, yet invalid according to new versions of OpenSSL. This would cause old nodes to accept the block and new nodes to reject it. Chain splits can be triggered by all sorts of programming mistakes, not just changes in libraries. There have been a few close calls.