This paper describes the multi-year effort undertaken by Mozilla to incorporate and deploy CRLite, a TLS certificate revocation checking system, in the Firefox browser. With the deprecation of the Online Certificate Status Protocol (OCSP) by Let's Encrypt and others, CRLite is now the only broadly deployed mechanism capable of checking the revocation status of every TLS certificate. The successful seven-year evolution of CRLite from a research prototype to a widely used tool required improvements in the original data structures (now using partitioned Ribbon filters), changes in Certificate Authority revocation practices, and correctly synchronizing with Certificate Transparency logs to eliminate false positives. Using data from Firefox's opt-in telemetry, we report that CRLite achieves an effective revocation coverage of 87.8% while maintaining moderate bandwidth costs, even during real revocation events like the November 2025 Microsoft incident. Through simulations, we also examine the potential impacts of shorter certificate lifetimes and hypothetical mass revocations on CRLite. CRLite demonstrates that low-latency, private, comprehensive certificate revocation checking is possible using moderate bandwidth.

Email has been a cornerstone of online communication for decades, but its lack of built-in confidentiality has left it vulnerable to various attacks. To address this issue, two key protocols are being used: MTA-STS (Mail Transfer Agent Strict Transport Security) and DANE (DNS-based Authentication of Named Entities). While DANE was introduced first, MTA-STS has been actively adopted by major email providers like Google and Microsoft, as it does not require the complex DNSSEC chain that poses a significant challenge in deploying and managing DANE. However, despite its significance, there has been limited research on how MTA-STS is deployed and managed in practice. In this study, we present a thorough, longitudinal investigation of the MTA-STS ecosystem. We base our analysis on a dataset capturing over 87 million domains from DNS scans collected across four TLDs over 31 months, along with 10 months of additional component scanning such as TLS certificates, thereby offering a broad perspective on MTA-STS adoption and its management. Our analysis uncovers a concerning trend of misconfigurations and inconsistencies in MTA-STS setups. In our most recent snapshot, out of ~68K domains with MTA-STS record, 29.6% of domains were incorrectly configured, while 3.2% of these should encounter email delivery failure from MTA-STS supporting senders. To gain insights into the challenges faced by email administrators, we surveyed 117 operators. While awareness of MTA-STS was high (94.7%), many cited operational complexity (48.8%) and a preference for DANE (45.4%) as reasons for not deploying the protocol. Our study not only highlights the growing importance of MTA-STS but also reveals the significant challenges in its deployment and management.

Low adoption and high misconfiguration rates continue to blunt the security benefits of DNSSEC. Drawing on 1.1M historical diagnostic snapshots covering 319K second-level and their subdomains between 2020 and 2024 from the DNSViz service, this paper delivers the first longitudinal, data-driven taxonomy of real-world DNSSEC failures. The study shows that NSEC3 misconfigurations, delegation failures and missing/expired signatures account for more than 70% of all bogus states, and that 18% of such domains remain broken.

The Online Certificate Status Protocol's long slide—after 25 years of soft-fail rules, privacy leakage, and shaky infrastructure—exposes a deeper failure in web-PKI revocation. Certificate Authorities increasingly route OCSP traffic through CDNs for speed, yet this recentralizes trust: our measurements show Akamai serves 62 percent of all revocation responses, creating single points of failure and betraying PKI's decentralized ideals.

Certificate revocation is essential for maintaining the security of the Public Key Infrastructure (PKI), ensuring that compromised or untrustworthy certificates are invalidated promptly. Traditional revocation mechanisms like Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) face significant challenges, including scalability issues, high bandwidth consumption, privacy concerns, and reliance on centralized infrastructure that can become points of failure. In this paper, we introduce AccuRevoke, a novel revocation scheme that leverages cryptographic accumulators and edge computing to address these challenges effectively. Accu Revoke enables clients to verify the revocation status of certificates efficiently without the need to contact Certificate Authorities (CAs) directly for each validation. By utilizing distributed accumulators and threshold cryptography, Accu Revoke ensures authenticity and integrity of revocation information, even when responses are generated by third-party Edge Compute Providers (ECPs). Our scheme significantly reduces bandwidth consumption by providing compact revocation proofs-approximately 21 bytes for membership proofs and 61 bytes for non-membership proofs-which are substantially smaller than traditional OCSP responses. To further optimize performance, especially in generating non-membership witnesses, we employ GPU acceleration, achieving considerable improvements in processing times. We compare AccuRevoke with existing revocation mechanisms, demonstrating advantages in bandwidth efficiency, reliability, auditability, and potential enhancements in privacy. Our evaluation shows that Accu Revoke offers a scalable and practical solution for revocation checking, improving the security and performance of TLSIPKI deployments. We plan to open-source our design and implementation to facilitate adoption and encourage further research in this area.

