The reviewed record of science sign in
Pith

arxiv: 2607.06134 · v1 · pith:QIUIB7GY · submitted 2026-07-07 · cs.CR

Poster: Mind the Gap -- Characterizing the Temporal Blind Spot Between GSB and DNS Resolution

Tomer Gal , Fujiao Ji , Doowon Kim , Harel Israel Berger This is my paper

Reviewed by Pith T0 review T1 audit T2 compute T3 formal T4 kernel 2026-07-08 15:24 UTCglm-5.2pith:QIUIB7GYrecord.jsonopen to challenge →

classification cs.CR
keywords resolutiontemporaltimingbrowserbrowsingcname-domaindelaysgsb-related
0
0 comments X

The pith

DNS lags behind Safe Browsing checks 79% of the time

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper measures a timing gap between Google Safe Browsing (GSB) connection closures and final DNS resolution responses during browser navigation. Using packet captures in Chrome across 203 domains, the authors find that in roughly 79% of cases the DNS response arrives after the GSB-related connection has closed, with median delays of 67-79 ms and maxima exceeding 2.4 seconds. The central object is the timing gap metric, defined as the difference between the transport-layer closure timestamp of the GSB-related TLS stream and the arrival timestamp of the final DNS A/AAAA record. The authors argue this gap creates a security-relevant precondition: if an adversary can manipulate DNS resolution (via cache poisoning, resolver manipulation, or on-path position), the browser may reach a safety decision before the final network endpoint is fully established, potentially creating a mismatch between the domain that was checked and the endpoint that is ultimately contacted. The paper does not claim a complete browser bypass but identifies the timing precondition as a foundation for further end-to-end attack validation.

Core claim

