Certificate Transparency Revisited: The Public Inspections on Third-party Monitors

Certificate Transparency Revisited: The Public Inspections on Third-party Monitors

Speakers: Aozhuo Sun

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=1-l6UnZfrfQ

Overview

The integrity of the modern web relies heavily on TLS certificates, which vouch for the authenticity of websites and secure communication. However, the ecosystem built on trust in Certification Authorities (CAs) has been plagued by incidents of misissued or fraudulent certificates, undermining this fundamental trust. The Certificate Transparency (CT) framework was introduced to combat this by enhancing accountability and enabling prompt detection of such certificates. While CT mandates public logging of all certificate issuances and employs a system of log servers, auditors, and monitors, a critical vulnerability persists: the third-party monitors, essential for detecting misissued certificates, are largely uninspected and prone to unreliability.

This talk, presented by Aozhuo Sun at the NDSS Symposium, addresses this significant gap by introducing CT watchers. These watchers act as independent, public inspectors of third-party CT monitors. Their primary role is to detect misbehavior, whether due to faulty service or malicious actions, by identifying inconsistencies in certificate search results across multiple monitors. Furthermore, "full watchers" are designed to semi-automatically analyze the root causes of these inconsistencies, providing invaluable insights into potential design or implementation flaws within the monitors themselves.

The research presented demonstrates the critical need for such an inspection mechanism. Through a prototype implementation and a comprehensive 52-day trial, the CT watcher successfully analyzed 8.26 million unique certificates across 6,000 domains, uncovering 14 distinct design or implementation issues in popular third-party monitors. This work highlights that the foundational promise of Certificate Transparency—that any fraudulent certificate will be made visible—is fundamentally undermined by the unreliability of its monitoring layer, and that active, independent inspection by CT watchers is essential to restore and enhance the overall reliability and trustworthiness of the TLS certificate ecosystem.

Background

▶ Watch: CT's vulnerability: Uninspected third-party monitors undermine detection (0:00)

The security of the internet's Public Key Infrastructure (PKI), particularly for TLS (Transport Layer Security) certificates, hinges on the trustworthiness of CAs. Historically, this trust model has been vulnerable, with numerous incidents between 2011 and 2018 exposing instances of misissued or bogus certificates, often due to operational errors or even malicious attacks against CAs. These failures highlighted a critical need for a mechanism to detect and remediate such issues swiftly.

The Certificate Transparency (CT) framework was developed by Google to address this vulnerability. CT introduces three new components to the traditional PKI:

• Log Servers: These are append-only, publicly auditable logs that record all certificates submitted by CAs. Each submission results in a Signed Certificate Timestamp (SCT), which serves as proof that the certificate has been publicly logged. Logs are structured as Merkle hash trees, with a periodically signed root node known as a Signature Tree Head (STH).
• Auditors: These are lightweight components responsible for verifying the integrity of log servers. They ensure that logs are append-only and that SCTs are valid via audit paths, preventing logs from manipulating or omitting entries.
• Monitors: These are CT participants tasked with retrieving certificates of interest from the log servers. Monitors continuously fetch new log entries, parse raw certificates to extract relevant information (like domain names, SHA256 fingerprints, and submission times), and index them. When a domain is queried, they look up matching certificates and return the results.

Crucially, modern CT-compliant browsers (like Chrome) only accept certificates that include valid SCTs, ensuring that almost all publicly trusted certificates are logged. However, operating a CT monitor is a resource-intensive task, involving the processing of millions of new certificate records daily. Consequently, many domain owners and security researchers rely on professional third-party monitors to track certificates relevant to their domains. The study focused on six such active third-party monitors: Censys, crt.sh, Entrust Search, Facebook Monitor, Google Monitor, and SSLMate Spotter.

