CFSSL

Overview

During the Spring 2017 semester (February to April) I took a course called “Open-Source Software Engineering,” a class where students spend the semester contributing to an existing open-source project.

I chose to work on the CFSSL team, which worked on improving one of Cloudflare’s command line tools by providing support for “Certificate Transparency,” an added layer of security being gradually phased into the existing web infrastructure.

Below is a picture of our team: (left-to-right) myself, Bradley Tiller, Jimmy Cao, and David Li.

Check out Cloudflare’s blog post about the purpose of CFSSL or the CFSSL GitHub repository.

Why does this course exist?

Each team had mentors, actively contributing members of their chosen project, who got them up to speed on contributing and helped focus their efforts. While most of the projects started with some specific goal, students had some freedom to choose their specific tasks (such as addressing an issue filed by a user or another contributor). One of the main goals of the course was to develop the practical skills needed to understand and contribute to an existing software project. For instance, we spent a lot of time reading code, issues, and outside resources to better understand our tasks and develop reasonable implementations that were consistent with the existing codebase (without breaking it).

The Project and Our Contributions

What is CFSSL?

Every time you visit a website, just before connecting, your browser checks that you’re visiting the correct site (and not an imposter) by inspecting an SSL certificate provided by the site’s server. Each certificate is like a public ID card that contains identifying information for the site and a secure signature that uniquely identifies its issuer. The signature enables authentication because your browser only trusts certificates signed and issued by trusted organizations called Certificate Authorities (CAs). Cloudflare SSL (CFSSL) is an open-source command line tool created by Cloudflare for creating and managing SSL certificates.

What is Certificate Transparency?

One problem with authenticating websites with certificates is that it relies heavily on trust in Certificate Authorities. CAs can be compromised by hackers or simply behave maliciously (e.g. by issuing a certificate for your website to a third party). This creates the need to quickly detect maliciously issued certificates. Certificate Transparency (CT) is a framework that was developed to address this problem by enabling users, website owners, and certificate authorities to monitor the status of all certificates. One main feature introduced by Certificate Transparency is the certificate log server. In CT, all certificates must be submitted to public “CT Log” servers that keep an append-only collection of issued certificates. Browsers would only trust certificates that are available in one of these public logs, and CAs and domain owners would regularly check these logs for suspicious certificates. This allows users and website owners to quickly distrust certificates and detect when new certificates have been issued for existing websites, which together make them less vulnerable to compromised CAs.

What did I work on?

Whenever a certificate is submitted to a log, the log returns a Signed Certificate Timestamp (SCT), which websites must provide with the certificate before establishing a connection to a client. Because CAs are responsible for submitting certificates to logs, they must also provide SCTs to website owners. There are multiple ways of transmitting SCTs to website owners, one of which involves embedding them inside the actual certificates. This, however, requires that CAs wait to receive SCTs from logs before they issue the corresponding certificates. Another, faster, method involves embedding (a.k.a. “stapling”) the SCTs in the response from a separate server. Then, when the SCT becomes available, the website owner can query the server and extract the embedded SCT. My main contribution to CFSSL was to enable the second, “stapling” approach. To do this, I created a new database table for storing SCTs, which would be updated when new SCTs are received. Then, I augmented a second database table that stores precomputed server responses. I had this second table retrieve any corresponding SCTs from the SCT table and “staple” them to the new responses. Thus, new SCTs are eventually added to the server’s responses, making them available to website owners. This contributed to the adoption of the CT framework within CFSSL by enabling an alternative method of SCT issuance.

StapleSCTList

Below is the signature of one of the main functions I contributed to enable “stapling” SCTs to OCSP responses.

// StapleSCTList inserts a list of Signed Certificate Timestamps into all OCSP
// responses in a database.
func StapleSCTList(acc certdb.Accessor, serial, aki string, scts []ct.SignedCertificateTimestamp,
	responderCert, issuer *x509.Certificate, priv crypto.Signer) error {
        ...
}

Adding a feature to the CLI

One of the other contributions I made to CFSSL was to enable passing certain command line arguments as text rather than file names. This was a feature that users had requested in a GitHub issue.

Source

Both of my merged contributions can be found at the following link: https://github.com/cloudflare/cfssl/commits?author=sfurman3