Deepfake or synthetic images produced using deep generative models pose serious risks to online platforms. This has triggered several research efforts to accurately detect deepfake images, achieving excellent performance on publicly available deepfake datasets. In this work, we study 8 state-of-the-art detectors and argue that they are far from being ready for deployment due to two recent developments. First, the emergence of lightweight methods to customize large generative models, can enable an attacker to create many customized generators (to create deepfakes), thereby substantially increasing the threat surface. We show that existing defenses fail to generalize well to such user-customized generative models that are publicly available today. We discuss new machine learning approaches based on content-agnostic features, and ensemble modeling to improve generalization performance against user-customized models. Second, the emergence of vision foundation models—machine learning models trained on broad data that can be easily adapted to several downstream tasks—can be misused by attackers to craft adversarial deepfakes that can evade existing defenses. We propose a simple adversarial attack that leverages existing foundation models to craft adversarial samples without adding any adversarial noise, through careful semantic manipulation of the image content. We highlight the vulnerabilities of several defenses against our attack, and explore directions leveraging advanced foundation models and adversarial training to defend against this new threat.

When using a Content Delivery Network (CDN), domain owners typically delegate Transport Layer Security (TLS) authentication to the CDN by sharing their TLS certificate’s private key. However, this practice not only delegates TLS authentication but also grants the CDN complete control over the certificate. To mitigate these concerns, Delegated Credential (DC) was proposed as a solution; DC, which contains both the CDN’s public key and the domain owner’s signature, allows the domain owners to delegate their own credentials for TLS authentication, thereby avoiding the need to share their private keys. However, the absence of a mechanism to distribute the revocation status of a DC renders it non-revocable, even when a compromise of a credential has been detected. DCs were thus designed to be short-lived, necessitating frequent renewal for continued use.

When a root certificate authority (CA) in the Web PKI misbehaves, primary root-store operators such as Mozilla and Google respond by distrusting that CA. However, full distrust is often too broad, so root stores often implement partial distrust of roots, such as only accepting a root for a subset of domains. Unfortunately, derivative root stores (e.g., Debian and Android) that mirror decisions made by primary root stores are often out-of-date and cannot implement partial distrust, leaving TLS applications vulnerable.

The Resource Public Key Infrastructure (RPKI) is a system to add security to the Internet routing. In recent years, the publication of Route Origin Authorization (ROA) objects, which bind IP prefixes to their legitimate origin ASN, has been rapidly increasing. However, ROAs are effective only if the routers use them to verify and filter invalid BGP announcements, a process called Route Origin Validation (ROV).

Google and Apple jointly introduced a digital contact tracing technology and an API called "exposure notification,'' to help health organizations and governments with contact tracing. The technology and its interplay with security and privacy constraints require investigation. In this study, we examine and analyze the security, privacy, and reliability of the technology with actual and typical scenarios (and expected typical adversary in mind), and quite realistic use cases. We do it in the context of Virginia's COVIDWISE app. This experimental analysis validates the properties of the system under the above conditions, a result that seems crucial for the peace of mind of the exposure notification technology adopting authorities, and may also help with the system's transparency and overall user trust.

This paper proposes using a logic programming language to disentangle X.509 certificate validation policy from mechanism. Expressing validation policies in a logic programming language provides multiple benefits. First, policy and mechanism can be more independently written, augmented, and analyzed compared to the current practice of interweaving them within a C or C++ implementation. Once written, these policies can be easily shared and modified for use in different TLS clients. Further, logic programming allows us to determine when clients differ in their policies and use the power of imputation to automatically generate interesting certificates, e.g., a certificate that will be accepted by one browser but not by another.

TLS certificate pinning is a security mechanism used by applications (apps) to protect their network traffic against malicious certificate authorities (CAs), in-path monitoring, and other methods of TLS tampering. Pinning can provide enhanced security to defend against malicious third-party access to sensitive data in transit (e.g., to protect sensitive banking and health care information), but can also hide an app's personal data collection from users and auditors. Prior studies found pinning was rarely used in the Android ecosystem, except in high-profile, security-sensitive apps; and, little is known about its usage on iOS and across mobile platforms.

The couplings between IP addresses, names of content or services, and socket interfaces, are too tight. This impedes system manageability, growth, and overall provisioning. In turn, large-scale content providers are forced to use staggering numbers of addresses, ultimately leading to address exhaustion (IPv4) and inefficiency (IPv6).

