Marlinspike Launches Convergence to Break Web's SSL Authority Monopoly
DEFCONConference
The web's authenticity model fails because browsers cannot revoke trust from compromised certificate authorities without breaking connectivity, requiring client-driven verification to restore trust agility.
AI-assisted summary of DEF CON 19 - Moxie Marlinspike - SSL And The Future Of Authenticity — original source. Check the original for full context.
Source published:
Key ideas
- Moxie Marlinspike debunks Comodo's narrative of an advanced state-sponsored cyber army, revealing server logs that showed the Iranian attacker learning basic MITM attacks from Hak5 tutorials and troubleshooting iptables via Google. (6:36)
- The foundational flaw of the modern SSL/TLS ecosystem is the complete absence of 'Trust Agility,' which permanently locks browsers and users into trusting hundreds of Certificate Authorities with zero ability to revoke or revise trust without breaking the web. (24:35)
- DNSSEC fails as an authenticity replacement because it merely distributes data while centralizing absolute, unrevocable trust under domain registrars, foreign TLD operators, and ICANN under US jurisdiction. (31:13)
- Marlinspike releases Convergence, a trust-agile replacement for the CA system that uses client-driven multi-perspective network notaries and notary bouncing to protect user privacy without requiring any changes to web servers. (38:36)
Detailed notes
## Background Published by DEFCONConference on YouTube on November 2, 2013, this video features security researcher Moxie Marlinspike presenting at DEF CON 19. According to the show notes, the talk examines the historical origins and friction surrounding Certificate Authorities in SSL, sheds light on current authenticity failures, and explores new strategies to move forward.
## TL;DR Moxie Marlinspike examines the fundamental breakdown of authenticity in SSL, arguing that the centralized Certificate Authority (CA) model was hastily conceived as an afterthought and has become systematically unmanageable. Through real-world debacles like the Comodo breach, he demonstrates how corporate gatekeepers face zero consequences for negligence while users remain trapped in permanent trust lock-in. Marlinspike rejects top-down alternatives like DNSSEC as merely shifting centralized power to registrars and governments, proposing instead the principle of 'Trust Agility'—allowing clients to dynamically revise who they trust. To prove the concept, he introduces Convergence, an open-source system utilizing multi-path network probing and privacy-preserving notary bouncing that allows users to replace commercial CAs entirely without modifying web servers.
## Atmosphere & style The presentation is dryly irreverent, analytical, and subversive, kicking off with an absurd Tex-Mex prank story to stall for time before systematically dissecting the multi-billion-dollar CA industry. Marlinspike delivers sharp technical insights with deadpan humor, puncturing corporate spin about 'state-sponsored cyber armies' by pulling up basic log files showing attackers watching beginner tutorials. The talk carries the energetic, anti-establishment ethos of classic DEF CON, transforming a dry cryptographic debate into an empowering, pragmatic manifesto for user autonomy.
## Bulletin - [06:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=396s) Moxie Marlinspike debunks Comodo's narrative of an advanced state-sponsored cyber army, revealing server logs that showed the Iranian attacker learning basic MITM attacks from Hak5 tutorials and troubleshooting iptables via Google. - [24:35](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1475s) The foundational flaw of the modern SSL/TLS ecosystem is the complete absence of 'Trust Agility,' which permanently locks browsers and users into trusting hundreds of Certificate Authorities with zero ability to revoke or revise trust without breaking the web. - [31:13](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1873s) DNSSEC fails as an authenticity replacement because it merely distributes data while centralizing absolute, unrevocable trust under domain registrars, foreign TLD operators, and ICANN under US jurisdiction. - [38:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2316s) Marlinspike releases Convergence, a trust-agile replacement for the CA system that uses client-driven multi-perspective network notaries and notary bouncing to protect user privacy without requiring any changes to web servers.
## Key takeaways - [04:54](https://www.youtube.com/watch?v=UawS3_iuHoA&t=294s) The 2011 Comodo breach compromised critical login endpoints for Google, Yahoo, and Skype, exposing the vulnerability of relying on commercial CAs. - [06:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=396s) Server access logs for SSLsniff demonstrated that the Comodo intruder was an amateur operating on Windows with US English localization, directly following online video guides rather than operating an elite military cyber unit. - [09:47](https://www.youtube.com/watch?v=UawS3_iuHoA&t=587s) The CA industry suffers from a total lack of accountability; despite repeated breaches and baffling executive statements, Comodo lost no business and its CEO was honored at RSA. - [12:04](https://www.youtube.com/watch?v=UawS3_iuHoA&t=724s) SSL successfully solved transport secrecy and message integrity under extreme pressure in the early 1990s, but domain authenticity was added as a hasty afterthought. - [14:20](https://www.youtube.com/watch?v=UawS3_iuHoA&t=860s) Netscape engineer Kip Hickman confirmed that Certificate Authorities were designed as a rough hand-wave to address theoretical MITM attacks, never anticipated to scale to millions of hosts. - [17:33](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1053s) CA validation failures are routine occurrences rather than rare exploits, illustrated by unauthorized certificates historically issued for login.live.com, mozilla.com, and Microsoft code-signing. - [18:45](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1125s) The CA marketplace is commodified and operationally negligent, with providers accidentally publishing private keys, suffering breaches, and selling arbitrary interception subordinate roots for around $50,000. - [20:34](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1234s) Proposals to fix SSL by merely reducing the number of CAs or scoping them by country misunderstand the problem, as sovereign states already control roots and users do not universally trust their own governments. - [24:35](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1475s) Trust Agility requires two core capabilities: decisions about trust must be dynamically revisable over time, and trust anchors must be chosen directly by clients rather than dictated by servers. - [29:20](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1760s) DNSSEC misleads users by conflating distributed data storage with distributed trust, entrenching permanent trust across registrars, TLD registries, and ICANN with no client recourse. - [37:18](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2238s) Carnegie Mellon's Perspectives project pioneered multi-path network probing for self-signed certificates, but was held back by lack of coverage for embedded page assets, notary lag, and browsing history leakage. - [38:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2316s) Convergence redesigns network probing with notary bouncing, proxying encrypted queries through one notary to destination verifiers so that no single node knows both the user's identity and browsing destination. - [40:40](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2440s) Convergence inverts the traditional security model: adding more notaries increases security through consensus requirements, whereas in the CA model, adding more CAs increases the attack surface. - [40:40](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2440s) Adopting Convergence requires zero configuration changes or software upgrades on web servers, effectively eliminating the arbitrary distinction between commercial and self-signed certificates. - [43:44](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2624s) The primary operational hurdles for notary probing are fragmented multi-certificate setups like Citibank and captive portal networks, the latter solvable by tunneling verification queries over unblocked DNS port 53.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=UawS3_iuHoA&t=0s) The Conference Delay Strategy and the Tex-Mex Birthday Prank
Speakers at large events like DEF CON face a universal challenge: the venue is massive, attendees wander in slowly from previous sessions, and the room is barely half-full when the presentation begins. Most speakers stall by reciting a tedious personal biography or recounting the dry historical origins of their topic. Moxie Marlinspike decides to dispense with that routine entirely, announcing: “I don't really like that stuff so I want to try something a little different where I'm just going to tell for the first 3 minutes here a completely unrelated totally random story that has nothing to do with computer security or this talk.”
He recounts an escapade from right after he finished high school, when he and a few friends hatched a hare-brained scheme to travel to the Caribbean, find an uninhabited island, and colonize it. Because driving was cheaper than flying at the time, they drove all the way south to Miami before taking a short hop into the Caribbean, where they tried unsuccessfully to locate a boat. Starving and thoroughly defeated, they turned around and drove back north through Florida. Looking for a sit-down meal, they pulled into the parking lot of a Tex-Mex restaurant. Halfway to the front door, one of their companions realized he had forgotten something or left the car unlocked and turned back, leaving Moxie and his other friend to walk inside alone.
Inside, they witnessed the bizarre finale of the restaurant's birthday ritual. Two waiters were singing at a table; one held a tiny saucer with a small dollop of whipped cream and a spoon in front of an elegantly dressed birthday woman, prompting her to close her eyes and open her mouth. Meanwhile, a second waiter lurked behind her holding a full pie tin piled high with whipped cream. The moment she shut her eyes, the second waiter reached around and smashed the entire pie tin straight into her face without warning. As Moxie and his friend stood in the lobby open-mouthed, his friend noticed their third companion, Jack, walking up from the parking lot and said, “Hey, I think it might be Jack's birthday today.” Moxie slipped away to the waitstaff to confirm they had a birthday special. Jack, assuming his friends had claimed it was his birthday to score free dessert, willingly donned the celebratory hat, closed his eyes, and opened his mouth. Moxie, having prepped a disposable camera under the table, snapped a photograph the exact second the pie tin slammed into Jack's face, immortalizing his expression of pure shock.
[04:54](https://www.youtube.com/watch?v=UawS3_iuHoA&t=294s) The Comodo Breach and the "State-Sponsored Cyber Army" Narrative
Turning from pranks to the heart of the presentation—trust, authenticity, and the Public Key Infrastructure underlying SSL—Moxie shifts to an illustrative incident from March 2011 involving Comodo. Comodo was the second-largest Certificate Authority (CA) in the world, certifying between a fifth and a quarter of all SSL certificates on the internet according to Netcraft data. In March, an intruder breached Comodo's infrastructure and fraudulently generated valid digital certificates for high-value domain names, including `mail.google.com`, `login.yahoo.com`, and Skype—essentially everything required to intercept user credentials for major webmail and communications services across the web.
```mermaid flowchart TD accTitle: The Comodo Breach Narrative Comparison accDescr: Diagram contrasting Comodo's official narrative of a sophisticated state-sponsored cyber attack with the reality revealed by server access logs.
subgraph Official["Comodo Official Narrative"] direction TB A["Comodo Infrastructure Breached"] --> B["Attacker IPs Trace to Iran"] B --> C["CEO Declares 'Sophisticated Clinical Attack'"] C --> D["Mainstream Media Frenzy: State-Sponsored Cyber War"] end
subgraph Reality["Evidence from Server Logs"] direction TB E["Morning After: Same Iranian IP Hits Server"] --> F["Client Environment: Windows, en-US Localization"] F --> G["HTTP Referrer: Introductory Hak5 Video Tutorial"] G --> H["Google Searches: Basic iptables & MITM How-Tos"] end ```
In the wake of the incident, Comodo's founder and CEO issued an alarming public statement designed to elevate the severity of the intrusion. Moxie quotes the executive's assessment: “This attack was extremely sophisticated and critically executed it was a very well orchestrated clinical attack and the attacker knew exactly what they needed to do and how fast they had to operate.” The CEO pointed out that the IP addresses used in the intrusion traced back to Iran, stating: “All of the above leads us to one conclusion only that this was likely to be a state-driven attack.” By framing the incident not as a security lapse by a commercial CA, but as an act of cyberwarfare waged by a state-sponsored army, Comodo deflected institutional blame and propelled the story out of specialized security trade publications and into mainstream international headlines.
- **Market share:** Comodo was responsible for certifying approximately 20% to 25% of all internet certificates at the time. - **Compromised properties:** Fraudulent certificates included `mail.google.com`, `login.yahoo.com`, `login.skype.com`, and other critical login endpoints. - **Executive rhetoric:** The breach was framed as a clinical, state-sponsored cyber attack originating from Iranian IP blocks.
[06:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=396s) Examining the Web Logs: Hak5 Tutorials, Windows, and iptables
Following the explosion of mainstream media coverage, reporters contacted Moxie to ask what an attacker could actually do with rogue certificates. When reporters pressed him for the most straightforward, practical way an adversary would execute such a man-in-the-middle intercept, Moxie explained that they could simply run SSLsniff, a specialized MITM tool he had written and released online. Comodo had taken the unusual step of publishing the attacker's IP address in its official incident report to reinforce the narrative of an Iranian state actor. Curious whether his own public tool had caught the hacker's eye, Moxie inspected the server logs for the website where he hosted SSLsniff.
The morning immediately following the breach, the exact Iranian IP address Comodo had published in its report appeared in Moxie's access logs, downloading SSLsniff. The log metadata quickly punctured the narrative of a sophisticated, elite military unit. The attacker's system was running Windows, and the browser's language setting was localized to US English (`en-US`). Crucially, the HTTP referrer revealed that the attacker had landed on Moxie's download page directly from an introductory Hak5 video tutorial explaining how to use SSLstrip.
Subsequent referrer headers from Google searches made throughout the day showed the intruder struggling with basic network configurations, querying terms like `SSL protocol man in the middle howto` and `iptables PREROUTING`. Highlighting the absurdity of the gap between corporate spin and technical reality, Moxie observes: “So just to break this down for you on one hand we have the CEO of Comodo saying this is a clinical attack and on the other hand you know we see that the attacker is literally following video tutorials on the internet.” Far from operating an elite state cyber apparatus, the individual responsible for breaching the world's second-largest CA was an amateur troubleshooting basic routing tables via beginner forum posts and YouTube guides.
[09:47](https://www.youtube.com/watch?v=UawS3_iuHoA&t=587s) The Comodo Breach Fallout and the Failure of CA Accountability
The aftermath of the Comodo certificate breach turned into a public spectacle. The attacker alternated wildly between grandiose, technically absurd claims—such as boasting that he had cracked the RSA algorithm—and chest-thumping declarations of mundane programming skills, proudly announcing that he could export functions from DLLs and build custom SOAP APIs. Moxie Marlinspike notes that the spectacle was deeply humiliating for everyone involved, especially as the attacker refused to stay quiet, publishing six successive communiqués and giving press interviews.
```mermaid flowchart TD accTitle: The Comodo Hacker and Executive Reaction Flow accDescr: Diagram illustrating the hacker's bizarre claims, Comodo's contradictory public statement, and the lack of corporate consequences.
subgraph Attack["The Intrusion"] Hacker["Hacker publishes 6 communiqués<br/>• Claims he cracked RSA<br/>• Boasts about exporting DLL functions & SOAP APIs"] end
subgraph Reaction["Executive Response"] CEO["Comodo CEO Statement:<br/>'If this were a secure and trusted DNS,<br/>this issue would be a moot point!'"] end
subgraph Reality["The Industry Outcome"] Consequences["Zero business consequences<br/>• No lost clients or lawsuits<br/>• Two hacks later that month, another next month<br/>• CEO named Entrepreneur of the Year at RSA"] end
Hacker --> CEO CEO --> Consequences ```
The response from Comodo's leadership was equally bewildering. The company's CEO and founder issued a statement proclaiming that if the internet had a secure and trusted DNS, the entire incident would be a moot point. As Marlinspike observes, this response laid bare that the executive did not understand his own business model:
> “If man-in-the-middle attacks weren't possible, we wouldn't need the certificates that he's selling us.”
DNS tampering is far from the only vector for a man-in-the-middle attack, and the entire commercial justification for selling SSL certificates is to mitigate man-in-the-middle attacks regardless of the routing layer. To make matters worse, Comodo was breached two more times later that same month, and suffered yet another breach the following month.
Despite the catastrophe, Comodo experienced virtually zero negative fallout. The company did not go out of business, lost no measurable customer base, and faced no legal repercussions. Instead, Comodo’s CEO was named Entrepreneur of the Year at the RSA Conference later that year, illustrating the systemic absence of accountability in the certificate authority marketplace.
[12:04](https://www.youtube.com/watch?v=UawS3_iuHoA&t=724s) The Early 1990s Roots of SSL: Secrecy, Integrity, and Authenticity
Every secure network protocol must satisfy three core security guarantees: secrecy, integrity, and authenticity. If any one of these pillars fails, the entire security model collapses. However, evaluating the failures of SSL requires understanding the primitive landscape of the early 1990s when Netscape engineers first designed the protocol.
At the time, standard cryptographic references like Bruce Schneier's *Applied Cryptography* had not yet been published. Implementing RSA required licensing the patented algorithm directly from RSA the company for real money. E-commerce was non-existent, transmitting credit card numbers across the internet was an alien concept, and web applications did not exist to handle account passwords. The entire internet in 1994 consisted of fewer than 5 million hosts according to the Internet Systems Consortium (ISC), compared to an IPv4 space reaching exhaustion at over 4 billion addresses today. Back then, one could barely identify 10 web servers that required encryption, whereas modern networks host millions of certificates across hundreds of millions of domains.
The protocol emerged out of Netscape during a high-stakes commercial browser war under extreme operational pressure—the same environment where late-night rushing produced JavaScript:
> “...this is the same place where a series of 4:00 AM decisions gave us JavaScript, and we're we're still dealing with that today.”
Under those constraints, the original designers accomplished a heroic feat in delivering secrecy and integrity. While cryptographic flaws have occasionally surfaced, the transport encryption and message integrity primitives largely survived. The persistent structural failure lay instead in the third pillar: authenticity.
[14:20](https://www.youtube.com/watch?v=UawS3_iuHoA&t=860s) Tracking Down Kip Hickman: How CAs Were Added as an Afterthought
Authenticity prevents a classic man-in-the-middle (MITM) attack, where an adversary intercepts a connection, initiates independent secure sessions to both endpoints, and transparently logs decrypted data traversing the middle. In 1994 and 1995, however, this attack model was considered almost entirely theoretical. Network manipulation toolkits did not exist in the wild, and designers treated active interception as an academic edge case rather than an operational reality.
To solve this theoretical risk, Netscape adopted the concept of certificates and Certificate Authorities—external organizations trusted to verify domain ownership. Curious about the original assumptions behind this trust architecture, Marlinspike tracked down Kip Hickman, the Netscape engineer who originally authored SSL. Hickman, whose last public internet post dated back to 1995, took a cold call from Marlinspike to discuss how the system was conceived.
Hickman candidly admitted that domain authentication was never the protocol's primary objective:
> “SSL, it was never designed—we were designing it to prevent passive attacks for the most part, you know, we heard about this thing, the man-in-the-middle attack, and so we just sort of threw that in at the end.”
Hickman acknowledged that certificates were essentially a "hand wave" that they never expected to hold up at scale. In 1994, when Yahoo was merely a static index with thirty hyperlinks, verifying a handful of secure websites through a single entity seemed plausible. Expecting centralized organizations to reliably validate millions of domains across a global network was never part of the original design.
```mermaid flowchart LR accTitle: The Evolution of Internet Scale vs CA Trust Model accDescr: Comparison of web scale in 1994 versus modern scale against the static CA model.
subgraph EarlyEra["1994 Reality"] SitesOld["< 5 Million Hosts<br/>~10 Secure Sites<br/>Yahoo = 30 Links"] CAOld["Manual inspection by single trusted entity"] SitesOld --- CAOld end
subgraph ModernEra["Modern Scale"] SitesNew["> 4 Billion Addresses<br/>Millions of SSL Sites<br/>Massive Web Apps"] CANew["Hundreds of commercial CAs inspecting requests automatically"] SitesNew --- CANew end ```
[17:33](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1053s) Authenticity Failures in Practice: A Systemic Reality
Ivan Ristić’s SSL threat matrix highlights that while transport encryption and message integrity have endured, authenticity remains the focal point of catastrophic protocol failures. Real-world events demonstrate that unauthorized certificate issuance is a routine systemic vulnerability rather than sophisticated warfare:
> “I think, you know, looking back at the Comodo thing, you know, the lesson from these events shouldn't be that this was cyber war, because I think pretty clearly it wasn't, um, but that this is happening every day...”
Bypassing CA validation does not require complex technical exploits, reverse-engineering DLLs, or compromising cryptographic keys. Historical examples illustrate the fragility of domain and identity verification:
- **Mike Zusman:** Obtained an unauthorized certificate for Microsoft's `login.live.com` simply by submitting an automated request that the issuing authority failed to validate properly. - **Eddy Nigg:** Successfully secured an unauthorized SSL certificate for `mozilla.com` without undergoing verification. - **VeriSign Microsoft Incident:** Issued two authentic code-signing certificates in the name of Microsoft Corporation to completely unidentified, fraudulent claimants who were never traced.
[18:45](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1125s) The State of Certificate Authorities: Incompetence and Commodification
To illustrate the systemic dysfunction within the Certificate Authority (CA) ecosystem, Moxie Marlinspike shares an anecdote about attempting to buy a certificate from a budget vendor, `sslinabox.com`. Going straight to what he calls “the bottom of the barrel,” he ran into an administrative portal requiring account registration before submission. When he clicked "create account," the software malfunctioned and logged him directly into an existing, arbitrary user's account. He tried logging out and creating an account again, only to be logged into a different stranger's account every subsequent time. Rather than report this severe vulnerability, Marlinspike walked away, deadpanning: “the thing is it's like I didn't even bother emailing them about it because you know I'm I'm sure that they don't even care right.”
```mermaid flowchart TD accTitle: Broken Registration Flow at Low-End CA accDescr: Diagram showing how Moxie Marlinspike's attempt to register an account repeatedly logged him into other users' accounts. subgraph S1["User Action"] A["Moxie registers at sslinabox.com"] end subgraph S2["Broken Auth Logic"] B{"Submit Registration"} end subgraph S3["Faulty Results"] C["Logged into Stranger A's Account"] D["Retry: Logged into Stranger B's Account"] end A --> B B --> C B --> D ```
This negligence extends across the entire industry. Marlinspike points out another active CA that accidentally published its private signing key directly to the public directory of its web server. While making an initial operational mistake might be fathomable, the key remained hosted in that public directory untouched since 2009. Around the same time, StartCom suffered a breach under ambiguous circumstances. Moreover, attackers do not even need technical exploits to compromise the system; interception capabilities are openly commercialized. GeoTrust openly sells subordinate CA certificates: “if you got the money you can just buy a certificate Authority uh you can get a CA cert from GeoTrust I think it's 50 Grand anybody has 50 Grand to spend get your own CA cert intercept all the communication on the internet.” Highlighting the globe-and-key iconography GeoTrust used in their marketing materials, he remarks that they are effectively handing customers the keys to the entire world.
- A public web-accessible directory belonging to an authorized CA exposed its private key continuously starting from 2009. - Subordinate CA certificates granting arbitrary Internet interception abilities were marketed for roughly $50,000 by GeoTrust. - StartCom was recently compromised under unclear circumstances, demonstrating persistent operational insecurity among root trust anchors.
[20:34](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1234s) State-Sponsored Capabilities and Misdiagnosing the CA Problem
Addressing the high-profile Comodo breach, Marlinspike observes that discussion of nation-state involvement misses a broader geopolitical reality: “the only reason that Iran would have to hack a certificate Authority in order to order in order to issue certificates is because they don't have a certificate authority of their own but you know many other countries do.” Citing the Electronic Frontier Foundation's (EFF) SSL Observatory project, which mapped every entity globally capable of issuing trusted certificates, he notes that numerous sovereign states already possess trusted root or intermediate certificates. The map even highlights a tiny red speck in the middle of the Atlantic—Bermuda—possessing the power to sign certificates and intercept traffic. Marlinspike notes that public sentiment toward CAs has degraded “from the old Vibe of total ripoff which I think was just the general perception of certificate authorities to the new Vibe of total ripoff and mostly worthless.”
As the security community contemplates replacing the CA system, Marlinspike warns against misidentifying the root problems:
1. **The "Too Many CAs" Fallacy:** Critics look at the EFF SSL Observatory data—which revealed that 650 separate organizations have the authority to issue valid certificates—and conclude that the pool must simply be shrunk. Marlinspike rejects this, reminding the audience of the early days of the web when VeriSign operated as a monopoly, charging extortionate prices and doing whatever they pleased. Shrinking the CA count makes little sense when scaling from an era of 20 secure websites to 2 million, with an ultimate target of a billion encrypted domains. 2. **The "Few Bad Apples" Theory:** The assertion that most CAs are pristine while only a rogue few ruin their reputation is historically false. Even VeriSign operated a lawful interception services division for governments simultaneously alongside its public certificate business: “the same organization that we had entrusted to secure our communication was also simultaneously making money by intercepting secure communication.” 3. **The Scoping Argument:** Some argue that national security entities like the U.S. Department of Homeland Security (DHS) and the Chinese government hold equal authority over the same universal namespace, suggesting that restricting DHS to U.S. sites and CNNIC to Chinese sites would solve the problem. Marlinspike calls this an unacceptably low bar, noting that many citizens within China do not trust their own government to certify their communications, just as many Americans do not trust DHS to certify theirs.
[24:35](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1475s) The Root Flaw: The Absence of Trust Agility
To understand why nothing substantive happened to Comodo after its breach, Marlinspike examines the operational reality of revoking trust. If a user decides they no longer trust Comodo and removes the CA certificate from their browser's trust store, roughly 20% to 25% of the secure web immediately breaks. Because of this collateral damage, an individual user cannot reasonably uncheck Comodo, nor can browser vendors like Mozilla, Google, or Microsoft remove them on behalf of their users without breaking significant portions of the web. Describing this permanent vulnerability, Marlinspike explains: “The truth is that somewhere along the line along the line we made a decision to trust Komodo and now we are locked into trusting them forever.”
```mermaid flowchart LR accTitle: The CA Lock-In Trap accDescr: Flowchart illustrating how trusting a Certificate Authority creates irreversible lock-in for browsers and users. A["User or Browser Trusts CA (e.g., Comodo)"] --> B["CA Signs 20-25% of the Web"] B --> C{"CA Suffers Breach or Misbehaves"} C -->|"Remove CA from Trust Store"| D["20-25% of the Web Breaks"] C -->|"Keep CA in Trust Store"| E["Remain Vulnerable to Interception"] ```
Marlinspike synthesizes these failures into a single root diagnosis: the SSL ecosystem completely lacks an architectural property he terms **Trust Agility**. Trust agility relies on two non-negotiable principles:
- **Revision of Trust Over Time:** Decisions about whom to trust must be dynamically revisable at any moment. While it is reasonable to trust specific entities today, Marlinspike stresses: “what seems insane is to think that I could identify an organization or set of organizations that I would be willing to trust not just now but forever regardless of whether they continue to Warrant my trust and without any incentive to continue behaving in a trustworthy way.” - **Client-Side Determination of Trust Anchors:** Trust anchors must be selected by individual users and their client browsers rather than dictated centrally by web servers or static browser trust lists. Relying on websites to change CAs to punish bad actors is unrealistic, especially given how difficult it has historically been to convince websites to deploy HTTPS in the first place. Furthermore, because different users operate in different geographic and threat contexts, no single universal trust list can serve all human beings; ultimately, it is the end user's personal communication data that is at stake.
[27:52](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1672s) Inverting the Trust Model and Trust Agility
Moxie Marlinspike argues that security decisions should fundamentally belong to the user rather than the company running a service. After all, it is the user's data on the line, so users and their browsers ought to decide who to trust. Marlinspike explains that allowing individual users to choose their trust anchors represents a simple yet profound inversion of the current architecture. In the existing model, three entities participate: the client, the server, and the Certificate Authority (CA). The trust transaction is initiated entirely by the server, which asks an authority for a certificate and passes it down to the user. Inverting this dynamic empowers the client to initiate the validation by contacting an authority directly and asking it to verify a site.
This client-driven model resolves the thorny issue of scoping. If a user can select which authority to query, it no longer matters if a foreign agency—such as the Department of Homeland Security—has the authority to sign certificates for domains worldwide. Users in China, for example, could simply bypass that authority altogether and consult a Chinese entity, or an NGO, or any other institution they deem trustworthy. Moxie emphasizes that the twin pillars of trust agility—the freedom to choose and change trust anchors—are precisely what the traditional CA system lacks, and that structural failure is the root cause of the current security crisis.
```mermaid flowchart TD accTitle: Server-Initiated vs User-Initiated Trust Models accDescr: Comparison of traditional CA trust flow initiated by the server against the inverted user-initiated model.
subgraph Traditional["Traditional Model (Server-Initiated)"] S1["Server"] -->|"1. Please certify me"| CA1["Certificate Authority"] CA1 -->|"2. Certificate"| S1 S1 -->|"3. Certificate"| C1["Client / User"] end
subgraph Inverted["Inverted Model (User-Initiated)"] C2["Client / User"] -->|"1. Please certify this site"| CA2["Chosen Authority / Notary"] CA2 -->|"2. Certification result"| C2 S2["Server"] -.->|"Presents cert"| C2 end ```
- “This property that individual users decide where they can anchor their trust is really just a simple but powerful inversion of the way that things already work,” Moxie Marlinspike explains. - Scoping risks disappear when clients pick their verifier, because a user can safely disregard any authority they do not trust.
---
[29:20](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1760s) The Mirage of DNSSEC as an SSL Replacement
Turning to emerging proposals, Moxie examines the push to use DNSSEC to replace the authenticity mechanisms of SSL. The basic concept is deceptively simple: take the SSL certificate for a website and store it inside a DNS record. When a browser initiates a connection, it performs a DNS lookup that returns both the IP address and the server's public key certificate. Upon connecting to the server over SSL, the browser verifies that the certificate presented matches the one returned in the DNS response, with authenticity guaranteed through DNSSEC cryptographic signatures.
Moxie acknowledges the strong emotional appeal of this approach. People hear "DNS" and immediately associate it with the word "distributed," which feels like an attractive escape after years of suffering under the centralized yoke of Certificate Authorities. However, he warns that this appeal conflates data distribution with trust architecture. While the information in DNS records is distributed across zones worldwide, the trust hierarchy itself remains rigidly centralized and top-heavy. In reality, it mirrors the exact failure mode of the current CA ecosystem, where certificates are served across distributed web servers while trust remains consolidated in a tiny handful of centralized bodies.
- “It sounds like exactly what we need after suffering under the centralized yoke of certificate authorities for all these years it would feel good to just wipe them off the page and replace them with a distributed system instead,” Moxie notes, before breaking down why the trust remains centralized. - DNSSEC distributes zone data, but it does not distribute trust.
---
[31:13](https://www.youtube.com/watch?v=UawS3_iuHoA&t=1873s) The Three Untrustworthy Layers of DNSSEC
To evaluate whether DNSSEC offers better integrity or agility, Moxie breaks down the three tiers of entities users are forced to trust under the protocol:
```mermaid flowchart TD accTitle: DNSSEC Trust Hierarchy accDescr: The three mandatory layers of centralized trust required by DNSSEC.
subgraph Hierarchy["DNSSEC Trust Hierarchy"] Root["1. Root (ICANN)<br/>California 501(c)(3) subject to US law"] TLD["2. Top-Level Domains (TLDs)<br/>Verisign (.com,.net), Unknown Registries, ccTLDs"] Reg["3. Domain Registrars<br/>GoDaddy and commercial resellers"]
Root --> TLD TLD --> Reg end ```
1. **Domain Registrars:** If CAs are sketchy, registrars take questionable practices to another level. Moxie draws laughs by pointing out: “Personally I think it should be laughable that the current first step in deploying DNSSEC is to create an account with GoDaddy I think that should be laughable.” 2. **Top-Level Domain (TLD) Registries:** The entities running the TLDs include Verisign for `.com` and `.net`—the very same incumbent CA players under a different name. Other TLDs like `.org` and `.edu` are managed by obscure registries whose executive boards hardly inspire confidence as custodians of global internet communications. Furthermore, country-code TLDs (ccTLDs) force users to place absolute trust in foreign regimes. Moxie highlights trendy ccTLDs like `.io`, `.cc`, and `.ly`, questioning whether developers realize they are delegating security to those respective foreign governments. Looking at countries like Iran (`.ir`) or China (`.cn`), EFF SSL Observatory data already illustrates how many nations intercept traffic; under DNSSEC, state-level control over national domains makes wholesale interception trivial, especially given recent domain seizure precedents. 3. **The Root (ICANN):** While ICANN attempts to maintain a neutral global profile, it remains fundamentally a California 501(c)(3) non-profit organization bound by United States federal law. Pending legislative efforts such as COICA and the PROTECT IP Act (PIPA) reveal a clear governmental ambition to control the domain name system. Even if current resistance blocks these bills, future laws could compel ICANN to comply with domestic surveillance or censorship mandates.
Moxie concludes that DNSSEC drastically reduces trust agility instead of expanding it. In the CA system, a user or browser vendor can theoretically remove Verisign from their root trust store. Under DNSSEC, however, there is zero mechanism to remove Verisign's authority over `.com` and `.net`. Choosing DNSSEC locks users into permanent trust without any recourse: “So if we sign up to trust these people we're signing up not to trust them just now but forever regardless of whether they should continue to warrant our trust with no ability to change our mind about whether we should continue trusting them without any incentives to continue behaving appropriately.”
---
[35:01](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2101s) Network Perspective and the CMU Perspectives Project
Seeking a constructive path forward, Moxie highlights the *Perspectives* project, developed at Carnegie Mellon University by Dan Wendlandt, David G. Andersen, and Adrian Perrig. Originally documented in an academic paper on multi-path probing to authenticate SSH and SSL connections, Perspectives relies on the power of independent network viewpoints.
When a client visits a site like `paypal.com` and receives a certificate, it queries external network authorities called "notaries" to ask what certificate they observe from their own locations. Each notary connects to the destination server over its own distinct network path, collects the public key certificate, and reports it back to the client. The client then verifies that the certificate presented locally matches what the remote notaries received. By querying multiple notaries placed across diverse global vantage points, the user builds a robust "constellation of trust" that neutralizes localized man-in-the-middle attacks.
Moxie points out that relying on network perspective is not actually a radical departure—it is how the CA system already works behind the scenes. When a server administrator orders a certificate, the CA verifies control by emailing a secret confirmation token to the administrator's domain contact address. If the administrator receives the token and submits it back, domain ownership is presumed valid based on basic network reachability. Perspectives takes that exact concept and flips the direction, making the verification check client-initiated rather than site-initiated. Although the original CMU release demonstrated that the concept works, Moxie notes that its initial software implementation suffered from significant practical limitations.
[37:18](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2238s) Limitations of the Perspectives Project
```mermaid flowchart TD accTitle: Perspectives System Challenges accDescr: Diagram illustrating the three core challenges of the original Perspectives design: lack of completeness, privacy leaks, and responsiveness issues due to notary lag. subgraph P["Perspectives Weaknesses"] C["1. Completeness<br/>Only checks initial browser requests;<br/>ignores images, CSS, JavaScript"] PR["2. Privacy<br/>Every secure site lookup leaks<br/>browsing history to notaries"] R["3. Responsiveness (Notary Lag)<br/>Periodic polling caches certificates;<br/>site updates cause false invalid responses"] end ```
The concept of multi-path network probing was pioneered by Dan Wendlandt's Perspectives project, but because it was initially designed only to validate self-signed certificates, it ran into three major architectural limitations. The first hurdle was completeness: the browser extension only handled the top-level initial HTTP connection made by the browser. It completely ignored background page resources such as stylesheets, images, and JavaScript payloads, making it impossible to genuinely retire Certificate Authorities (CAs) using Perspectives alone.
The second critical issue was user privacy. Whenever a client navigates to a secure website, consulting an external notary effectively transmits the user's entire real-time browsing history to that notary. Marlinspike notes that leaking every site visit to third-party verification nodes is an unacceptable compromise.
The third issue was responsiveness, specifically what Marlinspike terms "notary lag." In the Perspectives architecture, when a client asks a notary what certificate it sees for a domain like `paypal.com`, the notary probes the target site and caches the resulting certificate so it does not overwhelm destinations with outbound connections. It then refreshes that cache via periodic polling—for instance, once a day:
> “The problem is that if a site did switch to a different certificate your responses from the notary would be invalid for the duration of the the poll interval.”
- Perspectives was restricted to initial connections, leaving embedded page assets completely unprotected. - Querying a notary on every connection leaked the user's real-time browsing habits. - Notary caching with daily polling intervals meant legitimate certificate rotations were misidentified as invalid or spoofed until the cache expired.
---
[38:36](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2316s) Convergence: Architecture, Privacy, and Notary Bouncing
```mermaid flowchart LR accTitle: Convergence Notary Bouncing Architecture accDescr: Flow diagram showing an end user establishing an encrypted tunnel through a bounce notary to hide browsing intent from destination notaries. subgraph Client["Client Machine"] Browser["Convergence Extension<br/>(Local Cache Checked First)"] end
subgraph Proxy["Proxying Layer"] Bounce["Random Bounce Notary<br/>(Knows WHO you are,<br/>NOT what you query)"] end
subgraph Validation["Verification Layer"] Dest1["Notary A"] Dest2["Notary B"] Dest3["Notary C"] end
Browser -->|"Tunnel via pre-shared keys"| Bounce Bounce -->|"Forward encrypted payload"| Dest1 Bounce -->|"Forward encrypted payload"| Dest2 Bounce -->|"Forward encrypted payload"| Dest3 ```
To resolve these structural flaws, Marlinspike built Convergence, a ground-up redesign comprising a new protocol, client implementation, and server architecture. Convergence eliminates notary lag entirely by altering the client handshake: when querying a notary, the client includes the exact certificate fingerprint it received from the target server. The notary only needs to connect outbound to the origin server if there is an explicit cache miss or a cache mismatch, making scheduled background polling obsolete.
To solve the privacy problem, Convergence implements a two-fold defense. First, it relies on extensive local caching. Once a trusted notary confirms a certificate is legitimate, the browser caches that verdict locally. On subsequent visits, as long as the origin presents the identical certificate, the client verifies it locally without notifying external servers. Marlinspike points out that this alone still leaves the client leaking metadata on first visits or certificate rotations, leading to the introduction of "notary bouncing."
Under notary bouncing, the client randomly picks one configured notary from its list to serve as an anonymizing proxy. The client establishes an SSL tunnel through this bounce notary out to its remaining destination verification notaries using static, pre-shared public keys set when the notaries were added to the browser. As Marlinspike summarizes the separation of concerns:
> “The bounce notary is just a dumb proxy shoveling bytes around and it's doesn't have any visibility into what you're querying about. The notaries that you're talking to know what you're asking about, but they don't know who you are, and the bounce notary knows who you are, but they don't—but it doesn't know who you're asking about.”
---
[40:40](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2440s) Eliminating CAs and Empowering Trust Agility
Convergence is packaged as a Firefox add-on that blends seamlessly into the standard browser interface, adding a small control button in the top right. Enabling Convergence fundamentally alters the browser's cryptographic trust model:
> “If you click this button and enable Convergence, you are completely divorced from the CA system.”
Every single connection—including all background page assets, scripts, stylesheets, and images—bypasses the operating system and browser Certificate Authority trust stores entirely. Instead of seeing a CA vendor listed in the favicon site-identity tooltip, validation is managed exclusively by Convergence notaries.
The server component is a lightweight, open-source REST service designed with modular backends. While its default engine relies on multi-perspective network probing, administrators can write pluggable validation backends: - A DNSSEC backend that validates certificates against signed DNS records. - A CA-signature backend (if an administrator actually wants to verify traditional hierarchical chains). - A front-end interface querying the EFF SSL Observatory (which the Electronic Frontier Foundation volunteered to host).
Convergence redefines authority trust by establishing a configurable consensus threshold across distinct notary nodes:
> “In the current CA system, you know you have some number of certificate authorities and if one of them is a bad actor you're completely out of luck, and we're inverting that here where the more authorities that you have, the more notaries that you configure, the better off you are because it means that all of them have to be in cahoots to misbehave and intercept your SSL communication.”
Unlike traditional PKI, Convergence introduces true trust agility. If a user loses faith in a particular notary operator, they can revoke or swap out that single notary immediately without breaking connectivity to any websites. Furthermore, web servers require zero configuration changes or software upgrades, completely eliminating the need for an internet-wide migration: the entire legacy CA system could be superseded simply by implementing Convergence natively across the four major web browsers. Under this paradigm, the arbitrary category of a "self-signed certificate" vanishes—certificates are treated purely as cryptographic keys without class distinctions.
---
[43:44](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2624s) Practical Edge Cases and the Future of Authenticity
Marlinspike highlights two real-world operational challenges encountered during beta testing. The first is what he terms the "Citibank problem." When testing Convergence on `citibank.com`, the browser triggered persistent untrusted certificate warnings:
> “And the problem is that Citibank apparently has like a couple of hundred different SSL certificates and each one is on a different like SSL accelerator, so every time you connect you get a different certificate, which means that all the notaries see different certificates, your browser sees a different certificate, and it looks identical to a—the case of being attacked.”
Fortunately, erratic multi-certificate deployments are an anomaly on the wider web, meaning resolving the issue requires isolated sites to adopt sane operational practices rather than modifying the broader protocol.
The second operational challenge involves captive portals commonly found in hotels and airports. These networks block internet access until the guest signs in or enters payment details on a captive web page. Because the portal intercepts and redirects web traffic while blocking external outbound connections, the Convergence client cannot reach its external notaries to validate the captive portal's own SSL certificate. Marlinspike notes that users currently have to temporarily disable Convergence in these environments. However, because captive portals almost universally allow DNS traffic out, building a lightweight Convergence query protocol over DNS would resolve the captive portal bottleneck without requiring browser deactivation.
Marlinspike announces that the software was released the previous day in beta at `convergence.io`, inviting security researchers to run their own notaries and build networks of mutual trust. He concludes by challenging the audience to re-examine the core premise of security architectures:
> “Whenever someone is proposing another authenticity system, I think the question that we should all ask is: who do we have to trust and for how long? If the answer is a prescribed set of people forever, proceed with caution.”
- Beta code and client extensions published at `convergence.io`. - Citibank was the only major site identified serving hundreds of disparate certificates across separate accelerators for the same host. - Captive network workarounds can leverage port 53 DNS tunneling because network gates routinely leave DNS unblocked. - The ultimate metric for any new authentication framework is whether it locks users into a permanent, non-negotiable set of authoritative gatekeepers.
## Notable quotes > [43:44](https://www.youtube.com/watch?v=UawS3_iuHoA&t=2624s) Whenever someone is proposing another authenticity system, I think the question that we should all ask is: who do we have to trust and for how long? If the answer is a prescribed set of people forever, proceed with caution. — Moxie Marlinspike
## Mentioned Moxie Marlinspike, Comodo, Netscape, SSLsniff, SSLstrip, Hak5, Bruce Schneier, Applied Cryptography, RSA, Internet Systems Consortium, Kip Hickman, Ivan Ristić, Mike Zusman, Eddy Nigg, VeriSign, sslinabox.com, GeoTrust, StartCom, Electronic Frontier Foundation, EFF SSL Observatory, U.S. Department of Homeland Security, CNNIC, DNSSEC, ICANN, GoDaddy, COICA, PROTECT IP Act, Dan Wendlandt, David G. Andersen, Adrian Perrig, Carnegie Mellon University, Perspectives, Convergence, Firefox, Citibank
## Video description Moxie Marlinspike - SSL And The Future Of Authenticity In the early 90's, at the dawn of the World Wide Web, some engineers at Netscape developed a protocol for making secure HTTP requests, and what they came up with was called SSL. Given the relatively scarce body of knowledge concerning secure protocols at the time, as well the intense pressure that everyone at Netscape was working under, their efforts can only be seen as incredibly heroic. But while it's amazing that SSL has endured for as long as it has, some parts of it -- particularly those concerning Certificate Authorities -- have always caused some friction, and have recently started to cause real problems. This talk will examine authenticity within SSL, shed new light on the current problems, and cover some new strategies for how to move forward.
[Source](https://www.youtube.com/watch?v=UawS3_iuHoA)