The paper's central empirical finding is that a positive timing gap between GSB-related query close events and final DNS resolution is not an anomaly but a recurring feature of standard browsing, appearing in approximately 78-80% of measured navigations across both general and CNAME-domain datasets. The gap exhibits a long-tail distribution: most instances are under 100 ms, but outliers exceed two seconds. This means there is a measurable, frequently occurring window in which the browser's safety-check infrastructure has concluded its connection-level interaction while DNS resolution is still in progress, leaving the final endpoint determination unresolved at the moment the safety check is (

What carries the argument

The timing gap metric is defined as the difference between the timestamp of the TCP FIN or RST packet closing the GSB-related TLS connection (identified via SNI) and the timestamp of the final DNS A/AAAA response packet. For CNAME chains, the final record in the resolution sequence is used. The measurement pipeline clears DNS cache and browser state before each navigation, launches Chrome to navigate to a target domain, captures traffic with Tshark, and post-processes the trace to extract both timestamps.

If this is right

  • If the timing gap is confirmed as security-relevant, browser vendors may need to bind Safe Browsing decisions to the final resolved DNS endpoint rather than to the domain name alone, or trigger revalidation when DNS resolution completes after the initial safety check.
  • CNAME-heavy domains, which require multi-step DNS resolution, may be disproportionately exposed to timing-gap exploitation due to longer resolution chains extending the window.
  • The long-tail delays exceeding two seconds suggest that even low-frequency, high-latency DNS resolutions could create exploitable windows for targeted attacks against specific domains.
  • The measurement methodology could be extended to non-Chromium browsers to determine whether the timing gap is browser-specific or reflects a fundamental architectural issue in how safety checks and DNS resolution are scheduled.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The use of TCP FIN/RST as a proxy for GSB check completion is an indirect measurement: the browser may have completed its local hash-prefix evaluation and reached a safety decision well before or after the connection closes, meaning the measured gap could overstate or understate the true decision-to-resolution window. A controlled experiment instrumenting the browser's internal GSB API calls would
  • The security relevance depends on whether the GSB check result is bound to the domain name or to the resolved IP address. If GSB decisions are domain-based and DNS manipulation changes the IP while preserving the domain, the timing gap may be less exploitable than if the browser binds safety decisions to IP-level endpoints.
  • The 21% of cases with non-positive gaps (DNS resolving before GSB connection closure) may themselves be security-relevant, as they represent scenarios where the endpoint is determined before the safety check completes, potentially creating a different class of timing mismatch.

Load-bearing premise

The paper assumes that the TCP FIN or RST packet closing the GSB-related TLS connection is a meaningful proxy for when the browser completes its safety check. Transport-layer connection closure does not necessarily correspond to the browser's internal safety decision point, which may be cached locally or completed at a different stage of the navigation pipeline. If FIN/RST timing does not track the actual safety decision, the measured gap reflects connection teardown behavior

What would settle it

If browser instrumentation showing the actual internal timestamp of the GSB safety decision were compared against the FIN/RST timestamp and the two diverged systematically, the measured timing gap would be an artifact of connection lifecycle semantics rather than a security-relevant window.

read the original abstract

Google Safe Browsing (GSB) and DNS resolution operate concurrently during browser navigation, yet their packet-level synchronization remains understudied. This work characterizes the timing gap (\(\Delta_{time}\)) between GSB-related query close events and parallel DNS resolution responses, identifying a consistent temporal offset with potential security relevance. Using packet-capture analysis across general and CNAME-domain datasets, we observe positive timing gaps in approximately 79\% of measurements. In these instances, DNS responses lag behind GSB-related query closures with median delays of 67-79 ms and maximum delays surpassing 2,400 ms. These empirical results highlight a measurable window within the browsing workflow. We suggest that such temporal inconsistencies, particularly in complex CNAME-domain resolutions, may create a security-relevant timing precondition under DNS-manipulation threat models. These results provide a foundation for further research into timing-based risks and mitigations in browser safety mechanisms.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 5 minor

Summary. This poster paper characterizes the timing gap between Google Safe Browsing (GSB)-related connection close events and final DNS resolution events during browser navigation. The authors define a metric Δ_time = T_resolution − T_query_close, where T_query_close is the TCP FIN/RST of a GSB-related TLS stream (identified via SNI) and T_resolution is the final DNS A/AAAA response. Using packet-capture on a single macOS workstation running Chrome Stable, the authors measure this gap across 100 general-domain and 103 CNAME-domain websites from the Tranco list. They report positive timing gaps (DNS lagging behind GSB closure) in approximately 78–80% of samples, with median delays of 67–79 ms and maxima exceeding 2,400 ms. The paper frames these gaps as a potential security-relevant precondition under DNS-manipulation threat models, while explicitly disclaiming a complete browser bypass.

Significance. The paper identifies a measurable and previously undercharacterized timing phenomenon at the packet level between GSB-related traffic and DNS resolution. The metric is parameter-free and directly computed from observed timestamps, which is a strength. The datasets are clearly described, and the results are reproducible in principle given the methodology. The security framing is appropriately cautious—the authors do not overclaim a bypass. However, the significance is substantially limited by the causal linkage problem (see major comments) and the single-machine, single-browser measurement design, which constrains generalizability.

major comments (3)
  1. §3.1, Eq. (1): The central claim—that the measured Δ_time represents a security-relevant timing window—depends on both T_query_close and T_resolution belonging to the same causal navigation chain. The paper does not establish that the GSB-related TLS connection (identified via SNI) corresponds to the specific safety check the browser used for the target navigation, nor that the DNS response captured is the one the browser actually consumed for the connection. Chrome performs background GSB database updates and speculative DNS prefetching that may be unrelated to the navigation being measured. Without correlating these events to a single navigation (e.g., via browser-internal timing APIs or per-navigation request IDs), the measured gap may compare unrelated asynchronous events. This is load-bearing for the security claim in §6.
  2. §3.1: The use of TCP FIN/RST as a proxy for GSB check completion is not validated. The paper states T_query_close is 'the timestamp of the associated TCP FIN or RST packet,' but transport-layer connection teardown does not necessarily correspond to the browser's safety decision point. The browser may complete its GSB evaluation before or after the connection closes, and the GSB check may be satisfied from a local cache without a server round-trip at all. If FIN/RST timing does not track the actual safety decision, the measured gap is an artifact of connection teardown semantics. The paper should either validate this proxy or substantially soften the security framing.
  3. §5.2, Table 2: The 79% positive-gap rate is itself surprising. DNS resolution is a prerequisite for establishing the TLS connection to the target domain, so one would expect DNS to typically complete before GSB-related traffic for the same navigation. The high frequency of DNS-lagging-behind-GSB suggests the captured DNS responses may be secondary events (cache refreshes, prefetch completions, CNAME chain continuations) rather than the resolution the browser actually used. The paper should address this apparent counterintuitiveness directly, as it bears on whether the measured gaps are security-relevant or artifacts of background activity.
minor comments (5)
  1. §4: The measurement is conducted on a single macOS workstation with Chrome Stable. While the authors acknowledge this limitation in §7 (Future Work), the generalizability concern should be discussed more prominently in the results section, as all quantitative claims derive from this single configuration.
  2. Table 1: The absolute timestamps (e.g., 1.426 s, 6.847 s) appear to be relative to capture start, but this is not stated. A brief note on the reference point for these timestamps would improve clarity.
  3. §3.2: The CNAME-domain selection criteria are described as 'the highest-ranked entries that explicitly require CNAME resolution.' It would help to specify how CNAME requirement was determined (e.g., manual inspection, automated DNS query).
  4. §5.1: The text states 'positive timing gaps appear in approximately 78%–80% of measured samples, with median delays around 70 ms,' but Table 2 reports medians of 79.40 ms and 67.88 ms. Rounding to 'around 70 ms' is acceptable for the abstract but slightly imprecise for the results section.
  5. §2.2: The threat model mentions 'cache poisoning, resolver manipulation, or an on-path position' but does not discuss whether the browser's DNS cache or OS-level resolver cache (which were cleared before each navigation per §4) would still be warm during the measurement, potentially affecting the gap. This interaction should be clarified.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for a careful and substantive review. The three major comments all identify the same underlying concern from different angles: without establishing that the GSB-related connection close and the DNS response belong to the same causal navigation chain, the measured Δ_time may compare unrelated asynchronous events, undermining the security framing. We agree this is the central limitation of the current manuscript and will revise accordingly.

read point-by-point responses

  1. Referee: §3.1, Eq. (1): The central claim—that the measured Δ_time represents a security-relevant timing window—depends on both T_query_close and T_resolution belonging to the same causal navigation chain. The paper does not establish that the GSB-related TLS connection (identified via SNI) corresponds to the specific safety check the browser used for the target navigation, nor that the DNS response captured is the one the browser actually consumed for the connection. Chrome performs background GSB database updates and speculative DNS prefetching that may be unrelated to the navigation being measured. Without correlating these events to a single navigation (e.g., via browser-internal timing APIs or per-navigation request IDs), the measured gap may compare unrelated asynchronous events. This is load-bearing for the security claim in §6.

    Authors: The referee is correct that the current manuscript does not establish causal linkage between the GSB-related connection and the DNS response for a single navigation. This is a genuine limitation of our packet-capture-only methodology. SNI-based identification of GSB traffic cannot distinguish a navigation-triggered safety check from background database updates, and the captured DNS response may be a prefetch or cache-refresh event rather than the resolution the browser consumed for the target connection. We will address this in two ways. First, we will add an explicit limitations subsection acknowledging that without browser-internal correlation (e.g., Chrome's net-internals tracing or the Performance Timeline API), we cannot confirm that the two timestamps belong to the same navigation chain. Second, we will conduct a supplementary measurement using Chrome's --log-net-log flag to emit per-request timing metadata, allowing us to correlate the GSB-related request and the DNS resolution to a specific navigation ID. If this correlation confirms that the gap persists for same-navigation events, the security framing is strengthened; if it does not, we will report that finding honestly and substantially soften the security claims in §6. In either case, the revised manuscript will not present Δ_time as a security-relevant window without this validation. revision: yes

  2. Referee: §3.1: The use of TCP FIN/RST as a proxy for GSB check completion is not validated. The paper states T_query_close is 'the timestamp of the associated TCP FIN or RST packet,' but transport-layer connection teardown does not necessarily correspond to the browser's safety decision point. The browser may complete its GSB evaluation before or after the connection closes, and the GSB check may be satisfied from a local cache without a server round-trip at all. If FIN/RST timing does not track the actual safety decision, the measured gap is an artifact of connection teardown semantics. The paper should either validate this proxy or substantially soften the security framing.

    Authors: We agree that FIN/RST timing is an imperfect proxy for the browser's safety decision point. The GSB check may be satisfied from the local hash-prefix database without any server round-trip, in which case there would be no GSB-related TLS connection to observe at all — meaning our metric only applies to the subset of navigations where a prefix match triggers a server query. Even in that subset, the browser may reach its safety decision before the connection closes (e.g., after receiving the response body but before FIN), or the connection may be kept alive for reuse rather than closed promptly. We will revise the manuscript to: (1) explicitly state that T_query_close measures connection teardown, not the safety decision itself, and that the relationship between the two is not established; (2) note that the metric is conditional on a server-side GSB query occurring, which is itself a subset of all navigations; and (3) soften the language in §6 from 'a Safe Browsing-related decision may complete before DNS resolution' to 'the GSB-related connection closes before the observed DNS response arrives,' which is what the data actually shows. We will also explore whether Chrome's net-log can provide a more direct timestamp for the safety decision, though we note that the browser's internal GSB decision timing may not be directly exposed even in detailed logs. revision: yes

  3. Referee: §5.2, Table 2: The 79% positive-gap rate is itself surprising. DNS resolution is a prerequisite for establishing the TLS connection to the target domain, so one would expect DNS to typically complete before GSB-related traffic for the same navigation. The high frequency of DNS-lagging-behind-GSB suggests the captured DNS responses may be secondary events (cache refreshes, prefetch completions, CNAME chain continuations) rather than the resolution the browser actually used. The paper should address this apparent counterintuitiveness directly, as it bears on whether the measured gaps are security-relevant or artifacts of background activity.

    Authors: This is the most challenging comment, and we acknowledge it raises a serious concern about the validity of our measurement. The referee's observation is correct: if the captured DNS response were the one the browser consumed to establish the target TLS connection, it should appear before the connection close, not after, in the majority of cases. The fact that 79% of measurements show DNS lagging behind GSB closure is indeed consistent with the hypothesis that the captured DNS responses are secondary events — cache refreshes, speculative prefetch completions, or later stages of CNAME chain resolution — rather than the resolution that enabled the navigation. We cannot rule this out with the current methodology. We will address this directly in the revised manuscript by: (1) adding a dedicated discussion of this counterintuitive result and its implications; (2) acknowledging that the high positive-gap rate may be an artifact of capturing background DNS activity rather than navigation-critical resolution; and (3) reporting the results of the net-log correlation experiment described in our response to the first major comment, which will allow us to determine whether the DNS response that the browser actually consumed for the target connection also exhibits a positive gap. If the correlated measurements show a substantially lower positive-gap rate, this would confirm that the current 79% figure is inflated by background activity, and we will report this transparently. We will not maintain the current security framing if the correlation experiment does not support it. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical measurement study with parameter-free metric and no self-citation load-bearing chain

full rationale

This is an empirical measurement poster with no derivation chain that could reduce to its inputs. The sole metric is defined in Equation (1) as Δtime = T_resolution − T_query_close, computed directly from two observed packet-capture timestamps with zero free parameters. No parameter is fitted to a subset of data and then used to predict a related quantity. The results (78–80% positive gaps, medians of 67–79 ms, maxima exceeding 2,400 ms) are raw descriptive statistics over measured samples, not model predictions. Reference [1] (Afek, Berger, Bremler-Barr, USENIX Security 2025) shares coauthor Berger, but it is cited only as general background on DNS cache poisoning attacks — it does not supply a theorem, ansatz, or fitted parameter that the present paper's central claim depends on. The paper's claim ('positive timing gaps appear in approximately 79% of measurements') is a direct report of observed data, not a quantity derived from a model whose inputs would make it circular. The concerns raised by the skeptic (causal linkage between GSB close and DNS events, FIN/RST as proxy for safety decision) are correctness and methodology risks, not circularity. No step in the paper reduces by construction to its own inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

The paper introduces no free parameters (the metric is a direct difference of two observed timestamps) and no invented entities. The axioms are all domain assumptions about the measurement methodology, with the FIN/RST proxy assumption being the most load-bearing and the single-machine generalizability assumption being the most ad hoc.

axioms (4)
  • domain assumption TCP FIN/RST packet timestamp on the GSB-related connection is a valid proxy for the completion of the GSB safety check.
    Section 3.1: 'we define T_query_close as the timestamp of the associated TCP FIN or RST packet.' This is the reference point for the entire timing gap metric, but the paper does not validate that transport-layer closure corresponds to the browser's safety decision.
  • domain assumption TLS SNI metadata reliably identifies GSB-related traffic.
    Section 3.1: 'We identify GSB traffic via TLS Server Name Indication (SNI) metadata.' The paper assumes SNI-based identification captures all relevant GSB traffic, but does not discuss false positives or negatives.
  • domain assumption Clearing system-level DNS cache and browser state eliminates caching effects on timing measurements.
    Section 4: 'Before each navigation, we cleared the system-level DNS cache and browser state to reduce the effect of cached records and persistent sessions.' The paper assumes this is sufficient but does not account for upstream resolver caching or GSB local hash-prefix database state.
  • ad hoc to paper A single macOS workstation running Chrome Stable produces measurements generalizable to browsing workflows broadly.
    Section 4: all measurements are from one machine and one browser. The paper does not justify why this single configuration is representative, though it acknowledges future work will expand to other platforms.

pith-pipeline@v1.1.0-glm · 8013 in / 2753 out tokens · 389509 ms · 2026-07-08T15:24:52.880293+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages · 1 internal anchor

  1. [1]

    Proceedings of the ACM Web Conference 2024 , pages=

    Phishinwebview: Analysis of anti-phishing entities in mobile apps with webview targeted phishing , author=. Proceedings of the ACM Web Conference 2024 , pages=

    work page 2024

  2. [2]

    2018 APWG Symposium on Electronic Crime Research (eCrime) , pages=

    Inside a phisher's mind: Understanding the anti-phishing ecosystem through phishing kit analysis , author=. 2018 APWG Symposium on Electronic Crime Research (eCrime) , pages=. 2018 , organization=

    work page 2018

  3. [3]

    2019 IEEE Symposium on Security and Privacy (SP) , pages=

    Phishfarm: A scalable framework for measuring the effectiveness of evasion techniques against browser phishing blacklists , author=. 2019 IEEE Symposium on Security and Privacy (SP) , pages=. 2019 , organization=

    work page 2019

  4. [4]

    Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security , pages=

    RebirthDay Attack: Reviving DNS Cache Poisoning with the Birthday Paradox , author=. Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security , pages=

    work page 2025

  5. [5]

    29th \ USENIX \ Security Symposium ( \ USENIX \ Security 20) , year=

    Sunrise to sunset: Analyzing the end-to-end life cycle and effectiveness of phishing attacks at scale , author=. 29th \ USENIX \ Security Symposium ( \ USENIX \ Security 20) , year=

    work page

  6. [6]

    Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , pages=

    Phisheye: Live monitoring of sandboxed phishing kits , author=. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , pages=

    work page 2016

  7. [7]

    Proceedings of the ACM on Web Conference 2025 , pages=

    7 Days Later: Analyzing Phishing-Site Lifespan After Detected , author=. Proceedings of the ACM on Web Conference 2025 , pages=

    work page 2025

  8. [8]

    Artificial Intelligence Review , volume=

    Digital deception: Generative artificial intelligence in social engineering and phishing , author=. Artificial Intelligence Review , volume=. 2024 , publisher=

    work page 2024

  9. [9]

    Proceedings of the 19th ACM Asia Conference on Computer and Communications Security , pages=

    Deep dive into client-side anti-phishing: A longitudinal study bridging academia and industry , author=. Proceedings of the 19th ACM Asia Conference on Computer and Communications Security , pages=

    work page

  10. [10]

    MANTIS: Detection of Zero-Day Malicious Domains Leveraging Low Reputed Hosting Infrastructure , author=. Proc. of the IEEE Symposium on Security and Privacy , year=

    work page

  11. [11]

    Ruofan Liu and Yun Lin and Xianglin Yang and Siang Hwee Ng and Dinil Mon Divakaran and Jin Song Dong , title =. Proc. of the USENIX Security Symposium , year =

    work page

  12. [12]

    ScamNet: Toward Explainable Large Language Model-Based Fraudulent Shopping Website Detection , booktitle=

    Bitaab, Marzieh and Karimi, Alireza and Lyu, Zhuoer and Mosallanezhad, Ahmadreza and Oest, Adam and Wang, Ruoyu and Bao, Tiffany and Shoshitaishvili, Yan and Doupé, Adam , year=. ScamNet: Toward Explainable Large Language Model-Based Fraudulent Shopping Website Detection , booktitle=

    work page

  13. [13]

    Ruofan Liu and Yun Lin and Xiwen Teoh and Gongshen Liu and Zhiyong Huang and Jin Song Dong , title =. Proc. of the USENIX Security Symposium , year =

    work page

  14. [14]

    APWG , howpublished =

    work page

  15. [15]

    Proceedings of the 17th International Conference on Availability, Reliability and Security , pages=

    Dating phish: An analysis of the life cycles of phishing attacks and campaigns , author=. Proceedings of the 17th International Conference on Availability, Reliability and Security , pages=

    work page

  16. [16]

    ACM Transactions on Software Engineering and Methodology , year=

    Large language models for cyber security: A systematic literature review , author=. ACM Transactions on Software Engineering and Methodology , year=

    work page

  17. [17]

    34th USENIX Security Symposium (USENIX Security 25) , pages=

    \ POPS \ : From History to Mitigation of \ DNS \ Cache Poisoning Attacks , author=. 34th USENIX Security Symposium (USENIX Security 25) , pages=

    work page

  18. [18]

    Collaborative client-side dns cache poisoning attack , author=. Proc. of the IEEE INFOCOM 2019-IEEE Conference on Computer Communications , year=

    work page 2019

  19. [19]

    International Conference on Security and Privacy in Communication Systems , pages=

    The hitchhiker’s guide to DNS cache poisoning , author=. International Conference on Security and Privacy in Communication Systems , pages=. 2010 , organization=

    work page 2010

  20. [20]

    IRBlock: A Large-Scale Measurement Study of the Great Firewall of Iran , author =. Proc. of the USENIX Security Symposium , year =

    work page

  21. [21]

    GFWeb: Measuring the Great Firewall’s Web Censorship at Scale , author =. Proc. of the USENIX Security Symposium , year =

    work page

  22. [22]

    2024 IEEE Symposium on Security and Privacy (SP) , pages=

    Tudoor attack: Systematically exploring and exploiting logic vulnerabilities in dns response pre-processing with malformed packets , author=. 2024 IEEE Symposium on Security and Privacy (SP) , pages=. 2024 , organization=

    work page 2024

  23. [23]

    Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation

    Tranco: A research-oriented top sites ranking hardened against manipulation , author=. arXiv preprint arXiv:1806.01156 , year=

    work page internal anchor Pith review Pith/arXiv arXiv

  24. [24]

    33rd USENIX Security Symposium (USENIX Security 24) , pages=

    A flushing attack on the \ DNS \ cache , author=. 33rd USENIX Security Symposium (USENIX Security 24) , pages=

    work page

  25. [25]

    29th USENIX Security Symposium (USENIX Security 20) , pages=

    Poison over troubled forwarders: A cache poisoning attack targeting \ DNS \ forwarding devices , author=. 29th USENIX Security Symposium (USENIX Security 20) , pages=

    work page