The DNS Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System (DNS), the naming system of the Internet. With DNSSEC, signatures are added to the information provided in the DNS using public key cryptography. Advances in both cryptography and cryptanalysis make it necessary to deploy new algorithms in DNSSEC, as well as deprecate those with weakened security. If this process is easy, then the protocol has achieved what the IETF terms "algorithm agility".

The public key infrastructure (PKI) provides the fundamental property of authentication: the means by which users can know with whom they are communicating online. The PKI ensures end-to-end authenticity insofar as it verifies a chain of certificates, but the true final step in end-to-end authentication comes when the user verifies that the website is what they expect. To this end, users are expected to evaluate domain names, but various "domain impersonation" attacks threaten their ability to do so. Indeed, if a user could be easily tricked into believing that amazon.com-offers.com is actually amazon.com, then, coupled with security indicators like a lock icon, users could believe that they have a secure connection to Amazon.

Despite its critical role in Internet connectivity, the Border Gateway Protocol (BGP) remains highly vulnerable to attacks such as prefix hijacking, where an Autonomous System (AS) announces routes for IP space it does not control. To address this issue, the Resource Public Key Infrastructure (RPKI) was developed starting in 2008, with deployment beginning in 2011. This paper performs the first comprehensive, longitudinal study of the deployment, coverage, and quality of RPKI. We use a unique dataset containing all RPKI Route Origin Authorizations (ROAs) from the moment RPKI was first deployed, more than 8 years ago. We combine this dataset with BGP announcements from more than 3,300 BGP collectors worldwide. Our analysis shows the after a gradual start, RPKI has seen a rapid increase in adoption over the past two years. We also show that although misconfigurations were rampant when RPKI was first deployed (causing many announcements to appear as invalid) they are quite rare today. We develop a taxonomy of invalid RPKI announcements, then quantify their prevalence. We further identify suspicious announcements indicative of prefix hijacking and present case studies of likely hijacks. Overall, we conclude that while misconfigurations still do occur, RPKI is "ready for the big screen," and routing security can be increased by dropping invalid announcements. To foster reproducibility and further studies, we release all RPKI data and the tools we used to analyze it into the public domain.

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers.

The domain name system (DNS) is the naming system on the Internet. With the DNS security extensions (DNSSECs) operators can protect the authenticity of their domain using public key cryptography. DNSSEC, however, can be difficult to configure and maintain: operators need to replace keys to upgrade their algorithm, react to security breaches or follow key management policies. These tasks are not trivial. If operators do not time changes to their keys right, caching resolvers may not have access to the correct keys, potentially rendering DNS zones unavailable for minutes or hours. While best current practices give abstract guidelines on how to introduce and withdraw keys, information on how to monitor and control actual rollovers in a live environment is lacking. More specifically, it is challenging for operators to know when to introduce or withdraw keys based on the state of the network. Our main contribution is to help operators answer this question and to address this barrier for deploying DNSSEC. We develop a method with which operators can monitor the replacement of DNSSEC keys, called a rollover. Thereby, they can make confident decisions during the rollover and make sure their zone stays available at all times. We validate the method with an algorithm rollover of the Swedish TLD .se and provide an open source tool with which operators can monitor their rollover themselves.

The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC's deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed.

Event-based social networks (EBSNs) are increasingly popular since they provide platforms on which online and offline activities are combined. Despite the increasing interest in EBSNs, little research has paid attention to the privacy issues coming from the unique features of EBSNs; the on-site information of users is highly relevant to real lives. In this paper, we try to investigate privacy leakages in Meetup, one of the most popular EBSN service. More specifically, we answer what private information can be inferred from the site's publicly available data. To this end, we conduct a measurement study by crawling webpages from Meetup containing 240K groups, 8.9M users, 27M group affiliations and 78M topical interests. By analyzing the dataset, we find that LGBT status of users, which is one of the most sensitive privacy information, can be predicted with 93% accuracy. Finally we discuss the cause of the privacy leakage on EBSNs and its possible ensuing damages.

The semantics of online authentication in the web are rather straightforward: if Alice has a certificate binding Bob's name to a public key, and if a remote entity can prove knowledge of Bob's private key, then (barring key compromise) that remote entity must be Bob. However, in reality, many websites' and the majority of the most popular ones-are hosted at least in part by third parties such as Content Delivery Networks (CDNs) or web hosting providers. Put simply: administrators of websites who deal with (extremely) sensitive user data are giving their private keys to third parties. Importantly, this sharing of keys is undetectable by most users, and widely unknown even among researchers. In this paper, we perform a large-scale measurement study of key sharing in today's web. We analyze the prevalence with which websites trust third-party hosting providers with their secret keys, as well as the impact that this trust has on responsible key management practices, such as revocation. Our results reveal that key sharing is extremely common, with a small handful of hosting providers having keys from the majority of the most popular websites. We also find that hosting providers often manage their customers' keys, and that they tend to react more slowly yet more thoroughly to compromised or potentially compromised keys.