Despite their critical role in detecting misissued certificates, these third-party monitors are not adequately inspected within the current CT framework. Prior studies (references 32, 33 in the talk) have already indicated that popular third-party CT monitors frequently fail to return a complete set of inquired certificates, with reported missing rates ranging from 12.6% to 52.3%. Some monitors even returned irrelevant certificates, such as code-signing certificates from Censys. This unreliability fundamentally undermines CT's protection goals, as misissued or fraudulent certificates can easily evade detection if a monitor's search service is flawed or compromised.

The security threat posed by unreliable monitors is significant. While centralized CT components like CAs and log servers are subject to inspection, non-centralized components like auditors and browsers rely on redundancy or self-interest. Third-party monitors, however, can be either benignly faulty (e.g., due to configuration errors or software bugs) or maliciously compromised. An attacker could obtain a bogus certificate (e.g., via a BGP hijack or DNS cache poisoning attack) and then exploit design or implementation flaws in monitors to conceal its existence. For example, if a monitor uses a case-sensitive search, an attacker could craft a mixed-case domain name to evade detection. The proposed CT watchers are designed to detect both benign faults (rhythmic, repeatable misbehavior) and malicious actions (erratic, reproducible, split-view attacks), providing a much-needed layer of defense and ensuring disclosure even if one watcher itself is faulty, through redundancy among watchers.

Key Findings

▶ Watch: Background: CT framework, components, and monitor workflow (2:00)

The research presented on CT watchers makes several pivotal contributions to enhancing the reliability and security of the Certificate Transparency ecosystem. The key findings and contributions can be summarized as follows:

1. Introduction of CT Watchers: The work proposes and validates CT watchers as a novel and essential component for the CT framework. These watchers provide an independent, scalable inspection service specifically designed to audit the reliability and behavior of third-party CT monitors, thereby addressing a critical gap in the current CT trust model.
2. Dual-Mode Watcher Design: Two types of watchers were designed and implemented:

• Automated Light Watchers: These are lightweight and practical for continuous operation by any interested party, focusing on automated detection of inconsistencies for a small set of domains.
• Semi-Automated Full Watchers: These require more resources but offer enhanced capabilities, including semi-automated fault analysis to uncover the underlying causes of monitor misbehavior, providing actionable insights for remediation.

1. Real-World Validation and Extensive Experimentation: A comprehensive 52-day trial operation (from January 25 to March 16, 2020) was conducted, followed by confirmation experiments (April to December 2020). This involved analyzing 8.26 million unique certificates across approximately 6,000 domains (randomly selected from Alexa Top-1M tiers) using a prototype implementation that supported six active third-party monitors (Censys, crt.sh, Entrust Search, Facebook Monitor, Google Monitor, and SSLMate Spotter).
2. Discovery of 14 Design and Implementation Flaws: The most significant finding was the successful detection of 14 distinct design or implementation flaws and limitations across the six inspected monitors. These flaws led to approximately 1.4 million cases of missing or irrelevant certificates, demonstrating that popular monitors harbor unnoticed, exploitable vulnerabilities. The issues spanned certificate collection, indexing, look-up, and output mechanisms.
3. Prevalence of Service Delays and Output Limitations: The study empirically confirmed that monitor service delays are a major source of latency within the CT ecosystem. Estimated delays varied significantly, with Entrust Search showing a particularly poor timeliness of 34 days. Many monitors also exhibited undisclosed output limits or inconsistent behavior when paging results, leading to incomplete data.
4. Variability in Monitor Implementation and QoS: Significant differences were observed in how monitors collect, index, and serve certificates, including their support for features like Internationalized Domain Names (IDNs), case-sensitive searches, and handling of redacted or short-lived certificates. This lack of standardization contributes to the overall unreliability.
5. Necessity for Standardized Monitor Specifications: Based on the findings, the research proposes crucial specifications for third-party monitors, advocating for the public disclosure of Quality of Service (QoS) information (service delay, output limit, log list) and the adoption of uniform APIs. These recommendations aim to foster better cooperation with watchers and improve overall system reliability.
6. Defense Against Malicious Monitors: The work outlines technical routes for watchers to defend against malicious monitors, including a novel Bloom filter (BF)-based watcher protocol. This protocol enables privacy-preserving verification of search results, allowing an inquirer to inspect a servicing monitor's output against reference monitors without revealing their full certificate set.
7. Confirmed Exploitable Faults: The discovered faults are not merely theoretical; they represent real-world weaknesses that could be exploited by attackers to conceal misissued certificates, thereby undermining the very purpose of Certificate Transparency. The varied responses from vendors—from fixing bugs (Facebook, Google) to non-response (Entrust) or partial acknowledgment (Censys, crt.sh)—further underscore the ongoing challenge.

