Google's internal fork. Used in Chrome, Android, and Cloudflare. Not intended for external use but widely adopted.
OpenSSL provides the cryptographic primitives and TLS protocol implementation used by the majority of internet servers and clients. BoringSSL strips OpenSSL down to what Google needs, removes legacy APIs, and adds Google-specific features like QUIC protocol support and certificate transparency.
Two months after LibreSSL made headlines by aggressively pruning OpenSSL's codebase, Google quietly announced its own fork: BoringSSL. Where LibreSSL was born of righteous anger, BoringSSL was born of engineering pragmatism. Google had been maintaining over 70 patches on top of OpenSSL across multiple internal copies used in Chrome, Android, and various infrastructure — and the maintenance burden was becoming unsustainable.
Adam Langley, Google's TLS guru, announced the fork on June 20, 2014. The name was deliberately anticlimactic — 'boring' as in 'not exciting,' because the last thing you want your cryptographic library to be is exciting. Unlike LibreSSL's dramatic code purges, BoringSSL was a methodical consolidation of Google's existing patches into a single coherent library.
What makes BoringSSL unusual is that Google explicitly told everyone not to use it. It's not meant to be a general-purpose OpenSSL replacement — it has no stable API, no guaranteed backward compatibility, and Google reserves the right to change anything at any time. Despite this, BoringSSL has become enormously influential because it ships inside Chrome (used by billions) and Android (used by billions more), and has been adopted by Cloudflare and other major infrastructure providers.
The project quickly diverged from OpenSSL in meaningful ways. Google implemented features like certificate transparency, QUIC protocol support, and post-quantum cryptographic algorithms in BoringSSL before they appeared anywhere else. It became a testing ground for the future of TLS.
BoringSSL represents a different philosophy from LibreSSL: rather than trying to fix OpenSSL for everyone, Google just fixed it for Google — and the rest of the world happened to benefit from the improvements that flowed back and forth between the three forks.
Heartbleed disclosure accelerates Google's plans to consolidate OpenSSL patches
Adam Langley announces BoringSSL, promises to share fixes with LibreSSL
Chrome begins transitioning from OpenSSL to BoringSSL
Android transitions to BoringSSL
Cloudflare adopts BoringSSL for its edge network
BoringSSL adds post-quantum key exchange experiments
“We have used a number of patches on top of OpenSSL for many years. As Google's product portfolio has become more complex, more copies of OpenSSL sprung up.”
BoringSSL is arguably the most successful of the three OpenSSL forks by sheer reach — it secures the TLS connections of Chrome and Android, meaning billions of devices use it daily. Its willingness to experiment with cutting-edge cryptography (post-quantum algorithms, QUIC support) has pushed the entire TLS ecosystem forward faster than any standards body could alone.
The fork also established a model that other companies would follow: instead of trying to influence a slow-moving open-source project, just fork it internally, optimize it for your needs, and let improvements flow back organically. It's corporate open source at its most honest — Google never pretended BoringSSL was for anyone but Google.