pith. sign in

arxiv: 1907.00231 · v1 · pith:YDBFAJ3Gnew · submitted 2019-06-29 · 💻 cs.CR

Towards Forward Secure Internet Traffic

Eman Salem Alashwali , Pawel Szalachowski , Andrew Martin This is my paper

Pith reviewed 2026-05-25 12:54 UTC · model grok-4.3

classification 💻 cs.CR
keywords forward secrecyTLSkey exchangeempirical analysisclient-side mechanisminternet measurementadversary model
0
0 comments X

The pith

Many TLS servers do not select forward secrecy even when they support it.

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

The paper measures how often pre-TLS 1.3 servers on the Internet choose forward secrecy during key exchange, drawing on scans of more than ten million servers from three separate datasets. It reports that between five and twenty-six percent of the servers skip FS algorithms, yet a sizable share of those non-selecting servers still possess the ability to use FS. The authors propose two client-side mechanisms, Best Effort Forward Secrecy and Best Effort Forward Secrecy and Authenticated Encryption, that attempt to steer misconfigured servers toward FS without changes on the server side. They also define a discriminatory adversary model that applies to the TLS setting. These observations matter because forward secrecy limits the damage from later compromise of long-term keys.

Core claim

Using a novel heuristic approach based on modern TLS client handshake algorithms, our results show 5.37% of top domains, 7.51% of random domains, and 26.16% of random IPs do not select FS key-exchange algorithms. Surprisingly, 39.20% of the top domains, 24.40% of the random domains, and 14.46% of the random IPs that do not select FS, do support FS. In light of this analysis, we discuss possible paths toward forward secure Internet traffic and propose a new client-side mechanism that we call Best Effort Forward Secrecy (BEFS), and an extension of it that we call Best Effort Forward Secrecy and Authenticated Encryption (BESAFE), which aims to guide misconfigured servers to FS using a best-effo

What carries the argument

The Best Effort Forward Secrecy (BEFS) client-side mechanism, which uses a best-effort approach to guide misconfigured servers toward selecting FS key-exchange algorithms.

If this is right

  • A measurable fraction of top domains, random domains, and random IPs fail to select FS key-exchange algorithms.
  • A substantial portion of servers that do not select FS still support it and could be guided to use it.
  • Client-side mechanisms such as BEFS and BESAFE can steer servers toward FS without requiring server configuration changes.
  • A discriminatory adversary model applies to the TLS protocol and can be used to reason about selective attacks on FS.

Where Pith is reading between the lines

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

  • Server operators may be unaware that their software supports FS or may have left default non-FS options active.
  • Widespread client adoption of BEFS could raise overall FS usage rates across the Internet without new server mandates.
  • The gap between support and selection points to configuration or awareness issues that predate the mandatory FS rules in TLS 1.3.

Load-bearing premise

The novel heuristic based on modern TLS client handshake algorithms correctly distinguishes servers that support FS from those that select it.

What would settle it

Performing direct TLS handshakes with a modern client against the servers flagged by the heuristic as supporting but not selecting FS, and checking whether FS algorithms are actually offered when the client expresses a strong preference for them.

Figures

Figures reproduced from arXiv: 1907.00231 by Andrew Martin, Eman Salem Alashwali, Pawel Szalachowski.

