Source author record

Nikita Korzhitskii

Nikita Korzhitskii appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record

Cryptography and Security Networking and Internet Architecture cs.CY Performance

Catalog footprint

What is connected

3works

4topics

2close collaborators

Actions

Connect this record

Open graph Browse works

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

preprint2022arXiv

Postcertificates for Revocation Transparency

The modern Internet is highly dependent on trust communicated via certificates. However, in some cases, certificates become untrusted, and it is necessary to revoke them. In practice, the problem of secure revocation is still open. Furthermore, the existing procedures do not leave a transparent and immutable revocation history. We propose and evaluate a new revocation transparency protocol that introduces postcertificates and utilizes the existing Certificate Transparency (CT) logs. The protocol is practical, has a low deployment cost, provides an immutable history of revocations, enables delegation, and helps to detect revocation-related misbehavior by certificate authorities (CAs). With this protocol, a holder of a postcertificate can bypass the issuing CA and autonomously initiate the revocation process via submission of the postcertificate to a CT log. The CAs are required to monitor CT logs and proceed with the revocation upon detection of a postcertificate. Revocation status delivery is performed independently and with an arbitrary status protocol. Postcertificates can increase the accountability of the CAs and empower the certificate owners by giving them additional control over the status of the certificates. We evaluate the protocol, measure log and monitor performance, and conclude that it is possible to provide revocation transparency using existing CT logs.

preprint2022arXiv

Revocation Statuses on the Internet

The modern Internet is highly dependent on the trust communicated via X.509 certificates. However, in some cases certificates become untrusted and it is necessary to revoke them. In practice, the problem of secure certificate revocation has not yet been solved, and today no revocation procedure (similar to Certificate Transparency w.r.t. certificate issuance) has been adopted to provide transparent and immutable history of all revocations. Instead, the status of most certificates can only be checked with Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs). In this paper, we present the first longitudinal characterization of the revocation statuses delivered by CRLs and OCSP servers from the time of certificate expiration to status disappearance. The analysis captures the status history of over 1 million revoked certificates, including 773K certificates mass-revoked by Let's Encrypt. Our characterization provides a new perspective on the Internet's revocation rates, quantifies how short-lived the revocation statuses are, highlights differences in revocation practices within and between different CAs, and captures biases and oddities in the handling of revoked certificates. Combined, the findings motivate the development and adoption of a revocation transparency standard.

preprint2021arXiv

Characterizing the Root Landscape of Certificate Transparency Logs

Internet security and privacy stand on the trustworthiness of public certificates signed by Certificate Authorities (CAs). However, software products do not trust the same CAs and therefore maintain different root stores, each typically containing hundreds of trusted roots capable of issuing "trusted" certificates for any domain. Incidents with misissued certificates motivated Google to implement and enforce Certificate Transparency (CT). CT logs archive certificates in a public, auditable and append-only manner. The adoption of CT changed the trust landscape. As a part of this change, CT logs started to maintain their own root lists and log certificates that chain back to one of the trusted roots. In this paper, we present the first characterization of this emerging CT root store landscape, as well as the tool that we developed for data collection, visualization, and analysis of the root stores. We compare the logs' root stores and quantify their changes with respect to both each other and the root stores of major software vendors, look at evolving vendor CT policies, and show that root store mismanagement may be linked to log misbehavior. Finally, we present and discuss the results of a survey that we have sent to the log operators participating in Apple's and Google's CT log programs.