Named Data Networking (NDN) uses content names as routing entries, and thus the scalability of NDN routing is of primary concern. NDN allows in-network caching as a built-in functionality; however, if network nodes make caching decisions individually, duplicate copies of the same content may exist among nearby nodes. To address these problems, we propose Coordinated Routing and Caching (CoRC) that mitigates routing scalability and enhances the efficiency of the in-network storage. CoRC aligns the routing and caching mechanisms to manage the same content namespace for better performance. We evaluate CoRC (and its variants) with Vanilla NDN in terms of the cache hit ratio, hop count, and traffic load by running software routers on Amazon EC2. To demonstrate the feasibility of CoRC, we also implement and test the processing time of CoRC forwarding in Linux machines.

Named Data Networking (NDN) routers can cache previously forwarded Data packets, and those can be reused when a matching Interest packet arrives. Unlike traditional IP routers and HTTP caches that exist as separate devices, designing a scalable NDN router is a new challenge because it should perform fast forwarding and massive-scale caching at the same time. This paper proposes a design of an NDN router with unique forwarding and caching mechanisms featuring terabyte-scale caching with solid-state drives (SSD) while still forwarding packets at line speed.

Understanding the group characteristics in MMORPGs is important in user behavior studies since people tend to gather together and form groups due to their inherent nature. In this paper, we analyze the group activities of users in Aion, one of the largest MMORPGs, based on the records of the activities of 94,497 users. In particular, we focus on (i) how social interactions within a group differ from the ones across groups, (ii) what makes a group rise, sustain, or fall, (iii) how group members join and leave a group, and (iv) what makes a group end. We first find that structural patterns of social interactions within a group are more likely to be close-knit and reciprocative than the ones across groups. We also observe that members in a rising group (i.e., the number of members increases) are more cohesive, and communicate with more evenly within the group than the ones in other groups. Our analysis further reveals that if a group is not cohesive, not actively communicating, or not evenly communicating among members, members of the group tend to leave.

We conduct comprehensive measurements on the current practice of content bundling to understand the structural patterns of torrents and the participant behaviors of swarms on one of the largest BitTorrent portals: The Pirate Bay. From the datasets of the 120K torrents and 14.8M peers, we investigate what constitutes torrents and how users participate in swarms from the perspective of bundling, across different content categories: Movie, TV, Porn, Music, Application, Game and E-book. In particular, we focus on: (1) how prevalent content bundling is, (2) how and what files are bundled into torrents, (3) what motivates publishers to bundle files, and (4) how peers access the bundled files. We find that over 72% of BitTorrent torrents contain multiple files, which indicates that bundling is widely used for file sharing. We reveal that profit-driven BitTorrent publishers who promote their own web sites for financial gains like advertising tend to prefer to use the bundling. We also observe that most files (94%) in a bundle torrent are selected by users and the bundle torrents are more popular than the single (or non-bundle) ones on average. Overall, there are notable differences in the structural patterns of torrents and swarm characteristics (i) across different content categories and (ii) between single and bundle torrents.

BitTorrent has achieved a great success in the field of peer-to-peer (P2P) file sharing. Although BitTorrent allows peers to share files efficiently and scalably, it shows inefficiency when a client participates in multiple torrents where each of them concurrently competing for the limited link bandwidth. In this paper, we propose a new bandwidth allocation algorithm, which greedily increases the bandwidth consumption for downloading, to reduce file transfer time considering the current download/upload status. To compensate overall performance degradation resulting from our greedy allocation, we suggest modifying the choking algorithm of BitTorrent to consider the ratio of seeders and leechers in each torrent. Through comprehensive experiments, we validate the performance gain of the proposed scheme over original BitTorrent in a mix of WiFi and Ethernet testbed and large scale public torrents.

Despite the increasing interest in content bundling in BitTorrent systems, there are still few empirical studies on the bundling practice in real BitTorrent communities. In this paper, we conduct comprehensive measurements on one of the largest BitTorrent portals: The Pirate Bay. From the torrents data set collected for 38 days from April to May, 2010, we study how prevalent bundling is and how many files are bundled in a torrent, across different types of contents shared: Movie, Porn, TV, Music, Application, E-book, and Game.