WinMagic Discovered a Flaw in TLS and FIDO

Introduction

In the ever-evolving landscape of cybersecurity, SSL/TLS has emerged as the preeminent security protocol, fortifying trillions of daily interactions through HTTPS across web browsers. The TLS protocol, meticulously developed by some of the brightest minds in the industry, stands as the bedrock of internet security, setting the gold standard for safeguarding data during transmission. Indeed, TLS has become synonymous with resilience and adaptability. However, WinMagic has made some recent discoveries that we believe will change the cybersecurity space and one of them sheds light on a fundamental flaw that affects TLS and various solutions — in the core design — which use encryption or authentication like FIDO.

FIDO and TLS: A Symbiotic Relationship?

FIDO and TLS have traditionally served distinct purposes in the realm of cybersecurity. FIDO, with its primary focus on authentication, offers a passwordless and strong user authentication experience. In contrast, TLS is a protocol designed to secure the communication channel, ensuring the privacy and integrity of data during transmission over a network.

The integration of FIDO with TLS, achieved through the Web Authentication (WebAuthn) API, has been a significant development. WebAuthn allows web applications to interact with FIDO devices for user authentication, enhancing the overall security framework for online interactions. As such, FIDO complements TLS by fortifying the authentication layer. This integration plays a pivotal role, particularly relevant for achieving passwordless authentication, and has proven effective against various types of cyberattacks.

Unveiling the Inadvertently Hidden Fundamental Flaw

The core issue centers around the fundamental principle that the encryption key must be established concurrently with the authentication process — that is, the encryption key cannot be obtained without the “principal” authentication.

In the case of TLS, the negotiated session key is created at the beginning of a session, irrespective of the presence of server and client-side certificates. However, when the principal authentication — e.g., the FIDO authentication – occurs afterward, the TLS session key no longer adheres to the principle of being securely protected by the principal authentication. Currently this TLS session (key) is continued to be used for subsequent transactions, and that is the flaw.

When a flaw exists, it might be attacked in various ways. One example is the attacker/man-in-the-middle attack whereby the attacker will redirect the FIDO authentication to the authorized client and pass the FIDO authentication.

Implications and Observations

In the wake of this discovery, we wish to highlight the following observations:

  • You can say that TLS is designed for secure communication between two points and not responsible for authentication.
  • You can say that FIDO, designed for authentication, is not responsible for the encryption of the session afterward.
  • But the intricate interplay between communication protocols, encryption and authentication has led to the widespread implementation of solutions with inherent flaws and vulnerabilities that have been exploited.
  • In the current landscape, explicit discussion about the interplay of authentication and encryption is needed even if the solution focuses in just one of the two. TLS and FIDO should not only discuss but also allow revisions or even designs to support the missing parts as discussed above.
  • The flaw can be more visible if we analyze the federated authentications. After the principal authentication by the Identity Provider (IdP), the endpoint might connect with the Service Provider with a new TLS session and the key is negotiated without the involvement of the principal authentication which already took place.
  • We understand that IETF has recognized perhaps the same vulnerability and has been addressing it through token-binding, as outlined in RFC 8473. Additionally, NIST has introduced the concept of ‘holder key assertion’ in NIST 800-63c for the Highest Assurance Level of Federated Authentication (FAL3). However, we assert that the foundational principle — the encryption key should be generated with/within the principal authentication process — offers a straightforward yet secure and efficient solution. This approach might be more secure and significantly easier to implement and operate than existing solutions.
  • The belief in FIDO’s immunity to MITM attacks because the URL cannot be manipulated is questionable. When online, everything is data and the best technology to bring trust into data is cryptography. Believing that the URL cannot be manipulated without cryptography is inadvisable.

While the foundational principle is well understood, we believe that the flaw was well hidden because the TLS session key was created with the “first authentication”, which is not the “principal authentication.”

It is not the first time this fundamental integration between authentication and encryption is missing. If “TPM-only” authentication is set for BitLocker disk encryption, there is no authentication for the disk encryption (no PBA pre-boot authentication). With “no PBA” there is nothing to protect the disk if a dedicated adversary gets hold of your laptop. Nevertheless, we acknowledge that certain misconceptions persist, possibly because they are deemed adequate, especially considering the infrequency of laptop theft compared to the escalating sophistication of attacks on the Internet.

The Fix: Easy — and Broader Impacts

By way of our discovery, we contend that the fix for the identified flaw is relatively straightforward, albeit requiring a change in industry standards — e.g., both in TLS and FIDO. By addressing the coordination between authentication and encryption, we seek to simplify solutions, making them more secure, especially when considering the more complex environment involving federated authentication. In the upcoming blogs, we will suggest some possible fixes and hope to have industry-wide participation. We believe this will address the vulnerability token-binding and NIST Holder-of-Key Assertions try to solve — in a simple way. And we could add some extensions in SAML and OIDC federation protocols as well.

Looking Ahead: Embracing Change for a Secure Future

Since offering solutions for online authentication two years ago, WinMagic has started raising the bar, delivering what we believe is “the most secure authentication solution coupled with the best possible user experience — (no user action required). Addressing prevalent misconceptions, as detailed in our blog MFA and Zero-Trust Misconceptions Prevent Effective Solutions, we advocate for a paradigm shift that the server verifies the endpoint and let the endpoint verify the user. This achieves stronger security while even eliminating the current burden on users.

Beyond authentication, we focus on the “validity” of the authentication — a facet often overlooked by the industry. We need to define what constitutes a “secure session following (good, accurate) authentication.” While the discovery in this blog is small in comparison to our other innovations, we anticipate its significant impact, especially on protocols like TLS. Embracing the correct perspective, especially when rectifying previous misconceptions, promises substantial positive impacts on user security and experience. We firmly believe that this correction will simplify cybersecurity protocols and implementations. The anticipation of industry-wide participation in this transformative journey underscores the collective responsibility to ensure a secure digital future.

Follow us on LinkedIn to keep up with our latest blogs!

Previous Post
Open Letter Addressing NSA and CISA New IAM Guidance Document
Next Post
Competitive Advantages of Pre-Boot Authentication in Passwordless Secure Authentication
keyboard_arrow_up