While transitioning to an IPv6-only communication, many devices settled on a dual-stack setup. IPv4 and IPv6 are available to these hosts for new connections. Happy Eyeballs (HE) describes a mechanism to prefer IPv6 for such hosts while ensuring a fast fallback to IPv4 when IPv6 fails. The IETF is currently working on the third version of HE. While the standards include recommendations for HE parameter choices, it is up to the client and OS to implement HE. In this paper, we investigate the state of HE in various clients, particularly web browsers and recursive resolvers. We introduce a framework to analyze and measure clients' HE implementations and parameter choices. According to our evaluation, only Safari supports all HE features. Safari is also the only client implementation in our study that uses a dynamic IPv4 connection attempt delay, a resolution delay, and interlaces addresses. We further show that problems with the DNS A record lookup can even delay and interrupt the network connectivity despite a fully functional IPv6 setup with Chrome and Firefox. We operate a publicly available website (www.happy-eyeballs.net) which measures the browser's HE behavior, and we publish our testbed measurement framework.

DNS is one of the cornerstones of the Internet. Nowadays, a substantial fraction of DNS queries are handled by public resolvers (e.g., Google Public DNS and Cisco's OpenDNS) rather than ISP nameservers. This behavior makes it difficult for authoritative nameservers to provide answers based on the requesting resolver. The impact is especially important for entities that make client origin inferences to perform DNS-based load balancing (e.g., CDNS). The EDNS0 Client Subnet (ECS) option adds the client's IP prefix to DNS queries, which allows authoritative nameservers to provide prefix-based responses. Previous work showed the potential of data collected during ECS scans. Infrastructure can be uncovered, and operators' subnet-specific behavior can be observed. In this study, we introduce a new method for conducting ECS scans. Our method significantly reduces the required number of queries by up to 97% compared to state-of-the-art techniques and allows us to provide new insights into ECS behavior. Our approach is also the first to facilitate ECS scans for IPv6. Due to its vast address space, we have developed and analyzed different IPv6 scanning approaches. We conduct a comprehensive evaluation of the ECS landscape, examining the usage and implementation of ECS across various services. Overall, 53% of all nameservers support prefix-based responses. Furthermore, we find that Google nameservers do not comply with the Google Public DNS guidelines. Additionally, we observe that certain operators (e.g., AWS Route53) exclusively employ a single specific scope prefix length without aggregation, potentially affecting resolver cache efficiency. Lastly, we make our tool and data publicly available to foster further research in the area.

QUIC experiences a rapid adoption since its standardization in 2021, and hypergiants configure their infrastructure to optimize for QUIC performance. In this paper, we introduce a passive measurement method to study both the progressive rollout and individual hypergiant configurations during the last five years. By analyzing backscatter traffic of the UCSD network telescope, we are able to make the following observations. First, Meta, Google, and Cloudflare configure significantly different maximal retransmission numbers and timeouts. Second, we can identify different off-net deployments of hypergiants, using packet features, such as QUIC connection IDs, packet coalescence, and packet lengths. Third, we observe changing hypergiant deployment configurations during our different measurement periods. Fourth, connection IDs can allow further insights into load balancer deployments, such as the number of servers. We bolster our results using two orthogonal measurements: passive recording of QUIC flows and active probing.

Active measurements allow the collection of server characteristics on a large scale that can aid in discovering hidden relations and commonalities among server deployments. Finding these relations opens up new possibilities for clustering and classifying server deployments; for example, identifying a previously unknown cybercriminal infrastructure can be valuable cyber-threat intelligence. In this work, we propose a methodology based on active measurements to acquire Transport Layer Security (TLS) metadata from servers and leverage it for fingerprinting. Our fingerprints capture characteristic behavior of the TLS stack, primarily influenced by the server’s implementation, configuration, and hardware support. Using an empirical optimization strategy that maximizes information gained from every handshake to minimize measurement costs, we generated 10 general-purpose Client Hellos. They served as scanning probes to create an extensive database of TLS configurations to classify servers. We propose the Shannon Entropy to measure collected information and compare different approaches. This study fingerprinted 8 million servers from the Tranco top list and two Command and Control (C2) blocklists over 60 weeks with weekly snapshots. The resulting data formed the foundation for two long-term case studies: classification of Content Delivery Network and C2 servers. Moreover, the detection was fine-grained enough to detect C2 server families. The proposed methodology demonstrated a precision of 99% and enabled a stable identification of new servers over time. This study shows how active measurements can provide valuable security-relevant insights and improve our understanding of the Internet.

Today's Internet is dominated by a small number of companies which are responsible for a large fraction of Internet traffic. These so called "hypergiants" make use of off-nets to deploy parts of their infrastructure in ISP networks. Off-nets ensure that clients from these ISPs get lower latencies and the ISP needs to send less traffic to its upstream providers. They have been relatively well studied in the IPv4 Internet, although their footprint in IPv6 remains unclear. In this paper, we take a first look at the IPv6 hypergiant infrastructure. We perform a first-of-its-kind study of IPv6 off-nets for 14 hypergiants and compare their deployment to IPv4. We find IPv6 off-nets in 2k ASes, compared to the more than 6k off-net ASes for IPv4. Moreover, the majority of IPv6 off-nets deployments are seen in ASes which already deploy IPv4 off-nets. Interestingly, we also see some hypergiants such as Disney and Hulu not making use of any IPv6 off-nets at all. We also uncover the phenomenon of cross-hypergiant deployments, where one hypergiant deploys its infrastructure in another hypergiant's network. Finally, we use latency measurements to compare IPv6 vs. IPv4 latency to off-net prefixes within off-net ASes and find similar results for both protocol versions. We make all our code and data available to encourage replicability.

The Internet is shaped by independent actors and heterogeneous deployments. With the wide adoption of Transport Layer Security (TLS), a whole ecosystem of intertwined entities emerged. Acquiring a comprehensive view allows searching for previously unknown malicious entities and providing valuable cyber-threat intelligence. Actively collected Internet-wide Domain Name System (DNS) and TLS meta-data can provide the basis for such large-scale analyses. However, in order to efficiently navigate the vast volumes of data, an effective methodology is required. This work proposes a graph model of the TLS ecosystem that utilizes the relationships between servers, domains, and certificates. A Probabilistic Threat Propagation (PTP) algorithm is then used to propagate a threat score from existing blocklists to related nodes. We conducted a one-year-long measurement study of 13 monthly active Internet-wide DNS and TLS measurements to evaluate the methodology. The latest measurement found four highly suspicious clusters among the nodes with high threat scores. External threat intelligence services were used to confirm a high rate of maliciousness in the rest of the newly found servers. With the help of optimized thresholds, we identified 557 domains and 11 IP addresses throughout the last year before they were known to be malicious. Up to 40% of the identified nodes appeared on average three months later on the input blocklist. This work proposes a versatile graph model to analyze the TLS ecosystem and a PTP analysis to help security researchers focus on suspicious subsets of the Internet when searching for unknown threats.

A global decentral Public Key Infrastructure (PKI) is a key element of trusted and secure communication over the Internet. Such a PKI enables trust inference through digital signatures. However, the irrevocable nature of signatures and the complexities involved in distributing revocation information pose significant challenges. Recent updates to the root store policies of Mozilla and Apple now mandate that each Certificate Authority (CA) must publish Certificate Revocation Lists (CRLs) on the Common CA Database (CCADB) as of October 2022. This policy shift enables new approaches for acquiring a comprehensive view of certificate revocations within the Transport Layer Security (TLS) ecosystem. This work investigates the impact of the new CRLs on certificate revocation research, whether they are sufficient to gain a comprehensive view, and how the current revocation methods compare. We conducted weekly Internet-wide TLS measurements to collect X.509 certificates over port 443 for two years starting in March 2022. These scans resulted in 1.1 billion valid leaf certificates, including 4.5 million revoked certificates we identified using the Online Certificate Status Protocol (OCSP), CRLs, CCADB CRLs, and OCSP stapling. Our findings show that acquiring a comprehensive view of certificate revocations is challenging, primarily via the OCSP. Compared to the other methods, our analyses indicate that the CCADB CRLs provided the most complete view of global certificate revocations. They covered nearly the entirety of valid leaf certificates, found 44% more revocations than alternative methods, and less than 0.3% of the revocations were exclusively visible via the OCSP or conventional CRLs.

The diversity of QUIC implementations poses challenges for Internet measurements and the analysis of the QUIC ecosystem. While all implementations follow the same specification and there is general interoperability, differences in performance, functionality, but also security (e.g., due to bugs) can be expected. Therefore, knowledge about the implementation of an endpoint on the Internet can help researchers, operators, and users to better analyze connections, performance, and security. In this work, we improved the detection rate of QUIC scans to find more deployments and provide an approach to effectively identify QUIC server libraries based on CONNECTION CLOSE frames and transport parameter orders. We performed Internet-wide scans and identified at least one deployment for 18 QUIC libraries. In total, we can identify the libraries with 8.0 M IPv4 and 2.5 M IPv6 addresses. We provide a comprehensive view of the landscape of competing QUIC libraries.

Estimating the capacity of network paths is a frequently and versatilely used technique for network and flow analysis used by service providers and researchers to analyze available bandwidth, performance limitations of connections, or infrastructure deployments. While researchers evaluated different capacity estimation approaches in the early 2000s, there are no recent studies on the accuracy of estimates and capacity deployments in today’s Internet.This paper is purposed to survey the accuracy of actively conducted capacity estimation in today’s Internet. We implement passive packet pair dispersion-based capacity estimation according to the PPrate algorithm and conduct active measurements with TCP and ICMP traffic on controlled targets in the Internet and on public web servers to analyze the accuracy and stability of estimated capacities in the Internet.Our study confirms the general accuracy of PPD-based measurements through the Internet while we observe and discuss impacts by interrupt coalescence, receive offloading, and ICMP rate limiting of middleboxes. Measurements to over 3500 web servers taken from the Alexa top 1M list indicate capacities of at least 1 Gbit/s for the majority of paths to measurement targets, while ICMP-based measurements frequently result in significant underestimation due to ICMP rate limiting.

Internet-wide scans are an important tool to evaluate the deployment of services. To enable large-scale application layer scans, a fast, stateless port scan (e.g., using ZMap) is often performed ahead of time to collect responsive targets. It is a common expectation that port scans on the entire IPv4 address space provide a relatively unbiased view as they cover the complete address space. Previous work, however, has found prefixes where all addresses share particular properties. In IPv6, aliased prefixes and fully responsive prefixes, i.e., prefixes where all addresses are responsive, are a well-known phenomenon. However, there is no such in-depth analysis for prefixes with these responsiveness patterns in IPv4. This paper delves into the underlying factors of this phenomenon in the context of IPv4 and evaluates port scans on a total of 161 ports (142 TCP & 19 UDP ports) from three different vantage points. To account for packet loss and other scanning artifacts, we propose the notion of a new category of prefixes, which we call highly responsive prefixes (HRPs). Our findings show that the share of HRPs can make up 70% of responsive addresses on selected ports. Regarding specific ports, we observe that CDNs contribute to the largest fraction of HRPs on TCP/80 and TCP/443, while TCP proxies emerge as the primary cause of HRPs on other ports. Our analysis also reveals that application layer handshakes to targets outside HRPs are, depending on the chosen service, up to three times more likely to be successful compared to handshakes with targets located in HRPs. To improve future scanning campaigns conducted by the research community, we make our study's data publicly available and provide a tool for detecting HRPs. Furthermore, we propose an approach for a more efficient, ethical, and sustainable application layer target selection. We demonstrate that our approach has the potential to reduce the number of TLS handshakes by up to 75% during an Internet-wide scan while successfully obtaining 99 % of all unique certificates.

Common DNS resolvers are optimized for query latency but are not designed to expose the internal dependencies and structures within the DNS. This makes it difficult to investigate DNS setups, detect errors and misconfigurations, and determine their impact on users.

DNS is one of the core building blocks of the Internet. In this paper, we investigate DNS resolution in a strict IPv6-only scenario and find that a substantial fraction of zones cannot be resolved. We point out, that the presence of an AAAA resource record for a zone's nameserver does not necessarily imply that it is resolvable in an IPv6-only environment since the full DNS delegation chain must resolve via IPv6 as well. Hence, in an IPv6-only setting zones may experience an effect similar to what is commonly referred to as lame delegation. Our longitudinal study shows that the continuing centralization of the Internet has a large impact on IPv6 readiness, i.e., a small number of large DNS providers has, and still can, influence IPv6 readiness for a large number of zones. A single operator that enabled IPv6 DNS resolution -- by adding IPv6 glue records -- was responsible for around 20.3% of all zones in our dataset not resolving over IPv6 until January 2017. Even today, 10% of DNS operators are responsible for more than 97.5% of all zones that do not resolve using IPv6.

Common DNS resolvers are optimized for query latency but are not designed to expose the internal dependencies and structures within the DNS. This makes it difficult to investigate DNS setups, detect errors and misconfigurations, and determine their impact on users. In order to reliably track the internal, potentially cyclic dependencies within the DNS, we propose to split the dependency graph into strongly connected components. By querying all authoritative servers and considering differences in order and timing for repeated runs, we are able to resolve domain names in a repeatable and traceable manner. We validate this approach by introducing a test methodology that allows re-running the resolver against previously recorded data. This data can be used to further study various aspects of global DNS deployments. We provide an example scan with 1.6 M domains on https://tcb-resolve.github.io/.

To keep up with increasing demands on quality of experience, assessing and understanding the performance of network connections is crucial for web service providers. While different measures, like TCP options, alternative transport layer protocols like QUIC, or the hosting of services in CDNs, are expected to improve connection performance, no studies are quantifying such impacts on connections on the Internet. This paper introduces an active Internet measurement approach to assess the impacts of mentioned measures on connection performance. We conduct downloads from public web servers considering different vantage points, extract performance indicators like throughput, RTT, and retransmission rate, and survey speed-ups due to TCP option usage. Further, we compare the performance of QUIC-based downloads to TCP-based downloads considering different option configurations. Next to significant throughput improvements due to TCP option usage, in particular TCP window scaling, and QUIC, our study shows significantly increased performance for connections to domains hosted by different giant CDNs.

Collecting metadata from Transport Layer Security (TLS) servers on a large scale allows to draw conclusions about their capabilities and configuration. This provides not only insights into the Internet but it enables use cases like detecting malicious Command and Control (C&C) servers. However, active scanners can only observe and interpret the behavior of TLS servers, the underlying configuration and implementation causing the behavior remains hidden. Existing approaches struggle between resource intensive scans that can reconstruct this data and light-weight fingerprinting approaches that aim to differentiate servers without making any assumptions about their inner working. With this work we propose DissecTLS, an active TLS scanner that is both light-weight enough to be used for Internet measurements and able to reconstruct the configuration and capabilities of the TLS stack. This was achieved by modeling the parameters of the TLS stack and derive an active scan that dynamically creates scanning probes based on the model and the previous responses from the server. We provide a comparison of five active TLS scanning and fingerprinting approaches in a local testbed and on toplist targets. We conducted a measurement study over nine weeks to finger-print C&C servers and analyzed popular and deprecated TLS parameter usage. Similar to related work, the fingerprinting achieved a maximum precision of 99% for a conservative detection threshold of 100 %; and at the same time, we improved the recall by a factor of 2.8.

The diversity of QUIC implementations poses challenges for Internet measurements and the analysis of the QUIC ecosystem. While all implementations follow the same specification and there is general interoperability, differences in performance, functionality, but also security (e.g., due to bugs) can be expected. Therefore, knowledge about the implementation of an endpoint on the Internet can help researchers, operators, and users to better analyze connections, performance, and security. In this work, we improved the detection rate of QUIC scans to find more deployments and provide an approach to effectively identify QUIC server libraries based on CONNECTION CLOSE frames and transport parameter orders. We performed Internet-wide scans and identified at least one deployment for 18 QUIC libraries. In total, we can identify the libraries with 8.0 M IPv4 and 2.5 M IPv6 addresses. We provide a comprehensive view of the landscape of competing QUIC libraries.

Honeypots are a widely used technique to observe the spread of malware and the emergence of new exploits. Attackers try to avoid connecting to honeypots as they reveal the attacker's methods, tools, and exploits. While different honeypot implementations have been fingerprinted in the past, we see a lack of studies covering Windows-related protocols such as Remote Desktop Protocol (RDP) and Server Message Block (SMB) honeypots. However, these protocols have seen at least two major security vulnerabilities in the past 5 years and are commonly exploited. We adapted existing fingerprinting algorithms to allow an accurate identification of RDP and SMB honeypots checking how implementations behave in error conditions. We present a new improvement, namely the inclusion of system TLS stack features previously not used for honeypot detection. We are the first to perform an internet-wide scan searching for RDP and SMB honeypots. We are able to effectively uncover the presence of two common open-source honeypots for RDP and SMB each. We identified 84 instances of Heralding (RDP), 1123 instances of RDPY (RDP), 60 instances of Impacket (SMB), and 1461 instances of Dionaea (SMB) during our scans. Furthermore, we found several hosts, which do not use Microsoft's SChannel TLS stack, but advertise themselves as Windows machines. This indicates the presence of a Man-in-the-Middle (MitM) box and could be a sign of a honeypot. Eventually, we analyzed how attackers interact with detectable honeypots. We deployed instances of RDP honeypots ourselves and found that credential guessing attackers seem to avoid them. This proves that RDP and SMB honeypots are finger-printable and that even MitM-box-based high-interaction honeypots leave detectable traces.

In this paper, we study the potentials of passive measurements to gain advanced knowledge about QUIC deployments. By analyzing one month backscatter traffic of the /9 CAIDA network telescope, we are able to make the following observations. First, we can identify different off-net deployments of hypergiants, using packet features such as QUIC source connection IDs (SCID), packet coalescence, and packet lengths. Second, Facebook and Google configure significantly different retransmission timeouts and maximum number of retransmissions. Third, SCIDs allow further insights into load balancer deployments such as number of servers per load balancer. We bolster our results by active measurements.