Figure 1
Figure 1. Figure 1: Illustration of the version and ciphersuite [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Illustration of the RSA key-exchange in pre-TLS 1.3. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Illustration of the (EC)DHE key-exchange in pre-TLS [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: A general overview of our methodology showing the two [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: A BEFS-enabled client hand￾shake when the server prefers to select a non-FS-ciphersuite while supporting FS-ciphersuites. The server is forced to select FS-ciphersuite through client FS-ciphersuite enforcement. Client (C) Server (S) CH(...,[a1f s,...,anf s],...) Prefers non-Fs; Sup￾ports non-FS only Error CH(...,[a1f s,...,annon f s],...) SH(...,aSnon f s,...) non-FS connection [PITH_FULL_IMAGE:figures/fu… view at source ↗
read the original abstract

Forward Secrecy (FS) is a security property in key-exchange algorithms which guarantees that a compromise in the secrecy of a long-term private-key does not compromise the secrecy of past session keys. With a growing awareness of long-term mass surveillance programs by governments and others, FS has become widely regarded as a highly desirable property. This is particularly true in the TLS protocol, which is used to secure Internet communication. In this paper, we investigate FS in pre-TLS 1.3 protocols, which do not mandate FS, but still widely used today. We conduct an empirical analysis of over 10 million TLS servers from three different datasets using a novel heuristic approach. Using a modern TLS client handshake algorithms, our results show 5.37% of top domains, 7.51% of random domains, and 26.16% of random IPs do not select FS key-exchange algorithms. Surprisingly, 39.20% of the top domains, 24.40% of the random domains, and 14.46% of the random IPs that do not select FS, do support FS. In light of this analysis, we discuss possible paths toward forward secure Internet traffic. As an improvement of the current state, we propose a new client-side mechanism that we call "Best Effort Forward Secrecy" (BEFS), and an extension of it that we call "Best Effort Forward Secrecy and Authenticated Encryption" (BESAFE), which aims to guide (force) misconfigured servers to FS using a best effort approach. Finally, within our analysis, we introduce a novel adversarial model that we call "discriminatory" adversary, which is applicable to the TLS protocol.

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 / 1 minor

Summary. The paper conducts a large-scale empirical measurement of forward secrecy (FS) adoption in pre-TLS 1.3 deployments across three datasets (top domains, random domains, random IPs) totaling over 10 million servers. Using a novel heuristic based on modern TLS client handshakes, it reports that 5.37% of top domains, 7.51% of random domains, and 26.16% of random IPs do not select FS key-exchange algorithms, while 39.20%, 24.40%, and 14.46% of those respectively still support FS. It proposes client-side mechanisms BEFS and BESAFE to steer servers toward FS and introduces a discriminatory adversary model applicable to TLS.

Significance. If the heuristic is correctly specified and validated, the measurements would provide concrete evidence of a support-selection gap in TLS FS deployments and motivate practical client-side interventions. The discriminatory adversary model offers a potentially useful addition to the TLS threat landscape for analyzing selective security properties.

major comments (3)
  1. [Abstract] Abstract and methods description: The novel heuristic is invoked to produce all headline percentages but is not specified (no algorithm, decision rules, client handshake parameters, or classification criteria are given), making the central empirical claims on support-vs-selection rates unverifiable.
  2. [Abstract] Abstract: No validation set, ground-truth comparison, false-positive/false-negative rates, or sensitivity analysis is reported for the heuristic; without these, it is impossible to assess whether the 14.46–39.20% 'support but do not select' figures are reliable or artifacts of misclassification.
  3. [Datasets] Datasets description: The construction of the random-domains and random-IPs datasets (sampling method, exact sizes, deduplication, and any filtering) is not detailed, which directly affects reproducibility and the interpretation of the 7.51% and 26.16% non-selection rates.
minor comments (1)
  1. [Abstract] The abstract states 'over 10 million TLS servers' without giving the precise total or per-dataset breakdown.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive comments. We agree that the heuristic requires explicit specification, that validation metrics are needed, and that dataset construction details must be expanded for reproducibility. We will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: [Abstract] Abstract and methods description: The novel heuristic is invoked to produce all headline percentages but is not specified (no algorithm, decision rules, client handshake parameters, or classification criteria are given), making the central empirical claims on support-vs-selection rates unverifiable.

    Authors: We agree that the heuristic must be fully specified. We will revise the methods section to include the complete algorithm, decision rules, client handshake parameters used, and classification criteria so that the support-vs-selection rates can be independently verified. revision: yes

  2. Referee: [Abstract] Abstract: No validation set, ground-truth comparison, false-positive/false-negative rates, or sensitivity analysis is reported for the heuristic; without these, it is impossible to assess whether the 14.46–39.20% 'support but do not select' figures are reliable or artifacts of misclassification.

    Authors: We agree that the current version lacks reported validation, ground-truth comparisons, error rates, or sensitivity analysis. We will add a validation subsection with these elements to support the reliability of the reported percentages. revision: yes

  3. Referee: [Datasets] Datasets description: The construction of the random-domains and random-IPs datasets (sampling method, exact sizes, deduplication, and any filtering) is not detailed, which directly affects reproducibility and the interpretation of the 7.51% and 26.16% non-selection rates.

    Authors: We agree that the dataset construction details are insufficient. We will expand the datasets section with the sampling methods, exact sizes, deduplication procedures, and any filtering steps applied. revision: yes

Circularity Check

0 steps flagged

No circularity: pure empirical measurement study

full rationale

The paper conducts an empirical scan of TLS servers across three datasets to measure FS selection and support rates using a novel heuristic based on client handshakes. No equations, fitted parameters, predictions, or self-citations appear in the provided text. The quantitative claims are direct outputs of the measurement process rather than reductions of any derivation chain to its inputs by construction. The study is self-contained against external benchmarks with no load-bearing self-referential steps of the enumerated kinds.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claims rest on assumptions about TLS handshake behavior and dataset representativeness plus one new invented entity; no free parameters are introduced.

axioms (1)
  • domain assumption TLS servers respond to client-offered key-exchange algorithms in a way that a modern client handshake can reliably detect support versus selection.
    This underpins the novel heuristic used to produce the reported percentages.
invented entities (1)
  • discriminatory adversary no independent evidence
    purpose: New adversarial model applicable to the TLS protocol.
    Introduced within the analysis as a novel model; no independent evidence provided.

pith-pipeline@v0.9.0 · 5838 in / 1346 out tokens · 38814 ms · 2026-05-25T12:54:52.078130+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

44 extracted references · 44 canonical work pages

  1. [1]

    In: Proceedings of USENIX Secu rity Symposium (2013)

    Akhawe, D., Felt, A.P .: Alice in Warningland: A Large-Sca le Field Study of Browser Secu- rity Warning Effectiveness. In: Proceedings of USENIX Secu rity Symposium (2013)

    work page 2013

  2. [2]

    In: Proceedings of Int

    Alashwali, E.S.: Cryptographic Vulnerabilities in Real -Life Web Servers. In: Proceedings of Int. Conference on Communications and Information Technol ogy (ICCIT). pp. 6–11 (2013)

    work page 2013

  3. [3]

    In: Proceedings of Appli- cations and Techniques in Cyber Security (A TCS) (2018)

    Alashwali, E.S., Rasmussen, K.: What’s in a Downgrade? A T axonomy of Downgrade At- tacks in the TLS Protocol and Application Protocols Using TL S. In: Proceedings of Appli- cations and Techniques in Cyber Security (A TCS) (2018)

    work page 2018

  4. [4]

    Alashwali, E.S., Szalachowski, P ., Martin, A.: Does “www .” Mean Better Transport Layer Security? In: Proceedings of Availability, Reliability an d Security (ARES) (2019)

    work page 2019

  5. [5]

    22, 2018

    Alexa Internet, Inc.: Alexa Top Sites (2018), http://s3.amazonaws.com/alexa-static/ top-1m.csv.zip, accessed Aug. 22, 2018

    work page 2018

  6. [6]

    In: Proceedings of Security and Privacy (SP)

    AlFardan, N.J., Paterson, K.G.: Lucky Thirteen: Breakin g the TLS and DTLS Record Proto- cols. In: Proceedings of Security and Privacy (SP). pp. 526– 540 (2013)

    work page 2013

  7. [7]

    In: Proceedings of Interne t Measurement Conference (IMC)

    Amann, J., Gasser, O., Scheitle, Q., Brent, L., Carle, G., Holz, R.: Mission Accomplished?: HTTPS Security After Diginotar. In: Proceedings of Interne t Measurement Conference (IMC). pp. 325–340 (2017)

    work page 2017

  8. [8]

    30, 2018

    Barnes, R., Thomson, M., Pironti, A., Langley, A.: Deprec ating Secure Sockets Layer V er- sion 3.0 (2015), https://tools.ietf.org/html/rfc7568, accessed Sept. 30, 2018

    work page 2015

  9. [9]

    In: Proceed- ings of Security and Privacy (SP) (2019)

    Calzavara, S., Focardi, R., Nemec, M., Rabitti, A., Squar cina, M.: Postcards from the Post- HTTP World: Amplification of HTTPS Vulnerabilities in the We b Ecosystem. In: Proceed- ings of Security and Privacy (SP) (2019)

    work page 2019

  10. [10]

    In: Proceed- ings of Advances in Cryptology (EUROCRYPT)

    Cavallar, S., Dodson, B., Lenstra, A.K., Lioen, W., Mont gomery, P .L., Murphy, B., te Riele, H., Aardal, K., Gilchrist, J., Guillerm, G., Leyland, P ., Marchand, J., Morain, F., Muffett, A., Putnam, C., Craig, Zimmermann, P .: Factorization of a 512-B it RSA Modulus. In: Proceed- ings of Advances in Cryptology (EUROCRYPT). pp. 1–18 (2000)

    work page 2000

  11. [11]

    IEEE Transactions on Information Theory 22(6), 644–654 (1976)

    Diffie, W., Hellman, M.: New Directions in Cryptography. IEEE Transactions on Information Theory 22(6), 644–654 (1976)

    work page 1976

  12. [12]

    Dukhovni, V .: Opportunistic Security: Some Protection Most of the Time (2014), https:// tools.ietf.org/html/rfc7435.html, accessed Oct. 1, 2018

    work page 2014

  13. [13]

    In: Proceedings of Computer and Communications Security (CCS)

    Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., Halde rman, J.A.: A Search Engine Backed by Internet-Wide Scanning. In: Proceedings of Computer and Communications Security (CCS). pp. 542–553 (2015)

    work page 2015

  14. [14]

    19, 2019

    Eastlake 3rd, D.: Transport Layer Security (TLS) Extens ions: Extension Definitions, https://tools.ietf.org/html/rfc6066#page-6, accessed Jun. 19, 2019

    work page 2019

  15. [15]

    30, 2018

    FIPS: Advanced Encryption Standard (AES) (2001), https : //nvlpubs.nist.gov/ nistpubs/FIPS/NIST.FIPS.197.pdf, accessed Sept. 30, 2018

    work page 2001

  16. [16]

    A.: Mining Your Ps and Qs: Detec- tion of Widespread Weak Keys in Network Devices

    Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J. A.: Mining Your Ps and Qs: Detec- tion of Widespread Weak Keys in Network Devices. In: Proceed ings of USENIX Security Symposium (2012)

    work page 2012

  17. [17]

    509 PKI Using Active and Passive Measurements

    Holz, R., Braun, L., Kammenhuber, N., Carle, G.: The SSL L andscape: a Thorough Analysis of the X. 509 PKI Using Active and Passive Measurements. In: P roceedings of Internet Measurement Conference (IMC). pp. 427–444 (2011)

    work page 2011

  18. [18]

    IEEE Internet Computing 18(6), 43–51 (2014)

    Huang, L.S., Adhikarla, S., Boneh, D., Jackson, C.: An Ex perimental Study of TLS Forward Secrecy Deployments. IEEE Internet Computing 18(6), 43–51 (2014)

    work page 2014

  19. [19]

    In: Proceedings of Advances in Cryptology (CRYPTO)

    Jager, T., Kohlar, F., Sch¨ age, S., Schwenk, J.: On the Se curity of TLS-DHE in the Standard Model. In: Proceedings of Advances in Cryptology (CRYPTO). pp. 273–293 (2012)

    work page 2012

  20. [20]

    In: Proceedings of Advances in Cryptology (CRYPTO)

    Kleinjung, T., Aoki, K., Franke, J., Lenstra, A.K., Thom ´ e, E., Bos, J.W., Gaudry, P ., Kruppa, A., Montgomery, P .L., Osvik, D.A., te Riele, H., Timofeev, A ., Zimmermann, P .: Factoriza- tion of a 768-bit RSA Modulus. In: Proceedings of Advances in Cryptology (CRYPTO). pp. 333–350 (2010)

    work page 2010

  21. [21]

    , V allina-Rodriguez, N., Caballero, J.: Coming of Age: A Longitudinal Study of TLS Deployment

    Kotzias, P ., Razaghpanah, A., Amann, J., Paterson, K.G. , V allina-Rodriguez, N., Caballero, J.: Coming of Age: A Longitudinal Study of TLS Deployment. In : Proceedings of Internet Measurement Conference (IMC). pp. 415–428 (2018)

    work page 2018

  22. [22]

    30, 2018

    Kurkowski, J.: tldextract (2017), https://github.com/john-kurkowski/tldextract, accessed Oct. 30, 2018

    work page 2017

  23. [23]

    25, 2019

    Laurie, B., Langley, A., Kasper, E.: Certificate Transpa rency (2013), accessed Feb. 25, 2019

    work page 2013

  24. [24]

    In: Proceedings of Internet Measurement Conference (IMC)

    Lee, H.K., Malkin, T., Nahum, E.: Cryptographic Strengt h of SSL/TLS Servers: Current and Recent Practices. In: Proceedings of Internet Measurement Conference (IMC). pp. 83–92 (2007)

    work page 2007

  25. [25]

    CRC press (1996)

    Menezes, A.J., V an Oorschot, P .C., V anstone, S.A.: Hand book of Applied Cryptography. CRC press (1996)

    work page 1996

  26. [26]

    Moeller, B., Langley, A.: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (2014), https : //tools.ietf.org/html/ draft-ietf-tls-downgrade-scsv-00 , accessed Oct. 1, 2018

    work page 2014

  27. [27]

    M¨ oller, B., Duong, T., Kotowicz, K.: This POODLE Bites: Exploiting the SSL 3.0 Fallback (2014), https://www.openssl.org/~bodo/ssl-poodle.pdf, accessed Jul. 6, 2018

    work page 2014

  28. [28]

    ietf.org/html/rfc8422, accessed Jun

    Nir, Y ., Josefsson, S., Pegourie-Gonnard, M.: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (2018), https://tools. ietf.org/html/rfc8422, accessed Jun. 21, 2019

    work page 2018

  29. [29]

    Com- munications of the ACM 59(10), 58–64 (2016)

    Partridge, C., Allman, M.: Ethical Considerations in Ne twork Measurement Papers. Com- munications of the ACM 59(10), 58–64 (2016)

    work page 2016

  30. [30]

    30, 2018

    Popov, A.: Prohibiting RC4 Cipher Suites (2015), https : //tools.ietf.org/html/ rfc7465, accessed Sept. 30, 2018

    work page 2015

  31. [31]

    10, 2019

    Qualys Inc.: SSL Labs (2018), https://www.ssllabs.com/ssl-pulse/, accessed Apr. 10, 2019

    work page 2018

  32. [32]

    Rescorla, E.: The Transport Layer Security (TLS) Protoc ol Version 1.2 (2008), https:// www.ietf.org/rfc/rfc5246.txt, accessed Jul. 6, 2018

    work page 2008

  33. [33]

    Rescorla, E.: The Transport Layer Security (TLS) Protoc ol Version 1.3 draft-ietf-tls-tls13-28 (2018), https://tools.ietf.org/html/draft-ietf-tls-tls13-28 , accessed Jul. 6, 2018

    work page 2018

  34. [34]

    Communications of the ACM 21(2), 120–126

    Rivest, R.L., Shamir, A., Adleman, L.: A Method for Obtai ning Digital Signatures and Public-Key Cryptosystems. Communications of the ACM 21(2), 120–126

    work page

  35. [35]

    In: Pro- ceedings of Network and Distributed System (NDSS) (2018)

    Ryan, M.D.: Enhanced Certificate Transparency and End-t o-End Encrypted Mail. In: Pro- ceedings of Network and Distributed System (NDSS) (2018)

    work page 2018

  36. [36]

    12, 2018

    Salowey, J., Choudhury, A., McGrew, D.: AES Galois Count er Mode (GCM) Cipher Suites for TLS (2008), https://tools.ietf.org/html/rfc5288#page- 3, accessed Nov. 12, 2018

    work page 2008

  37. [37]

    Web Servers

    Samarasinghe, N., Mannan, M.: Short Paper: TLS Ecosyste ms in Networked Devices vs. Web Servers. In: Proceedings of Financial Cryptography and Data Security (FC). pp. 533– 541 (2017)

    work page 2017

  38. [38]

    In: Proceedings of U SENIX Security Symposium

    Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., Cra nor, L.F.: Crying Wolf: An Empiri- cal Study of SSL Warning Effectiveness. In: Proceedings of U SENIX Security Symposium. pp. 399–416 (2009)

    work page 2009

  39. [39]

    17, 2018

    Synopsys Inc.: The Heartbleed Bug (2014), http://heartbleed.com, accessed Sept. 17, 2018

    work page 2014

  40. [40]

    In: Proceedings of Theory and Applications of Cryp tographic Techniques (EU- ROCRYPT)

    V audenay, S.: Security Flaws Induced by CBC Padding-App lications to SSL, IPSEC, WTLS.... In: Proceedings of Theory and Applications of Cryp tographic Techniques (EU- ROCRYPT). pp. 534–546 (2002)

    work page 2002

  41. [41]

    27, 2019

    W3Schools: Browser Statistics (2019), https : //www.w3schools.com/browsers, ac- cessed Feb. 27, 2019

    work page 2019

  42. [42]

    Wikipedia: PRISM (Surveillance Program) (2018), https://en.wikipedia.org/wiki/ PRISM (surveillance program), accessed Oct. 3, 2018

    work page 2018

  43. [43]

    Yahoo Inc.: tls-scan (2016), https://github.com/prbinu/tls-scan, accessed Sept. 8, 2018

    work page 2016

  44. [44]

    Y oung, A., Y ung, M.: The Dark Side of Black-Box Cryptogra phy or: Should We Trust Cap- stone? In: Proceedings of Advances in Cryptology (CRYPTO). pp. 89–103 (1996)

    work page 1996