The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.
For Developers‎ > ‎Design Documents‎ > ‎Network Stack‎ > ‎

SSL Stack

Note: This document was written around ~March 2010.

For an update on the status, see the chromium-dev archives, e.g. this thread.

" the features described [here after] have long since been implemented, initially during the Chrome 6 development  phase for most purposes, and finalized for all uses prior to the release of Chrome 9. "

Current Status

Chromium uses the system SSL and crypto libraries on each platform.
  • Linux: Chromium uses NSS.
  • Mac: Chromium uses Secure Transport for SSL and CSSM for crypto.
  • Windows: Chromium uses SChannel for SSL and CryptoAPI for crypto.

Proposal

  • Switch to NSS for SSL.
  • Continue to use the system crypto library for crypto and certificate verification.
  • Continue to use the system trusted root CA list.

Requirements

We want Chromium to integrate nicely with the OS.
  • Use the system certificate and key stores.
    • On Mac OS X, this is the Keychain.
    • On Linux, we use SQLite-based NSS databases in $HOME/.pki/nssdb, following the NSS Shared DB and LINUX proposal.
  • Support the OS native interface to smart cards.
The easiest way to ensure we meet these requirements is to use the system SSL and crypto libraries.  Since Chromium is a new browser, we had an opportunity to experiment with this approach.

Issues

Although using the system SSL and crypto libraries enabled us to accomplish perfect integration with the system certificate and key stores and support the native interface to smart cards, it has a few issues.
  • Uneven support of SSL features across OS versions: New SSL features are only available in the newer versions of the OS and are usually not backported to older versions of the OS.  The TLS server name indication extension is a feature we're especially interested in, but it is not supported by SChannel on Windows XP.
  • Inability to add new SSL features: We're interested in several SSL features that could improve HTTPS performance, but we can't extend or modify the system SSL libraries.
  • Long time to get bug fixes: Bug fixes in system SSL and crypto libraries are OS updates.  It takes much longer (weeks to months) to for OS updates to go through QA certification.

Three Components of SSL

SSL consists of three components:
  • Crypto operations
  • Certificate verification
  • Actual SSL protocol: sending and handling protocol messages
These three components can be separated.

Crypto libraries have a long history of using a pluggable architecture for crypto modules.  This allows an application to use an alternative crypto module (for better security or performance) or multiple crypto modules.

Certificate verification is easy to separate from the SSL protocol.  The only other certificate processing an SSL implementation needs to do is to extract the public key from a certificate so it can perform crypto operations with the public key.

Using NSS for SSL

We plan to switch to NSS for SSL so that we can use new SSL features across all versions of OS.

Because of tight integration of the key store with the crypto library, the requirement of using the system key store implies we need to use the system crypto library for private key operations.

Although not necessary, we plan to use the system crypto library for certificate verification so that we can benefit from the system-provided certificate chain viewer and certificate management tool.

This mixed use of NSS and system crypto library is possible because the three components of SSL can be separated.

Costs

NSS adds 781.5 KB to the size of Chromium on Windows, or a 4.0% increase (on 2010-01-21).

We had to create a custom build system to build NSS as part of Chromium.  This was necessary because Chromium is a single DLL on Windows and everything is statically linked in.

Comments