BoringSSL vs. OpenSSL: Why It Was Created for Chromium

In 2014, Google introduced BoringSSL, a direct fork of the widely used OpenSSL cryptographic library, designed specifically to power the Chromium web browser and the Android operating system. This article explains why Google decided to build and maintain its own cryptographic solution rather than rely on the standard OpenSSL distribution. It covers the historical challenges Chromium developers faced with OpenSSL and outlines the core architectural, operational, and security differences that separate the two libraries today.

Why BoringSSL Was Created for Chromium

Before BoringSSL, Google relied heavily on OpenSSL for secure communications in Chromium, Chrome, and Android. However, Chromium is a rapidly evolving browser that frequently serves as a testing ground for new web standards and cutting-edge security protocols. OpenSSL, as a general-purpose library used by millions of servers and applications worldwide, could not move at the speed Chromium required.

To implement new features—such as TLS False Start, ALPN (Application-Layer Protocol Negotiation), and experimental cipher suites—Google engineers had to write custom patches on top of OpenSSL. By 2014, Google was maintaining over 70 complex patches.

Maintaining these patches became unsustainable for several reasons:

  • Integration Bottlenecks: Every time OpenSSL released an update or security fix, Google engineers had to manually port their 70+ patches to the new version, which was time-consuming and prone to human error.
  • Fragmentation: Chromium, Android, and Google’s internal servers were all using slightly different versions of OpenSSL with different sets of patches.
  • The Heartbleed Catalyst: The discovery of the catastrophic Heartbleed bug in OpenSSL in 2014 highlighted the dangers of a bloated, complex codebase. Google realized it needed a smaller, cleaner, and heavily audited library tailored strictly to its own ecosystem.

BoringSSL was created to unify Google's cryptographic efforts into a single, streamlined codebase that Chromium could update seamlessly without waiting for upstream approval or managing fragile patch sets.

Key Differences Between BoringSSL and OpenSSL

While BoringSSL and OpenSSL share the same ancestry and continue to share bug fixes and code with one another, their goals and designs have diverged significantly.

1. API and ABI Stability

  • OpenSSL: Strongly commits to API (Application Programming Interface) and ABI (Application Binary Interface) backward compatibility. When OpenSSL updates, existing applications using it generally do not need to rewrite their code.
  • BoringSSL: Explicitly offers no API or ABI stability guarantees. Because it is built directly into the Chromium source tree, Google engineers can change how BoringSSL works at any time and simultaneously update the Chromium code that calls it. This allows for rapid refactoring and security improvements without the burden of legacy support.

2. Codebase Size and Legacy Support

  • OpenSSL: Designed to run on almost any hardware and operating system in existence, including decades-old mainframes and obscure embedded systems. It also retains support for deprecated cryptographic algorithms to avoid breaking older software.
  • BoringSSL: Strips away all legacy code, obscure hardware support, and weak cryptographic algorithms not needed by modern browsers or Android devices. By aggressively deleting unused code, BoringSSL drastically reduces its attack surface, making it easier to audit and secure.

3. Target Audience

  • OpenSSL: A public utility meant for everyone. It is the default cryptographic library for most Linux distributions and countless open-source projects.
  • BoringSSL: Built strictly for Google and Chromium. In fact, Google actively discourages outside developers from using BoringSSL as a general-purpose system library because its lack of stability guarantees will break third-party applications.

4. Adoption of Modern Cryptography

  • OpenSSL: Moves deliberately and cautiously. It typically waits for internet standards (like those from the IETF) to be finalized before implementing them, ensuring stability for its massive user base.
  • BoringSSL: Acts as an incubator for the future of web security. Because it is tied to Chromium, Google uses BoringSSL to deploy and test draft versions of protocols at scale. For example, BoringSSL was used to pioneer TLS 1.3 and experiment with post-quantum cryptography in Chrome long before those standards were finalized.

5. Programming Language Modernization

  • OpenSSL: Written strictly in C to ensure maximum portability across all compilers and platforms.
  • BoringSSL: Has gradually migrated much of its internal codebase from C to modern C++. This allows Chromium developers to use safer memory management techniques and modern programming constructs, reducing the likelihood of memory-safety bugs like buffer overflows.