Duke University / Vice President, Research, Akamai Technologies
Bruce Maggs received the S.B., S.M., and Ph.D. degrees in computer science from the Massachusetts Institute of Technology in 1985, 1986, and 1989, respectively. His advisor was Charles Leiserson. After spending a year as a Postdoctoral Associate at MIT, he worked as a Research Scientist at NEC Research Institute in Princeton from 1990 to 1993. In 1994, he moved to Carnegie Mellon, where he stayed until joining Duke University in 2009. While on a two-year leave-of-absence from Carnegie Mellon, Maggs helped to launch Akamai Technologies, serving as its first Vice President for Research and Development. The work on CRLite received the 2017 IEEE Cybersecurity Innovation Award. In 2018 Maggs was part of a large team that received the inaugural SIGCOMM Networking Systems Award for the Akamai CDN, and was named an ACM Fellow.
The Public Key Infrastructure (PKI) for the web was designed to help thwart “phishing” attacks by providing a mechanism for browsers to authenticate web sites, and also to help prevent the disclosure of confidential information by enabling encrypted communications. For users to reap these benefits, however, the parties that implement and operate the PKI, including certificate authorities, web-site operators, and browser vendors, must each perform their roles properly. This talk focuses on one aspect of the PKI: certificate revocation. The security of a web site hinges on the ability of the site operator to keeps its private keys private. While most operators guard their keys carefully, on occasion software vulnerabilities such as the notorious Heartbleed Bug have put millions of keys at risk. If a web-site operator fears that its private key has been compromised, it should ask its certificate authority to revoke the corresponding certificate. Browsers, however, often do not fully check whether the certificates they receive have been revoked, and mobile browsers never check. There are a variety of reasons for not checking, but the most important are the amount of bandwidth required to download certificate revocation lists in advance, the latency of checking certificates on the fly, and the slow progress of upgrading every web server to support the newer certificate status stapling approach. This talk presents a new and much more efficient system, CRLite, for pushing the revocation status of every certificate to every browser. CRLite leverages a recent development: although lists of revoked certificates were previously available, Google’s Certificate Transparency project now also provides a log of all unrevoked certificates as well. With both lists in hand, a compact data structure called a filter cascade can be used to represent the status of every certificate with no false positives and no false negatives. CRLite requires a browser to download a 1.2MB filter cascade initially, and then a 40KB update (on average) every day. Our results demonstrate that complete revocation checking is within reach for all clients.