Announcing the Open Multi-Perspective Issuance Corroboration Project

By Henry Birge-Lee, Grace Cimaszewski, Liang Wang, Cyrill Krähenbühl, Kerstin Fagerstrom, and Prateek Mittal

Today we are announcing the development of a new open source project by our research group at Princeton University designed to strengthen certificate issuance against Border Gateway Protocol (BGP) routing attacks. Recent years have seen an uptick in a very powerful attack that can man-in-the-middle an HTTPS webpage by exploiting a vulnerability in the Internet’s routing system. We previously analyzed one such example of this attack in the wild in a previous blog post.

As discussed in our Usenix Security ‘23 paper, the process that CAs use to verify domain ownership, known as domain control validation, is vulnerable to BGP attacks. By hijacking traffic to a victim’s webserver during domain control validation, an adversary can fool a CA into signing a certificate on its behalf for a domain it does not control. To mitigate the risk of BGP attacks on domain control validation, several CAs (including the world’s largest Web PKI CA Let’s Encrypt and Google Trust Services) have deployed a countermeasure known as Multi-Perspective Issuance Corroboration or MPIC (which we designed in our Usenix Security ‘18 paper and studied the deployment of in our Usenix Security ‘21 paper). In MPIC, domain control validation for each certificate request is performed multiple times from distinct vantage points spread throughout the Internet. This technique detects BGP attacks by exploiting the fact that many BGP announcements are localized and only affect a portion of Internet traffic. If a CA performs domain control validation from a vantage point whose routing is unaffected by the adversary’s attack, this vantage point’s traffic will be routed to the victim’s server and connect to the “real” domain, enabling detection of the attack.

Today, we are beginning the development of an open source, and extensible MPIC implementation that can be readily deployed by any CA. There are currently three MPIC implementations, but each has limitations that potentially prevent it from scaling to the entirety of the CA ecosystem.

• Let’s Encrypt uses MPIC in their open-source production CA Boulder, but it is based on Let’s Encrypt-specific back end data structures and RPC calls which potentially make it difficult to integrate into other CA codebases. Furthermore, as Let’s Encrypt is an ACME-only CA their implementation only handles ACME domain control validation types.
• Google Trust Services similarly uses MPIC in production, but has a MPIC deployment that currently utilizes Google-specific infrastructure. Google Trust Services only supports ACME in their MPIC deployment.
• CloudFlare developed a HTTPS-API-based deployment of MPIC in order to assist the broader CA community in deploying MPIC. This API currently only supports ACME validation methods but there are plans to add non-ACME validation methods as well.

We identify the following limitations in existing implementations. First, there is no option for CAs that do not support ACME or support validation methods other than the ACME validation methods. Second, adapting the Let’s Encrypt or Google Trust Services implementation for a different CA requires rethinking infrastructure-specific design choices. While the CloudFlare implementation does offer a convenient API for all CAs to use, some CAs may prefer to maintain control over this infrastructure as opposed to relying on a third party to operate it.

With this in mind, we are launching the Open MPIC project. The goal of the project is to develop an API-style implementation of MPIC that anyone can deploy on the cloud provider of their choice. This offers the convenience of a RESTful HTTPS API for implementation purposes, but allows a CA to manage the infrastructure themselves. Below we discuss some of the design choices we are making for the project.

ACME and Non-ACME Support

We plan to support both ACME and non-ACME HTTP and DNS validation methods. This will be done by having a flexible format for URLs and domain names that will not require specific ACME prefixes (e.g., “.acme-challenge”). 

Various Domain Control Validation Methods Supported

We plan to initially focus on HTTP and DNS-based validation. After this, we plan to further expand the API to retrieve records (e.g., email contacts in CAA records which can be used for validation) from multiple network perspectives.

CAA Compliance Checking

The API will offer the option of checking CAA records concurrently with DNS or HTTP challenges. The API will also support the checking of CAA records via a separate API call that can be initiated at any time.

Logging

The implementation will support detailed logging designed to comply with the current logging requirements in the draft of the MPIC ballot. This will include multiple logging levels, cloud logs generated at remote network perspectives, and detailed API responses. We intend to include in the API responses a unique identifier of the remote perspectives used, the domain/IP being validated, the methods used by each perspective, and the result from each perspective. With this design, storing these API responses using a CA’s existing logging infrastructure should satisfy the current logging requirement for MPIC stated in the draft ballot.

Use of Secure Infrastructure and Best Practices

The API will be hosted on secure infrastructure that conforms to best practices to prevent any attacks that occur on API infrastructure. Furthermore, communication between the CA and the API endpoint will be protected with TLS and API secrets that are only known to the specific CA using the API. Communication between all elements of the API (e.g., remote network perspectives) will also all be done over secure and encrypted channels that offer confidentiality and integrity.

Automated Deployment

A potential challenge with a roll-your-own API approach is that each CA has to manage remote infrastructure all around the globe which is a considerable part of the difficulty involved with deploying MPIC. To solve this we plan to utilize an automated deployment system to allow for rapid deployment of our API using only a CA’s cloud provider account id/access token. Config scripts, initialization scripts, monitoring will all be included in the project and allow for the deployment of a personalized and customized API using a single command.

Serverless Computing

Our preliminary work has shown the potential to run such an API using serverless computing. This eliminates the need to operate “servers” to run the API and instead reduces the API to several functions which can be invoked on an on-demand basis on cloud-provider-managed servers. While simplifying some setup scripts and interactions with OSes, the main advantage of running an API like this in a serverless environment is that a CA does not need to keep the servers running when no requests are coming in. The costs of running MPIC even at a large scale are quite manageable (as discussed in our Usenix Security ‘21 paper) but the serverless option further saves resources.

High Degree of Configurability

While we expect default settings to work for many CAs, we also want the API to be highly configurable and easily manage variables like network perspective location, count, and quorum policy. We plan to have this adjustable in a configuration file which CAs can change to get the MPIC deployment they want.

Cross Cloud Provider Compatibility

Different cloud providers offer different pricing models, and some CAs may already have billing relationships in place with specific cloud providers further simplifying setup. With this in mind we would eventually like the API to be fully cross-cloud compatible.

Call for Collaborators

We welcome any external collaboration on this project from both the broader community or industry. The project will be fully open source and community driven. We plan to announce an official GitHub repo shortly (as well as a formal email list for discussion). We further are open to working with CA product vendors to integrate this API directly into popular CA software. For the time being any interested parties with more questions or collaboration inquiries can contact open-mpic [at] princeton.edu or subscribe to this list here.

Conclusion

With all of these features and conveniences, we aim to make MPIC readily deployable for any CA. We intend for the API format to return enough detail to satisfy potential CA/B Forum logging requirements but also return a simple Yes/No that can be easily parsed from the result of the API call (e.g., in the HTTP status code). We hope this will ease the burden on CAs for deploying MPIC and make it something that can be integrated into any CA’s operations with very few lines of code.