Stories with Tag TLS

• How to distrust a CA without any certificate errors

  permalink

  Posted: 2025-03-06 22:28:01

  Verbose tl;dr

  This blog post explores how a Certificate Authority (CA) could maliciously issue a certificate with a valid signature but an impossibly distant expiration date, far beyond the CA's own validity period. This "fake future" certificate wouldn't trigger typical browser warnings because the signature checks out. However, by comparing the certificate's notAfter date with Signed Certificate Timestamps (SCTs) from publicly auditable logs, inconsistencies can be detected. These SCTs provide proof of inclusion in a log at a specific time, effectively acting as a timestamp for when the certificate was issued. If the SCT is newer than the CA's validity period but the certificate claims an older issuance date within that validity period, it indicates potential foul play. The post further demonstrates how this discrepancy can be checked programmatically using open-source tools.

  This blog post by Dadrian, titled "How to distrust a Certificate Authority without any certificate errors," explores a nuanced vulnerability related to Signed Certificate Timestamps (SCTs), which are crucial for ensuring the transparency and integrity of certificate issuance. The core issue revolves around the "notAfter" field within these SCTs. While a certificate itself has a validity period defined by its own "notAfter" date, the SCTs that vouch for its inclusion in a Certificate Transparency (CT) log also possess their own "notAfter" dates. The post highlights a potential scenario where a malicious or compromised Certificate Authority (CA) could issue a perfectly valid certificate – meaning the certificate's own "notAfter" date is in the future – yet manipulate the SCTs associated with that certificate. Specifically, the CA could backdate the SCTs, setting their "notAfter" dates to a point in the past.

  This manipulation wouldn't immediately trigger certificate errors in browsers or other relying parties because the certificate itself remains technically valid. However, it undermines the core principle of Certificate Transparency. Certificate Transparency logs are designed to provide an auditable record of all issued certificates, allowing for public scrutiny and detection of mis-issued or fraudulent certificates. The "notAfter" date of an SCT serves as a timestamp guaranteeing the certificate's inclusion in the log up to that specific point in time. By backdating the SCTs, the CA effectively creates a situation where the proof of inclusion in the CT log expires prematurely. This creates a window of opportunity where the CA could potentially issue other, fraudulent certificates without those certificates being reflected in the CT logs, as the now-expired SCTs no longer offer valid proof of inclusion. This undermines the entire auditability and transparency mechanism.

  The blog post details a practical demonstration of this vulnerability, showing how one can programmatically examine SCTs embedded in a certificate and compare their "notAfter" dates with the current time. This allows for the identification of certificates with potentially backdated SCTs, raising a red flag regarding the trustworthiness of the issuing CA, even in the absence of traditional certificate errors. The post concludes by emphasizing the importance of validating SCT "notAfter" dates as a critical part of robust certificate verification procedures and underscores the subtle ways in which the Certificate Transparency ecosystem can be compromised, requiring vigilance beyond simply checking for standard certificate validity. It implies that relying solely on the validity of the certificate itself isn't sufficient for guaranteeing trustworthiness and that scrutiny of associated SCTs is paramount.

  • TLS
  • SSL
  • certificates
  • Certificate Authority
  • CA
  • PKI
  • Security
  • Web Security
  • SCT
  • Signed Certificate Timestamps
  • transparency
  • X.509
  • Not After
  • Expiration
  • Distrust
  • verification
  • Cryptography

  Summary of Comments ( 43 )
  https://news.ycombinator.com/item?id=43285671

  Verbose tl;dr

  Hacker News users discuss the practicality and implications of the blog post's method for detecting malicious Sub-CAs. Several commenters point out the difficulty of implementing this at scale due to the computational cost and potential performance impact of checking every certificate against a large CRL set. Others express concerns about the feasibility of maintaining an up-to-date list of suspect CAs, given their dynamic nature. Some question the overall effectiveness, arguing that sophisticated attackers could circumvent such checks. A few users suggest alternative approaches like using DNSSEC and DANE, or relying on operating system trust stores. The overall sentiment leans toward acknowledging the validity of the author's points while remaining skeptical of the proposed solution's real-world applicability.

  The Hacker News post "How to distrust a CA without any certificate errors" sparked a discussion with several insightful comments. Many commenters engaged with the core concept of the blog post, which explored how a Certificate Authority (CA) could potentially manipulate certificates without triggering typical browser warnings.

  One commenter highlighted the difficulty in detecting this type of manipulation, emphasizing that the trust model inherently relies on the CA. They pointed out the unlikelihood of a user independently verifying the certificate chain, especially given the complexity involved. This reinforced the article's point about the potential vulnerability.

  Another commenter discussed the "certificate pinning" technique, which involves hardcoding expected certificate information into an application. While effective against the specific attack described in the article, they acknowledged that it's not a widespread solution and introduces its own set of management challenges, such as the need to update pinned certificates regularly.

  The conversation also touched upon the broader issues of trust and security in the digital landscape. One commenter expressed a general lack of trust in CAs, citing past incidents of compromised CAs and questionable practices. This sentiment resonated with other users who echoed concerns about the centralized nature of the CA system.

  Some commenters suggested alternative approaches to enhance security. One idea involved using DNSSEC combined with DANE (DNS-based Authentication of Named Entities), allowing domain owners to specify which CAs are authorized to issue certificates for their domain. Another suggestion was to explore decentralized identity solutions, moving away from the reliance on centralized CAs altogether.

  Several comments also delved into the technical details of the attack described in the article, with users discussing specific aspects of certificate validation and the potential implications for different browsers and operating systems. There was some debate about the practicality of the attack and the likelihood of it being exploited in the wild, with some arguing that the complexity involved would make it a less attractive option for attackers.

  Overall, the comments section reflected a general understanding of the potential vulnerabilities associated with the current CA system and a desire for more robust and transparent security solutions. While no single solution emerged as a clear winner, the discussion provided valuable insights into the challenges and potential future directions of certificate management and online trust.