In essence, the research unequivocally demonstrates that relying solely on third-party CT monitors for security is insufficient and that the proactive deployment of CT watchers is a practical and effective solution to significantly enhance the accountability, trustworthiness, and overall security of the Certificate Transparency framework.

Technical Deep Dive

▶ Watch: Security threats posed by unreliable third-party CT monitors (3:25)

The core innovation of this research lies in the design and implementation of CT watchers, a novel component engineered to bring accountability to third-party Certificate Transparency monitors. Watchers function as independent inspectors, akin to how auditors verify log servers, but focused on the search services provided by monitors.

CT Watcher Design Goals and Challenges:

The design of CT watchers is guided by three primary goals:

1. Effective Misbehavior Detection: Watchers must actively probe monitor services to detect incorrect or abnormal behavior, whether benignly faulty or malicious.
2. Scalable Deployment: Operations need to be automated and lightweight to allow continuous or periodic execution by any interested party.
3. (Semi-)Automated Fault Analysis: For full watchers, this includes uncovering potential causes of misbehavior and identifying bug locations to provide actionable insights for monitor operators.

Achieving these goals presents several significant challenges:

• Absence of Ground Truth: There is no single, authoritative source for the complete set of relevant certificates for a given domain. Watchers must approximate this "ground truth" by aggregating data.
• Unpredictable Misbehavior: Monitor misbehavior is not easily predictable, necessitating a distributed design where many lightweight watchers cooperatively inspect the entire space.
• Monitor Heterogeneity: Monitors vary widely in their query APIs, certificate sources, search policies, and internal processing logic, which is often opaque. This requires sophisticated, non-trivial effort for automated certificate parsing and matching.
• Diverse Fault Reasons: Misbehavior can stem from various causes, leading to a large number of abnormal records that make manual analysis impractical and automated fault analysis challenging.

To address these, the watcher design relies on two key assumptions:

1. Standardized Monitor Interface: Monitors should ideally output expected certificates for a domain and specific certificates for SHA256 fingerprints, including basic certificate information (CN, SAN:dNSName, Issuer, SerialNumber, NotBefore, NotAfter), the PEM file, and log-details (log server name, submission time).
2. Public QoS Disclosure: Monitors should disclose their Quality of Service (QoS) information, such as service delay, output limit, and the list of logs they monitor. If not disclosed, watchers infer this from returned results.

System Design and Architecture (Figure 2):

A CT watcher operates continuously over N periods, iteratively collecting certificates, constructing a reference set, and analyzing inconsistencies. The system comprises two main modules:

1. Inconsistency Analyzer: This module is responsible for detecting discrepancies between a monitor's output and the approximated ground truth.

