Abstract-The level of trust accorded to certification authorities has been decreasing over the last few years as several cases of misbehavior and compromise have been observed. Logbased approaches, such as Certificate Transparency, ensure that fraudulent TLS certificates become publicly visible. However, a key element that log-based approaches still lack is a way for clients to verify that the log behaves in a consistent and honest manner. This task is challenging due to privacy, efficiency, and deployability reasons. In this paper, we propose the first (to the best of our knowledge) gossip protocols that enable the detection of log inconsistencies. We analyze these protocols and present the results of a simulation based on real Internet traffic traces. We also give a deployment plan, discuss technical issues, and present an implementation.

Certificate transparency (CT) is an elegant mechanism designed to detect when a certificate authority (CA) has issued a certificate incorrectly. Many CAs now support CT and it is being actively deployed in browsers. However, a number of privacy-related challenges remain. In this paper we propose practical solutions to two issues. First, we develop a mechanism that enables web browsers to audit a CT log without violating user privacy. Second, we extend CT to support non-public subdomains.

Certificate Transparency (CT) is an emerging system for enabling the rapid discovery of malicious or misissued certificates. Initially standardized in 2013, CT is now finally beginning to see widespread support. Although CT provides desirable security benefits, web browsers cannot begin requiring all websites to support CT at once, due to the risk of breaking large numbers of websites. We discuss challenges for deployment, analyze the adoption of CT on the web, and measure the error rates experienced by users of the Google Chrome web browser. We find that CT has so far been widely adopted with minimal breakage and warnings.Security researchers often struggle with the tradeoff between security and user frustration: rolling out new security requirements often causes breakage. We view CT as a case study for deploying ecosystem-wide change while trying to minimize end user impact. We discuss the design properties of CT that made its success possible, as well as draw lessons from its risks and pitfalls that could be avoided in future large-scale security deployments.

No abstract

No abstract