• 0+0 > 0: C++ thread-local storage performance

  permalink

  Posted: 2025-02-17 11:18:29

  Verbose tl;dr

  Thread-local storage (TLS) in C++ can introduce significant performance overhead, even when unused. The author benchmarks various TLS access methods, demonstrating that even seemingly simple zero-initialized thread-local variables incur a cost, especially on Windows. This overhead stems from the runtime needing to manage per-thread data structures, including lazy initialization and destruction. While the performance impact might be negligible in many applications, it can become noticeable in highly concurrent, performance-sensitive scenarios, particularly with a large number of threads. The author explores techniques to mitigate this overhead, such as using compile-time initialization or avoiding TLS altogether if practical. By understanding the costs associated with TLS, developers can make informed decisions about its usage and optimize their multithreaded C++ applications for better performance.

  The blog post "0+0 > 0: C++ thread-local storage performance" by Yosef Kreinin explores the performance implications of using thread-local storage (TLS) in C++. Kreinin begins by establishing the context that accessing thread-local variables can introduce performance overhead, potentially negating the benefits of multithreading. He sets out to investigate the extent of this overhead and identify the contributing factors.

  The investigation starts with a simple benchmark that measures the time taken to perform a trivial arithmetic operation (0+0) within a loop, both with and without declaring a thread-local variable. Surprisingly, the benchmark reveals that the version with the thread-local variable is significantly slower, even though the variable is never accessed. This indicates that the mere presence of a thread-local variable introduces overhead.

  Kreinin then delves into the potential reasons for this performance degradation. He explains that TLS is typically implemented using a hidden global data structure accessed indirectly through thread-local storage pointers. Each thread maintains its own pointer to its respective slot in this structure. The access to a thread-local variable involves retrieving the thread-local storage pointer, which can be a relatively expensive operation depending on the platform and implementation. Furthermore, the added complexity can disrupt compiler optimizations, hindering performance.

  The post examines several scenarios and their corresponding assembly code to demonstrate how thread-local variables impact performance. These scenarios include cases where the variable is initialized with a constant, initialized with a non-constant expression, and cases where the variable is accessed or not accessed within the loop. The analysis of the generated assembly code illuminates the underlying mechanisms responsible for the observed performance differences. It highlights the additional instructions required for thread-local variable access, compared to regular global or local variables.

  Kreinin further investigates how different compilers and operating systems handle TLS. He observes variations in performance across different platforms, suggesting that the overhead associated with thread-local variables is not uniform. This emphasizes the importance of understanding the specific implementation details when working with TLS.

  The post then explores strategies for mitigating the performance impact of thread-local variables. One such strategy involves reducing the number of thread-local variables by grouping related variables into a structure. This technique minimizes the number of indirect accesses required, potentially improving performance. Another approach involves caching the value of a thread-local variable in a local variable within a tight loop, thereby avoiding repeated access to the TLS mechanism.

  The blog post concludes by summarizing the findings and emphasizing the importance of considering the performance implications of thread-local storage when designing multithreaded C++ applications. It advises developers to be mindful of the potential overhead and to employ appropriate optimization techniques when necessary. The key takeaway is that while thread-local storage provides a valuable mechanism for managing thread-specific data, its usage should be carefully considered in performance-critical sections of code.

  • C++
  • performance
  • Thread-Local Storage
  • TLS
  • Multithreading
  • concurrency
  • optimization
  • benchmarking

  Summary of Comments ( 10 )
  https://news.ycombinator.com/item?id=43077675

  Verbose tl;dr

  The Hacker News comments discuss the surprising performance cost of thread-local storage (TLS) in C++, particularly its impact on seemingly unrelated code. Several commenters highlight the overhead introduced by the TLS lookups, even when the TLS variables aren't directly used in a particular code path. The most compelling comments delve into the underlying reasons for this, citing issues like increased register pressure due to the extra variables needing to be tracked, and the difficulty compilers have in optimizing around TLS access. Some point out that the benchmark's reliance on rdtsc for timing might be flawed, while others offer alternative benchmarking strategies. The performance impact is acknowledged to be architecture-dependent, with some suggesting mitigations like using compile-time initialization or alternative threading models if TLS performance is critical. A few commenters also mention similar performance issues they've encountered with TLS in other languages, suggesting it's not a C++-specific problem.

  The Hacker News post titled "0+0 > 0: C++ thread-local storage performance," linking to an article about C++ thread-local storage performance, has a moderate number of comments discussing various aspects of the topic.

  Several commenters discuss the complexities and nuances of thread-local storage (TLS) implementation across different compilers and platforms. One commenter points out the variability in performance characteristics of TLS, noting how different compilers (like GCC and Clang) and operating systems might handle TLS access differently, impacting performance. This commenter also highlights how the use of dynamic libraries can further complicate the situation, leading to potential performance hits if TLS isn't implemented optimally within the dynamic loading process.

  Another commenter delves into the specifics of how TLS is handled on Windows, mentioning the use of "Thread Local Storage (TLS) callbacks," which are functions executed upon thread creation or destruction that manage the TLS data. This introduces overhead, especially in scenarios with frequent thread creation and destruction. The commenter contrasts this with the __thread keyword (supported by GCC and Clang), which is often faster but less portable.

  One commenter mentions the difficulties in measuring the performance of TLS accurately, emphasizing the importance of factors such as CPU caching and benchmarking methodology. They also point out the impact that the surrounding code and its interaction with the TLS access can have on overall performance.

  The discussion also touches upon the performance implications of different TLS access patterns. One commenter suggests that accessing TLS frequently within tight loops can indeed be a performance bottleneck, echoing the article's findings. Another comment highlights the overhead associated with the initial access to a TLS variable in a thread's lifetime, as opposed to subsequent accesses.

  Finally, a few comments provide alternative solutions or approaches to consider when dealing with performance-sensitive multithreaded code. One commenter mentions using thread pools to minimize the overhead of thread creation and destruction, thus indirectly reducing the impact of TLS management. Another commenter suggests exploring alternative data structures or algorithms that might minimize the need for frequent TLS access altogether.