• Certificate Collection: For each inquired domain d, the watcher periodically obtains a "searched set" of certificates (Ssubd,m/sub) from each inspected monitor m at a specific SearchedTime.
• Reference Set Construction: This is a multi-step process to approximate the ground truth:
• Total Set (Equation 1): The watcher first combines all Ssubd,m/sub from all monitors over N periods to create a comprehensive total set Tsubd/sub.
• Pre-Reference Set (Equation 2): From Tsubd/sub, certificates that are either unlogged or expired before the SearchedTime are removed, forming a pre-reference set R'subd,i/sub.
• Final Reference Set (Equation 3): Irrelevant certificates—those returned by only a few monitors (e.g., 2 in the prototype, excluding newly issued or short-lived ones)—are then removed from the pre-reference set to yield the final reference set R''subd,i/sub. This voting mechanism helps filter out potentially erroneous or transient entries.
• Identifying Irrelevant and Missing Certificates:
• **Irrelevant Certificates (Ssup+/supsubd,m/sub):** These are certificates present in a monitor's searched set (Ssubd,m/sub) but not in the final reference set (R''subd,i/sub).
• **Missing Certificates (Ssup-/supsubd,m/sub):** These are certificates present in the final reference set (R''subd,i/sub) but absent from a monitor's searched set (Ssubd,m/sub).
• Classifying Missing Certificates by Cause: The analyzer attempts to attribute missing certificates to specific monitor limitations:
• Service Delay: If a certificate's SubmittedTime plus the monitor's estimated service delay is earlier than the SearchedTime, but the certificate is still missing, it's flagged as a delayed certificate.
• Output Limit: If a domain's searched set from a monitor reaches its known output limit, and the reference set for that domain is larger, then missing certificates are attributed to the output limit.
• Unmonitored Logs: If all logs recording a certificate are not part of the monitor's disclosed (or inferred) log list, the missing certificate is attributed to unmonitored logs.
• Trigger Domains: Any domain for which inconsistent results (non-empty irrelevant or missing sets) are found is identified as a trigger domain, indicating a potential issue.

1. Semi-Automated Fault Analyzer: This module, typically run by full watchers, aims to deduce internal bugs by analyzing trigger features.

• Certificate Labeling: Certificates are automatically labeled based on attributes like issuer, lifetime, SAN:dNSNames, redacted status, submission characteristics (e.g., first submission time, number of SCTs, logged format), and domain-inquired information (e.g., eTLD, target domains, mixed case, IDNs, reference set size). Manual labels can also be added.
• Feature Extraction and Ranking: A machine learning model (specifically, Random Forest with 10 estimators) is used to extract and rank features that exhibit strong discriminative power in classifying missing or irrelevant certificates.
• Trigger Feature Construction: High-ranking features are manually refined into "trigger features" that strongly correlate with potential bugs. Two measures are used:
• Measure 1 (Equation 4): Calculates the ratio of inconsistent certificates matching a feature Fsubx/sub to all collected certificates matching Fsubx/sub. A high ratio indicates a strong correlation with inconsistency.
• Measure 2 (Equation 5): Uses Cramer's V for a chi-square goodness-of-fit test. A V value of 0.5 or higher indicates a high association between Fsubx/sub and inconsistency.
• Bug Locating: For identified trigger features, black-box tests (e.g., searching by SHA256 fingerprint or precise subdomain) are performed. This helps pinpoint where in the monitor's internal workflow (fetching, storing, indexing, searching, or returning) the error is likely occurring.

Implementation Details:

The prototype implemented supported six active third-party monitors. Extensive investigation, including partial source code review, official documentation, CT forums, emails with development teams, and black-box tests, was conducted to infer critical service information and understand implementation differences. This included estimating service delays (e.g., Entrust Search at 34 days, Censys at 15 days, Google/SSLMate at 2 days) and identifying output limits (Entrust Search: 5,000 certificates). Significant differences were found in certificate sources, returned information, search policies (e.g., comparison scope, handling of expired certificates, (pre)certificate deduplication), and query APIs (ranging from database queries to web crawling). The data collection module standardizes raw data from these diverse monitors, ensuring synchronous queries to minimize the impact of service delays and uniquely identifying certificates by a quadruple (SerialNumber, Issuer, NotBefore, NotAfter) for deduplication.

Demo / Proof of Concept

▶ Watch: Core technical approach: CT Watchers methodology and design (4:05)

The efficacy of the CT watcher framework was rigorously demonstrated through a real-world prototype implementation and extensive experimental evaluation. This involved a 52-day trial operation from January 25 to March 16, 2020, followed by confirmation experiments from April to December 2020, providing a robust proof of concept.

Experimental Setup:

The prototype was configured to inspect six actively running third-party CT monitors: Censys, crt.sh, Entrust Search, Facebook Monitor, Google Monitor, and SSLMate Spotter. The input consisted of 4,000 domains randomly selected across various tiers of the Alexa Top-1M list, with 3,996 domains ultimately processed after excluding a few "super domains" that posed inquiry difficulties.

Data Collection and Inconsistency Analysis:

During the 52-day trial, the watcher collected approximately 5 million certificates daily, totaling 267.6 million raw certificate records. After deduplicating pre-certificates and final certificates, this yielded 964,050 unique certificates. The Inconsistency Analyzer then processed this data to identify irrelevant and missing certificates:

• Irrelevant Certificates: While most certificates were consistently found, some inconsistencies were noted. For instance, 42 certificates were returned only by Facebook Monitor, later confirmed to be due to a time parsing error (F5). Additionally, 52 email certificates were returned exclusively by Censys and/or Entrust Search, which were deemed irrelevant for domain-based queries.
• Missing Certificates: This was a more pervasive issue, with monitors missing a significant portion of certificates, ranging from 8.4% to a staggering 65.7% of the reference set.
• Entrust Search had the highest rate, missing 621,520 certificates in total, with 77,693 remaining unexplained after accounting for known limitations. This indicated a severe backlog problem, with a continuous increase in missing certificates over time.
• Facebook Monitor missed 633,605 certificates, with a substantial 594,743 initially unexplained, primarily due to a page-turning error (F9).
• SSLMate Spotter missed 310,078 certificates, with 244,713 attributed to an "internal_error."
• Censys missed 206,037 certificates, with 2,996 unexplained.
• Google Monitor missed 95,527 certificates, with 20,269 unexplained.
• crt.sh had the lowest rate, missing 80,841 certificates, with 0 unexplained, suggesting better handling of service limitations.
• A notable surge in missing certificates was observed for short-lived certificates (e.g., those for wixsite.com domains), highlighting an area where monitor indexing or retention might be problematic.

Service Delays:

The evaluation confirmed that monitor service delays are a primary source of latency in the CT ecosystem. The estimated service delays varied significantly: Censys (15 days), crt.sh (6 days), Facebook Monitor (3 days), Google Monitor (2 days), SSLMate Spotter (2 days), and Entrust Search (34 days). Entrust Search's delay was particularly egregious, with only 32.9K newly issued certificates found within the 52-day period, and 99% of those found within 34 days, indicating a profound lack of timeliness.

Identified Faults (14 Design/Implementation Issues):

Using the Semi-Automated Fault Analyzer, the research successfully identified 14 distinct design or implementation issues across the monitors. The Random Forest classifiers achieved high test accuracy (0.912 for Entrust Search, 0.994 for others) and F-1 scores (0.62-0.982) in distinguishing missing certificates. Four confirmed trigger features (F2, F4, F9, F11) were constructed, filtering out 83.0% to 99.8% of missing certificates. The identified issues, categorized by their impact on the monitor's workflow, include:

• Certificate Collection Issues:
• F1 (Entrust Search): Only monitored Google-operated logs, missing 35 non-Google certificates.
• F2 (Entrust Search): Prone to missing certificates on busiest logs (4 fastest-growing Google logs), with 83% of 77,693 missed certificates originating from non-busiest logs (Cramer's V = 0.863).
• Certificate Indexing Issues:
• F3 (Facebook Monitor, Google Monitor): Incorrectly indexed redacted certificates (2 instances found).
• F4 (Censys): Incorrectly parsed certificates with vast SAN:dNSNames (e.g., 8,830 characters long), tagging 2,895 out of 3,178 such certificates as unparsable.
• F5 (Facebook Monitor): Incorrectly parsed validity periods (a daylight saving time error) for 42 certificates.
• F6 (Facebook Monitor): May omit to mark certificates with a small probability, missing 1,291 certificates with only one target domain (Cramer's V = 0.833).
• F7 (Google Monitor): Parsing error for precertificates with underscores, leading to 165 missed certificates.
• Certificate Look-up or Output Issues:
• F8 (Entrust Search, Facebook Monitor): Prohibited queries with Internationalized Domain Names (IDN-ccTLD), returning no results for domains like xn--b1amahh6b.xn--p1ai.
• F9 (Facebook Monitor): Duplicated or missed certificates when paging results, affecting 592,902 certificates across 116 out of 122 paged domains.
• F10 (Censys, Entrust Search): Implemented case-sensitive retrieval, causing Entrust to miss all 1,428 mixed-case certificates and Censys to be case-sensitive for some domain fields.
• F11 (Google Monitor): Problem with outputs for short-lived certificates (e.g., 91 days), with 19,901 of 20,269 missing certificates being short-lived (Cramer's V = 1.812).

Confirmation and Vendor Responses:

Confirmation experiments further validated these findings. Facebook Monitor, for instance, fixed the page-turning error (F9) after the report but subsequently introduced an undisclosed output limit of 10,000 certificates. Google Monitor fixed the precertificate parsing error (F7) but clarified that it does not consider itself an RFC 6962 monitor for deep security analysis. Other vendors, like Entrust and crt.sh, did not provide convincing responses or address the reported issues.

Operating Cost and Bloom Filter Protocol:

The trial showed that a light watcher is practical, with an average cost per domain per search period of 1.19MB for downloads, 1.97MB for storage, and 163 seconds for processing. For defending against malicious monitors, a conceptual Bloom filter (BF)-based watcher protocol was proposed. This protocol allows an inquirer to privately verify a servicing monitor's results against reference monitors using BF vectors, without revealing the full set of certificates. This demonstrates a path toward privacy-preserving, deterministic detection of malicious misbehavior, although it increases monitor workload.

The extensive real-world testing and the discovery of numerous, significant flaws underscore the critical need for CT watchers, demonstrating their practical effectiveness in improving the overall reliability of the Certificate Transparency framework.

Defensive Implications

▶ Watch: CT Watchers: Design goals and implementation challenges (4:55)

The findings from this research have profound implications for anyone relying on Certificate Transparency for security, from individual domain owners to large enterprises and security professionals. The core message is clear: third-party CT monitors cannot be blindly trusted to provide a complete and accurate view of certificate issuances. This unreliability creates a significant blind spot, potentially allowing misissued or fraudulent certificates to go undetected.

Here are the key defensive implications and recommended actions:

1. Do Not Solely Rely on Single Third-Party Monitors: Domain owners and security teams should understand that relying on a single third-party CT monitor, or even a few, for comprehensive detection of misissued certificates is insufficient. The demonstrated flaws in popular monitors, including significant service delays, output limits, and parsing errors, mean that critical certificates could be missed.
2. Deploy Independent CT Watchers: For critical domains or organizations with significant security concerns, deploying CT watchers (either light or full versions) is a recommended proactive measure. Operating an independent watcher allows for direct inspection of multiple third-party monitors, enabling detection of inconsistencies and potential misbehavior. This self-operated redundancy provides a layer of assurance that is currently missing from the CT ecosystem.
3. Actively Monitor and Inquire About Monitor QoS: If direct operation of a watcher is not feasible, organizations should actively inquire about the Quality of Service (QoS) information of any third-party monitor they rely on. This includes understanding their reported service delay, output limits, and the specific log servers they monitor. The research recommends a service delay of less than 4 days, aligning with STAR (Short-Term, Automatically Renewed) certificates.
4. Advocate for Standardized Monitor APIs and Disclosures: Defenders should advocate for monitor vendors to adopt the proposed specifications: public disclosure of QoS information and implementation of uniform APIs. Standardized APIs would simplify integration for domain owners and watcher operators, making the ecosystem more robust and transparent.
5. Be Aware of Common Monitor Limitations: Security teams should be acutely aware of the types of flaws identified:

• Service Delays: Certificates might not appear for days or weeks.
• Output Limits: Monitors may only return a partial set of certificates for domains with many issuances.
• Case Sensitivity: Attackers could exploit case-sensitive search implementations to hide certificates for mixed-case domain names.
• IDN Support: Lack of proper support for Internationalized Domain Names (IDNs) can create blind spots.
• Parsing Errors: Issues with vast SANs, redacted certificates, or specific certificate fields can lead to missed entries.
• Paging Errors: Incomplete results when monitors use pagination.
• Short-Lived Certificates: These certificates, often used in automated environments, are particularly prone to being missed.

1. Consider Privacy-Preserving Inspection: For highly sensitive scenarios where revealing one's full set of monitored certificates to multiple third-party monitors is a concern, the proposed Bloom filter (BF)-based watcher protocol offers a promising direction. While still future work, this concept could enable private, deterministic detection of malicious monitor behavior.
2. For Monitor Operators: Self-Inspect and Improve Robustness: Organizations operating their own CT monitors, or those providing commercial monitoring services, should use these findings as a checklist for self-inspection. They should review their certificate collection, indexing, and search logic for vulnerabilities related to:

• Comprehensive log monitoring.
• Robust parsing of diverse certificate structures (e.g., vast SANs, redacted certs, precertificates with special characters).
• Correct handling of validity periods and daylight saving time.
• Case-insensitive matching for domain names.
• Full support for IDNs.
• Reliable pagination and disclosure of output limits.
• Timely indexing and search results, with publicly stated service delays.
• Accurate tagging of certificate statuses (e.g., expired/unexpired).

By taking these proactive and informed steps, defenders can significantly enhance their ability to detect misissued certificates and ensure that the promise of Certificate Transparency is truly realized, rather than being undermined by the very services meant to uphold it.

Key Takeaways

• Third-party CT monitors are frequently unreliable: Despite their critical role in the Certificate Transparency framework, popular third-party monitors often fail to provide complete and accurate search results for certificates, undermining CT's core security objective.
• CT watchers offer a novel and effective solution: The research introduces CT watchers as an independent inspection service that can detect both benign faults and malicious misbehavior in third-party monitors, significantly enhancing the accountability and trustworthiness of the CT ecosystem.
• Widespread flaws were discovered in popular monitors: A real-world trial detected 14 distinct design or implementation issues across six active third-party monitors, leading to approximately 1.4 million cases of missing or irrelevant certificates. These flaws include significant service delays, output limits, case-sensitive searches, and parsing errors.
• Monitor QoS disclosure and API standardization are crucial: To improve cooperation with watchers and overall reliability, monitor vendors should publicly disclose their Quality of Service (QoS) information (service delay, output limit, monitored logs) and adopt uniform APIs for certificate search.
• Defenders must be proactive: Domain owners and security teams cannot passively trust third-party CT monitors. They should consider deploying their own CT watchers for critical domains, actively scrutinize monitor performance, and advocate for improved transparency and robustness from monitor providers.
• Future work includes privacy-preserving inspection: The proposed Bloom filter (BF)-based watcher protocol demonstrates a promising technical route for enabling privacy-preserving detection of malicious monitor behavior, allowing for verification without revealing sensitive certificate sets.

About the Speaker(s)

The research presented in this talk was given by Aozhuo Sun. No additional details regarding their title or company affiliation were provided in the talk metadata or transcript.